Migrar o MySQL local para o Banco de Dados do Azure para MySQL – Linhas de base de desempenho
Estabelecer linhas de base de desempenho é vital ao migrar bancos de dados para MySQL de ambientes locais para o Banco de Dados do Azure para MySQL. Este artigo aborda a importância das linhas de base de desempenho, fornecendo um guia detalhado sobre como medir e analisar o desempenho atual do banco de dados. Ao entender suas métricas de desempenho existentes, você pode definir expectativas realistas e identificar áreas de melhoria durante o processo de migração. Este guia o equipa com o conhecimento para criar linhas de base de desempenho precisas, garantindo que seus bancos de dados migrados atendam ou excedam seus níveis de desempenho atuais no ambiente do Azure. Se você quer otimizar o desempenho da consulta, aprimorar a escalabilidade ou garantir uma experiência consistente do usuário, este artigo fornece os insights necessários para atingir suas metas de desempenho.
Pré-requisitos
Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Planos de Teste
Visão geral
Entender a carga de trabalho existente do MySQL é um dos melhores investimentos que podem ser feitos para garantir uma migração bem-sucedida. O excelente desempenho do sistema depende do hardware adequado e de um design de aplicativo excelente. Itens como CPU, memória, disco e rede devem ser dimensionados e configurados adequadamente para a carga prevista. Hardware e configuração fazem parte da equação de desempenho do sistema. O desenvolvedor precisa entender a carga de consulta do banco de dados e as consultas mais caras a serem executadas. O foco nas consultas mais caras pode afetar substancialmente as métricas gerais de desempenho.
A criação de linhas de base de desempenho de consulta é vital para um projeto de migração. As linhas de base de desempenho podem ser usadas para verificar a configuração da zona de destino do Azure para as cargas de trabalho de dados migradas. A maioria dos sistemas será executada 24 horas por dia, sete dias por semana e tem diferentes horários de carga de pico. É importante capturar as cargas de trabalho de pico para a linha de base. As métricas são capturadas várias vezes. Mais adiante no documento, exploraremos os parâmetros do servidor de origem e como eles são essenciais para o cenário de linha de base de desempenho geral. Os parâmetros do servidor não devem ser ignorados durante um projeto de migração.
Ferramentas
Veja abaixo as ferramentas usadas para coletar as métricas do servidor e as informações de carga de trabalho do banco de dados. Use as métricas capturadas para determinar o Banco de Dados do Azure apropriado para a camada MySQL e as opções de escala associadas.
Telemetria MySQL Enterprise: essa ferramenta de edição empresarial não gratuita pode fornecer uma lista classificada das consultas, métricas de servidor, E/S de arquivo e informações de topologia mais dispendiosas
PMM (Percona Monitoring and Management): uma das soluções de software livre mais avançadas de monitoramento de banco de dados. Ela ajuda a reduzir a complexidade, otimizar o desempenho e aprimorar a segurança de ambientes de banco de dados comercialmente críticos, independentemente da localização implantada.
Parâmetros do Servidor
As configurações padrão do servidor MySQL podem não dar suporte adequado a uma carga de trabalho. Há uma grande quantidade de parâmetros de servidor no MySQL, mas, na maioria dos casos, a equipe de migração deve se concentrar em alguns. Os parâmetros a seguir devem ser avaliados nos ambientes de origem e de destino. Configurações incorretas podem afetar a velocidade da migração. Vamos revisitar esses parâmetros novamente quando executarmos as etapas de migração.
innodb_buffer_pool_size: um valor alto garantirá que os recursos na memória sejam usados primeiro antes de utilizar a E/S de disco. Os valores típicos variam de 80 a 90% da memória disponível. Por exemplo, um sistema com 8 GB de memória deve alocar de 5 a 6 GB para o tamanho do pool.
innodb_log_file_size: os logs de refazer garantem gravações rápidas e duráveis. Esse backup transacional é útil durante uma falha do sistema. Começando com innodb_log_file_size = 512M (dando 1 GB de logs de refazer) deve oferecer muito espaço para gravações. Aplicativos com uso intensivo de gravação que usam o MySQL 5.6 ou superior devem começar com innodb_log_file_size = 4G.
max_connections: esse parâmetro pode ajudar a atenuar o erro
Too many connections. O valor padrão é de 151 conexões. É preferível usar um pool de conexões no nível do aplicativo, mas a configuração de conexão do servidor talvez também precise ser aumentada.innodb_file_per_table: essa configuração informará ao InnoDB se ele deve armazenar dados e índices no espaço de tabela compartilhado ou em um arquivo .ibd separado para cada tabela. Ter um arquivo por tabela permite que o servidor recupere espaço quando as tabelas são removidas, truncadas ou recriadas. Bancos de dados que contêm muitas tabelas não devem usar a tabela por configuração de arquivo. Do MySQL 5.6 em diante, o valor padrão é ON. As versões anteriores do banco de dados devem definir a configuração como ON antes do carregamento de dados. Essa configuração só afeta as tabelas recém-criadas.
innodb_flush_log_at_trx_commit: a configuração padrão de um significa que o InnoDB está em total conformidade com ACID. Essa configuração de transação de menor risco pode ter uma sobrecarga significativa em sistemas com discos lentos devido às sincronizações extras necessárias para liberar cada alteração para os logs de refazer. A definição do parâmetro como 2 é um pouco menos confiável, porque as transações confirmadas serão liberadas para os logs de restauração apenas uma vez por segundo. O risco pode ser aceitável em algumas situações de mestre e é um bom valor para uma réplica. Um valor igual a 0 permite um melhor desempenho do sistema, mas o servidor de banco de dados apresenta maior probabilidade de perder alguns dados durante uma falha. Na linha inferior, use o valor 0 somente para uma réplica.
innodb_flush_method: essa configuração controla como os dados e os logs são liberados para o disco. Use
O_DIRECTquando estiver na presença de um controlador RAID de hardware com um cache de write-back protegido por bateria. Usefdatasync(valor padrão) para outros cenários.innodb_log_buffer_size: essa configuração é o tamanho do buffer para transações que ainda não foram confirmadas. O valor padrão (1 MB) é aceitável. As transações com campos grandes de blob/texto podem preencher o buffer rapidamente e disparar uma carga extra de E/S. Veja a variável de status
Innodb_log_waitse, se não for 0, aumenteinnodb_log_buffer_size.query_cache_size: o cache de consulta é um gargalo conhecido que pode ser visto durante a simultaneidade moderada. O valor inicial deve ser definido como 0 para desabilitar o cache, por exemplo, query_cache_size = 0. Esse é o padrão no MySQL 5.6 e posterior.
log_bin: essa configuração habilita o registro em log binário. A habilitação do log binário é obrigatória se o servidor precisa funcionar como um mestre de replicação.
server_id: essa configuração é exclusiva para servidores de identidade em topologias de replicação.
expire_logs_days: essa configuração controla o número de dias em que os logs binários serão automaticamente limpos.
skip_name_resolve: usuário que executará a resolução de nome do host do cliente. Se o DNS estiver lento, a conexão será lenta. Na desabilitação da resolução de nomes, as instruções GRANT precisam usar apenas endereços IP. Todas as instruções GRANT feitas anteriormente precisarão ser refeitas para usar o IP.
Execute o comando a seguir para exportar os parâmetros do servidor para um arquivo para análise. Usando algumas análises simples, a saída pode reaplicar os mesmos parâmetros de servidor após a migração, se apropriado, ao servidor do Banco de Dados do Azure para MySQL. Veja Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL usando o portal do Azure.
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
Os parâmetros de servidor instalado padrão do MySQL 5.5.60 podem ser encontrados no apêndice.
Antes do início da migração, exporte as definições de configuração do MySQL de origem. Compare esses valores com as configurações da instância da zona de destino do Azure após a migração. Se alguma configuração tiver sido modificada em relação ao padrão na instância da zona de destino do Azure, certifique-se de que ela seja definida novamente após a migração. Além disso, o usuário de migração deve verificar se os parâmetros do servidor podem ser definidos antes da migração.
Para obter uma lista dos parâmetros de servidor que não podem ser configurados, veja Parâmetros de servidor não configuráveis.
Entrada e saída
Os parâmetros do servidor MySQL de origem e de destino devem ser modificados para cada ferramenta e caminho de migração de dados respectivos para dar suporte à saída e entrada mais rápidas possíveis. Dependendo da ferramenta, os parâmetros podem ser diferentes. Por exemplo, uma ferramenta que executa uma migração em paralelo pode precisar de mais conexões entre a origem e o destino versus uma ferramenta de thread único.
Revise os parâmetros de tempo limite que poderão ser afetados pelos conjuntos de dados. Estão incluídos:
Além disso, revise os parâmetros que afetam os máximos:
Observação
Um erro comum de migração é MySQL server has gone away. Os parâmetros mencionados costumam ser os responsáveis por resolver esse erro.
Cenário da WWI
A WWI revisou a carga de trabalho do banco de dados de conferência e determinou que tinha uma carga pequena. Embora um servidor de camada básica funcione para eles, eles não queriam executar o trabalho posteriormente para migrar para outra camada. O servidor que está sendo implantado acabará hospedando as outras cargas de trabalho de dados do MySQL e, portanto, escolheram a camada General Performance.
Ao revisar o banco de dados MySQL, descobri que o servidor MySQL 5.5 é executado com os parâmetros de servidor padrão definidos durante a instalação inicial.