Melhores práticas para operações de servidor no Banco de Dados do Azure para MySQL - Servidor flexível
Conheça as melhores práticas para trabalhar com o Banco de Dados do Azure para MySQL. À medida que adicionarmos novos recursos à plataforma, continuamos a nos concentrar em refinar as melhores práticas detalhadas nesta seção.
Diretrizes operacionais de Servidor Flexível do Banco de Dados do Azure para MySQL
Veja a seguir as diretrizes operacionais que devem ser seguidas ao trabalhar com o Servidor Flexível do Banco de Dados do Azure para MySQL para melhorar o desempenho do seu banco de dados:
Colocalização: para reduzir a latência de rede, coloque o cliente e o servidor de banco de dados na mesma região do Azure.
Monitorar a memória, a CPU e o uso do armazenamento: é possível configurar alertas para notificar você quando os padrões de uso forem alterados ou quando se aproximar da capacidade de sua implantação, para que você possa manter o desempenho e a disponibilidade do sistema.
Logs acelerados para desempenho aprimorado: habilitar o recurso de logs acelerados otimiza operações relacionadas a logs transacionais, aumentando a taxa de transferência e o desempenho do servidor. Esse recurso, disponível sem custo adicional, é uma adição significativa às práticas recomendadas operacionais para usuários da camada de serviço Comercialmente Crítico.
Escalar verticalmente a instância de BD: você pode escalar verticalmente 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 habilitar o recurso de crescimento automático do armazenamento como 'ON' apenas para garantir que o serviço dimensione automaticamente o armazenamento conforme for se aproximando dos limites de armazenamento.
Configurar backups: habilite backups locais ou com redundância geográfica baseados no requisito do negócio. Além disso, modifique o período de retenção de quanto tempo os backups ficam disponíveis para continuidade dos negócios.
Otimizar a capacidade de E/S com o IOPS de dimensionamento automático: se a carga de trabalho do seu banco de dados exigir mais E/Ss do que você provisionou, a recuperação ou outras operações transacionais do banco de dados ficarão lentas. Para aumentar a capacidade de E/S de uma instância de servidor, faça o seguinte:
Use o IOPS de dimensionamento automático: o 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, permite que o servidor ajuste automaticamente o IOPS com base nos requisitos de carga de trabalho. Isso significa que o servidor pode dimensionar o IOPS para cima ou para baixo automaticamente, dependendo das necessidades de carga de trabalho.
O Servidor Flexível do Banco de Dados do Azure para MySQL fornece escala de IOPS na taxa de três IOPS por GB de armazenamento provisionado. Aumente o armazenamento provisionado para escalar o IOPS para melhorar o desempenho.
Se você já estiver usando o armazenamento de IOPS provisionado, provisione capacidade de taxa de transferência adicional.
Escalar computação: a carga de trabalho do banco de dados também pode ser limitada devido à CPU ou memória e isso pode ter um impacto significativo no processamento de transações. A computação (tipo de preço) pode ser escalada ou reduzida verticalmente somente entre as camadas Uso Geral ou Otimizado para Memória.
Teste de failover: faça o teste manual de failover para sua instância de servidor para entender quanto tempo o processo leva para seu 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 as tabelas têm uma chave primária ou exclusiva enquanto você opera na instância do Servidor Flexível do Banco de Dados do Azure para 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 do Sistema de Nomes de Domínio (DNS) de suas instâncias de servidor, defina um valor de tempo de vida útil (TTL) inferior a 30 segundos. Como o endereço IP subjacente de uma instância de servidor pode ser alterado após um failover, armazenar em cache os dados de DNS por um tempo estendido pode levar a falhas de conexão se o 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 limites máximos de conexão e use a lógica de repetição para evitar problemas de conexão intermitente.
Se você estiver usando a réplica, use o ProxySQL para balancear carga entre o servidor primário e o servidor de réplica secundária para leitura. Veja as etapas de instalação aqui.
Ao provisionar o recurso, certifique-se de ter habilitado 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 contra quaisquer gargalos de armazenamento que você possa encontrar.
Usar o InnoDB com o Banco de Dados do Azure para MySQL – Servidor Flexível
Se você estiver usando o recurso
ibdata1, que é um arquivo de dados de espaço de tabela do sistema, não é possível reduzir ou limpar removendo os dados da tabela ou movendo a tabela para arquivo por tabelatablespaces.Para um banco de dados com tamanho maior que 1 TB, você deve criar a tabela em innodb_file_per_table
tablespace. Para uma única tabela com tamanho maior que 1 TB, você deve particionar a tabela.Para um servidor que tem um grande número de
tablespace, a inicialização do mecanismo é muito lenta devido à verificação de espaço de tabela sequencial durante a inicialização ou o failover do Servidor Flexível do Banco de Dados do Azure para MySQL.Defina innodb_file_per_table = ON antes de criar uma tabela, se o número total de tabelas for menor que 500.
Se você tiver mais de 500 tabelas em um banco de dados, examine 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 limite de armazenamento máximo.
Observação
Para tabelas com tamanho menor que 5 GB, considere usar o espaço de tabela do sistema
CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;
Particione sua tabela na criação de tabela se você tiver uma tabela grande que possa crescer e ultrapassar 1 TB.
Use várias instâncias de Servidor Flexível do Banco de Dados do Azure para MySQL e espalhe as tabelas entre esses servidores. Evite colocar muitas tabelas em um único servidor se você tiver cerca de 10.000 tabelas ou mais.