Partilhar via

Práticas recomendadas para operações de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível

  • Artigo

Saiba mais sobre as práticas recomendadas para trabalhar com o Banco de Dados do Azure para o Servidor Flexível MySQL. À medida que adicionamos novos recursos à plataforma, continuamos a nos concentrar em refinar as práticas recomendadas detalhadas nesta seção.

Diretrizes operacionais do Banco de Dados do Azure para Servidor Flexível MySQL

A seguir estão as diretrizes operacionais que devem ser seguidas ao trabalhar com o Banco de Dados do Azure para o Servidor Flexível MySQL para melhorar o desempenho do seu banco de dados:

  • Colocalização: para reduzir a latência da rede, coloque o cliente e o servidor de banco de dados na mesma região do Azure.

  • Monitore o uso de memória, CPU e armazenamento: você pode configurar alertas para notificá-lo quando os padrões de uso mudarem ou quando se aproximar da capacidade de sua implantação, para que possa manter o desempenho e a disponibilidade do sistema.

  • Logs acelerados para desempenho aprimorado: habilitar o recurso de logs acelerados otimiza as operações relacionadas a logs transacionais, aumentando a taxa de transferência e o desempenho do servidor. Esse recurso, disponível sem custo extra, é uma adição significativa às práticas recomendadas operacionais para usuários da camada de serviço Business Critical.

  • Aumente a escala da instância de banco de dados: você pode aumentar a escala quando estiver se aproximando dos limites de capacidade de armazenamento. Você deve ter algum buffer no armazenamento e na memória para acomodar aumentos imprevistos na demanda de seus aplicativos. Você também pode ativar o recurso de crescimento automático de armazenamento 'ON' apenas para garantir que o serviço dimensione automaticamente o armazenamento à medida que se aproxima dos limites de armazenamento.

  • Configurar backups: habilite backups locais ou com redundância geográfica com base nos requisitos da empresa. Além disso, você modifica o período de retenção por quanto tempo os backups estão disponíveis para continuidade de negócios.

  • Otimize a capacidade de E/S com IOPS de dimensionamento automático: se a carga de trabalho do banco de dados exigir mais E/S do que o provisionado, a recuperação ou outras operações transacionais para o banco de dados serão lentas. Para aumentar a capacidade de E/S de uma instância do servidor, siga um destes procedimentos:

    • Usar IOPS de dimensionamento automático: IOPS de dimensionamento automático elimina a necessidade de pré-provisionar um número específico de operações de E/S por segundo. Em vez disso, ele permite que o servidor ajuste automaticamente as IOPS com base nos requisitos de carga de trabalho1. Isso significa que seu servidor pode escalar IOPS para cima ou para baixo automaticamente, dependendo das necessidades de carga de trabalho.

    • O Banco de Dados do Azure para Servidor Flexível MySQL fornece escalonamento de IOPS à taxa de três IOPS por GB de armazenamento provisionado. Aumente o armazenamento provisionado para dimensionar as IOPS para obter um melhor desempenho.

    • Se você já estiver usando o armazenamento de IOPS provisionadas, provisione capacidade de taxa de transferência adicional.

  • Computação em escala: a carga de trabalho do banco de dados também pode ser limitada devido à CPU ou à memória, e isso pode ter um sério impacto no processamento da transação. A computação (nível de preço) pode ser dimensionada para cima ou para baixo apenas entre os níveis de uso geral ou otimizado para memória .

  • Teste de failover: teste manualmente o failover da instância do servidor para entender quanto tempo o processo leva para o caso de uso e para garantir que o aplicativo que acessa a instância do servidor possa se conectar automaticamente à nova instância do servidor após o failover.

  • Usar chave primária: verifique se suas tabelas têm uma chave primária ou exclusiva enquanto você opera no Banco de Dados do Azure para a instância do Servidor Flexível MySQL. Isso ajuda muito a fazer backups, réplicas, etc. e melhora o desempenho.

  • Configurar valor TTL: Se o aplicativo cliente estiver armazenando em cache os dados DNS (Serviço de Nomes de Domínio) das instâncias do servidor, defina um valor TTL (time-to-live) inferior a 30 segundos. Como o endereço IP subjacente de uma instância do servidor pode mudar após um failover, armazenar em cache os dados DNS por um tempo prolongado pode levar a falhas de conexão se seu aplicativo tentar se conectar a um endereço IP que não está mais em serviço.

  • Use o pool de conexões para evitar atingir os limitesmáximos de conexão e use a lógica de repetição para evitar problemas de conexão intermitentes.

  • Se você estiver usando réplica, use ProxySQL para equilibrar a carga entre o servidor primário e o servidor de réplica secundário legível. Consulte os passos de configuração aqui.

  • Ao provisionar o recurso, certifique-se de habilitar o crescimento automático para sua instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Isso não adiciona nenhum custo extra e protege o banco de dados de quaisquer gargalos de armazenamento que você possa encontrar.

Usar o InnoDB com o Banco de Dados do Azure para o Servidor Flexível MySQL

  • Se estiver usando ibdata1 o recurso, que é um arquivo de dados de espaço de tabela do sistema não pode diminuir ou ser limpo soltando os dados da tabela ou movendo a tabela para o arquivo por tabela tablespaces.

  • Para um banco de dados maior que 1 TB, você deve criar a tabela em innodb_file_per_table tablespace. Para uma única tabela maior que 1 TB de tamanho, você deve a tabela de partição .

  • Para um servidor que tem um grande número de , a inicialização do mecanismo é muito lenta devido à verificação sequencial do espaço de tabela durante a inicialização ou failover do Banco de Dados do Azure para o Servidor Flexível MySQL tablespace.

  • Defina innodb_file_per_table = ON antes de criar uma tabela, se o número total da tabela for inferior a 500.

  • Se você tiver mais de 500 tabelas em um banco de dados, revise o tamanho da tabela para cada tabela individual. Para uma tabela grande, você ainda deve considerar o uso do espaço de tabela de arquivo por tabela para evitar que o arquivo de espaço de tabela do sistema atinja o limite máximo de armazenamento.

Nota

Para tabelas com tamanho inferior a 5 GB, considere usar o espaço de tabela do sistema

CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;

  • Particione sua tabela na criação da tabela se você tiver uma tabela grande pode potencialmente crescer além de 1 TB.

  • Use várias instâncias do Banco de Dados do Azure para o Servidor Flexível MySQL e espalhe as tabelas por esses servidores. Evite colocar muitas tabelas em um único servidor se você tiver cerca de 10.000 tabelas ou mais.

Conteúdos relacionados