Práticas recomendadas para o desempenho ideal do Banco de Dados do Azure para MySQL - Servidor Flexível

Artigo
12/19/2023

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único Banco de Dados do Azure para MySQL - Servidor Flexível

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

Saiba como obter o melhor desempenho ao trabalhar com o servidor flexível do Banco de Dados do Azure para MySQL. À medida que adicionamos novos recursos à plataforma, continuaremos refinando nossas recomendações nesta seção.

Proximidade física

Certifique-se de implantar um aplicativo e o banco de dados na mesma região. Uma verificação rápida antes de iniciar qualquer execução de benchmarking de desempenho é determinar a latência da rede entre o cliente e o banco de dados usando uma simples consulta SELECT 1.

Quando recursos como um aplicativo Web e seu banco de dados associado estão sendo executados em regiões diferentes, pode haver maior latência na comunicação entre esses recursos. Outro efeito colateral possível de ter o aplicativo e o banco de dados em regiões separadas diz respeito aos custos de transferência de dados de saída.

Para melhorar o desempenho e a confiabilidade de um aplicativo em uma implantação com custo otimizado, é altamente recomendável que o serviço de aplicativo Web e o recurso de servidor flexível do Banco de Dados do Azure para MySQL residam na mesma região e zona de disponibilidade. Esse colocation é melhor para aplicativos sensíveis à latência e também fornece a melhor taxa de transferência, já que os recursos são estreitamente emparelhados.

Rede acelerada

Use a rede acelerada para o servidor de aplicativos se estiver usando a máquina virtual do Azure, o Kubernetes do Azure ou os Serviços de Aplicativo. A rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) para uma VM, melhorando consideravelmente seu desempenho de rede. Esse caminho de alto desempenho ignora o host do caminho de dados, reduzindo a latência, o jitter e a utilização da CPU, para uso com as cargas de trabalho de rede mais exigentes em tipos de VM suportados.

Eficiência da ligação

Estabelecer uma nova conexão é sempre uma tarefa cara e demorada. Quando um aplicativo solicita uma conexão de banco de dados, ele prioriza a alocação de conexões de banco de dados ociosas existentes em vez de criar uma nova. Aqui estão algumas opções de boas práticas de conexão:

ProxySQL: Use o ProxySQL, que fornece pool de conexões interno e balanceamento de carga de trabalho para várias réplicas de leitura, conforme necessário sob demanda com quaisquer alterações no código do aplicativo.
Heimdall Data Proxy: Como alternativa, você também pode usar o Heimdall Data Proxy, uma solução de proxy proprietária neutra do fornecedor. Ele suporta cache de consulta e divisão de leitura/gravação com deteção de atraso de replicação. Você também pode consultar como acelerar o desempenho do MySQL com o proxy Heimdall.
Conexão persistente ou de longa duração: se seu aplicativo tiver transações curtas ou consultas normalmente com tempo de execução de < 5 a 10 ms, substitua conexões curtas por conexões persistentes. Substituir conexões curtas por conexões persistentes requer apenas pequenas alterações no código, mas tem um grande efeito em termos de melhoria de desempenho em muitos cenários típicos de aplicativos. Certifique-se de definir o tempo limite ou fechar a conexão quando a transação for concluída.
Réplica: 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. Saiba como configurar o ProxySQL.

Conjunto de ligações

O pool de conexões é um mecanismo que gerencia a criação e a alocação de conexões de banco de dados e protege um banco de dados contra picos de conexão. Considere o pool de conexões se seu aplicativo abrir muitas conexões em um tempo relativamente curto e as conexões forem de curta duração. Esses tipos de conexões podem ocorrer, por exemplo, em uma magnitude de centenas ou milhares por segundo, e o tempo necessário para estabelecê-las e fechá-las é significativo em comparação com a vida útil total da conexão.

Se a estrutura de desenvolvimento do seu aplicativo não oferecer suporte ao pool de conexões, use um proxy de conexão, como o proxy ProxySQL ou Heimdall, entre o aplicativo e o servidor de banco de dados.

Manipulando o dimensionamento de conexão

Uma abordagem comum para dimensionar aplicativos Web para atender à demanda flutuante é adicionar e remover servidores de aplicativos. Cada servidor de aplicativos pode usar um pool de conexões com o banco de dados. Essa abordagem faz com que o número total de conexões em um servidor de banco de dados cresça em relação ao número de servidores de aplicativos. Por exemplo, se um servidor de banco de dados tiver 10 servidores de aplicativos e cada um estiver configurado para 100 conexões de banco de dados, isso fornecerá 1.000 conexões de banco de dados. Se a carga de trabalho do aplicativo for dimensionada devido à maior atividade do usuário ou durante o horário de pico e se forem adicionados 50 servidores de aplicativos adicionais, as conexões de banco de dados totalizarão 6.000. Normalmente, a maioria dessas conexões ficará ociosa, depois de ser gerada pelos servidores de aplicativos. Como as conexões ociosas consomem recursos (memória e CPU) para permanecerem abertas, a escalabilidade do banco de dados pode ser afetada.

Outros desafios potenciais envolvem a manipulação do número total de conexões com o servidor de banco de dados. Isso é ditado pelo número de servidores de aplicativos conectados ao servidor de banco de dados, cada um criando seu próprio conjunto de conexões. Nesses cenários, considere ajustar os pools de conexões nos servidores de aplicativos. Tente reduzir o número de conexões em cada pool para um mínimo aceitável para garantir que não haja inchaço nas conexões no lado do servidor de banco de dados. Considere isso como uma solução de curto prazo para combater os efeitos do dimensionamento do servidor de aplicativos, em vez de uma solução permanente para lidar com o crescimento do aplicativo.

Como uma solução de longo prazo, introduza um proxy de conexão, como ProxySQL ou proxy Heimdall, entre o servidor de banco de dados e o servidor de aplicativos. Isso ajuda porque o proxy irá:

Estabeleça uma conexão com o servidor de banco de dados com um número fixo de conexões.
Aceite conexões de aplicativos e aja como um buffer para possíveis tempestades de conexão.

Os proxies podem fornecer outros recursos, como cache de consulta, buffer de conexão, regravação/roteamento de consultas e balanceamento de carga. Para uma escalabilidade ainda maior, considere o uso de várias instâncias de proxy.

Tratamento de ligações para tolerância a falhas e recuperação mais rápida

Ao projetar seus aplicativos e ambiente para tolerância a falhas e recuperação mais rápida, considere que, em um ambiente de banco de dados, é provável que você sofra interrupções de conexão ou falhas de hardware. Lembre-se também da necessidade de ações operacionais, como dimensionamento de tamanhos de instância, aplicação de patches e execução de failover manual.

Por exemplo, considere um cenário em que o servidor de banco de dados conclui o failover em um minuto, mas seu aplicativo fica inativo por vários minutos a mais devido a coisas como o TTL DNS ser muito longo no lado do aplicativo. Nesses casos, simplesmente reduzir o valor TTL fornecerá uma recuperação mais rápida ou integrar um proxy de conexão entre o aplicativo e o servidor de banco de dados pode ajudar a lidar com essas falhas.

Criação de partições

Quando sua carga de trabalho de produção usa tabelas extremamente grandes, o particionamento é um ótimo método para melhorar o desempenho do banco de dados e facilitar a manutenção. O particionamento facilita o gerenciamento de tabelas grandes, essa abordagem permite que você adicione e solte partições para gerenciar tabelas grandes de forma eficaz. O particionamento também pode ajudar a dimensionar o mecanismo, aliviando a contenção da estrutura interna, como bloqueios internos por tabela ou por índice (por exemplo, considere o btr_search_latch no InnoDB).

Ao adicionar cinco partições, por exemplo, você essencialmente quebra uma mesa grande com muita atividade em cinco tabelas menores e mais eficientes. Isso ajudaria principalmente nos casos em que a operação principal é a pesquisa de chave primária na tabela, de modo que as consultas possam tirar proveito da "remoção de partição". Mas o particionamento também pode ajudar em termos de verificação de tabela.

Observe que, embora o particionamento tenha seus benefícios, ele também tem algumas limitações, como a falta de suporte para chaves estrangeiras em tabelas particionadas, a falta de cache de consulta, etc. Para obter uma lista completa dessas limitações, no manual de referência do MySQL, consulte o capítulo Restrições e limitações de particionamento.

Segregação de leituras e gravações

A maioria dos aplicativos lê principalmente do banco de dados, com apenas uma pequena porcentagem das interações envolvendo gravações. O número de conexões ativas no banco de dados primário que calculamos para os pools de conexões provavelmente inclui tráfego de leitura. O descarregamento do maior número possível de consultas para ler réplicas e a conservação do acesso à instância primária gravável aumentam a quantidade de atividade geral do banco de dados executada pelos servidores de aplicativos sem aumentar a carga no banco de dados primário. Se você ainda não estiver acessando réplicas de leitura pelo menos para consultas de execução mais longas, como relatórios, considere mover imediatamente relatórios ou análises para réplicas de leitura.

O uso em maior escala de réplicas de leitura pode exigir uma consideração mais cuidadosa, pois as réplicas ficam ligeiramente atrás do principal devido à natureza assíncrona da replicação. Encontre o maior número possível de áreas do aplicativo que podem ser servidas com leituras das réplicas com pequenas alterações de código. Você também deve aplicar esse método em níveis mais altos em relação ao cache - veicular mais conteúdo somente leitura ou que muda lentamente de uma camada de cache dedicada, como o Cache do Azure para Redis.

Gravação, dimensionamento e fragmentação

Com o tempo, os aplicativos evoluem e novas funcionalidades são adicionadas. Por conveniência ou prática geral, as tabelas são adicionadas ao banco de dados primário. Para lidar com cargas de tráfego crescentes em um banco de dados, identifique áreas do aplicativo que podem ser facilmente movidas para bancos de dados separados e considere fragmentar horizontalmente ou dividir verticalmente o banco de dados.

A fragmentação horizontal de um banco de dados funciona criando várias cópias do esquema do aplicativo em bancos de dados separados e segregando clientes e todos os dados associados com base na ID do cliente, na geografia ou em algum outro atributo por cliente ou locatário. Isso funciona muito bem para aplicativos SaaS ou B2C em que os clientes individuais são pequenos e a carga no aplicativo é do uso agregado de milhões de clientes. No entanto, é mais difícil com aplicações B2B em que os clientes são de tamanhos diferentes e os grandes clientes individuais podem dominar a carga de tráfego para um fragmento específico.

Divida verticalmente a carga fragmentando funcionalmente o banco de dados - movendo domínios de aplicativos separados (ou microsserviços) para seus próprios bancos de dados. Isso distribui a carga do banco de dados primário para bancos de dados separados por serviço. Exemplos simples incluem uma tabela de registro em log ou informações de configuração do site que não precisam estar no mesmo banco de dados que a tabela de pedidos muito carregada. Exemplos mais complicados incluem separar domínios de clientes e contas de pedidos ou domínios de atendimento. Em alguns casos, isso pode exigir alterações no aplicativo, por exemplo, para modificar filas de trabalho de e-mail ou em segundo plano para serem independentes e não dependerem de junções de volta a um cliente ou tabela de pedidos. Mover tabelas e dados existentes para um novo banco de dados primário pode ser realizado com o Banco de Dados do Azure para réplicas de leitura de servidor flexível do MySQL, promovendo a réplica e apontando partes do aplicativo para o banco de dados gravável recém-criado. O banco de dados recém-criado precisa limitar o acesso com pools de conexões, ajustar consultas e distribuir a carga com suas próprias réplicas, assim como a principal original.

Configurações de importação de dados

Você pode dimensionar temporariamente sua instância para um tamanho de SKU mais alto antes de iniciar uma operação de importação de dados e, em seguida, reduzi-la quando a importação for bem-sucedida.
Você pode importar seus dados com o mínimo de tempo de inatividade usando o Serviço de Migração de Banco de Dados do Azure (DMS) para migrações online ou offline.

Recomendações de memória flexível do Banco de Dados do Azure para MySQL

Uma prática recomendada de desempenho de servidor flexível do Banco de Dados do Azure para MySQL é alocar RAM suficiente para que seu conjunto de trabalho resida quase completamente na memória.

Verifique se a porcentagem de memória que está sendo usada para atingir os limites usando as métricas do Banco de Dados do Azure para o servidor flexível MySQL.
Configure alertas nesses números para garantir que, à medida que o servidor atinge limites, você pode tomar ações imediatas para corrigi-lo. Com base nos limites definidos, verifique se a expansão da SKU do banco de dados — seja para um tamanho de computação mais alto ou para um nível de preço melhor, o que resulta em um aumento dramático no desempenho.
Aumente a escala até que seus números de desempenho não caiam mais drasticamente após uma operação de dimensionamento. Para obter informações sobre como monitorar as métricas de uma instância de banco de dados, consulte Banco de Dados do Azure para métricas de banco de dados de servidor flexível MySQL.

Usar o InnoDB buffer pool Warmup

Depois que a instância flexível do servidor do Banco de Dados do Azure para MySQL for for reiniciada, as páginas de dados que residem no armazenamento são carregadas à medida que as tabelas são consultadas, o que leva a uma maior latência e a um desempenho mais lento para a primeira execução das consultas. Isso pode não ser aceitável para cargas de trabalho sensíveis à latência.

A utilização do aquecimento do pool de buffers do InnoDB reduz o período de aquecimento recarregando páginas de disco que estavam no pool de buffers antes da reinicialização, em vez de esperar pelas operações DML ou SELECT para acessar as linhas correspondentes.

Você pode reduzir o período de aquecimento depois de reiniciar sua instância de servidor flexível do Banco de Dados do Azure para MySQL, o que representa uma vantagem de desempenho configurando os parâmetros do servidor do pool de buffers InnoDB. O InnoDB salva uma porcentagem das páginas usadas mais recentemente para cada pool de buffers no desligamento do servidor e restaura essas páginas na inicialização do servidor.

Também é importante notar que o desempenho melhorado vem à custa de um tempo de inicialização mais longo para o servidor. Quando esse parâmetro está habilitado, espera-se que o tempo de inicialização e reinicialização do servidor aumente dependendo das IOPS provisionadas no servidor.

Recomendamos testar e monitorar o tempo de reinicialização para garantir que o desempenho de inicialização/reinicialização seja aceitável, pois o servidor não está disponível durante esse período. Não é recomendável usar esse parâmetro com menos de 1000 IOPS provisionadas (ou, em outras palavras, quando o armazenamento provisionado for inferior a 335 GB).

Para salvar o estado do pool de buffers no desligamento do servidor, defina o parâmetro innodb_buffer_pool_dump_at_shutdown do servidor como ON. Da mesma forma, defina o parâmetro innodb_buffer_pool_load_at_startup do servidor para ON restaurar o estado do pool de buffers na inicialização do servidor. Você pode controlar o efeito no tempo de inicialização/reinicialização reduzindo e ajustando o valor do parâmetro innodb_buffer_pool_dump_pctserver . Por padrão, esse parâmetro é definido como 25.

Nota

Os parâmetros de aquecimento do pool de buffers InnoDB só são suportados em servidores de armazenamento de uso geral com armazenamento de até 16 TB. Para obter mais informações, consulte Banco de Dados do Azure para opções flexíveis de armazenamento de servidor MySQL.