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 na migração de bancos de dados MySQL de ambientes locais para o Banco de Dados do Azure para MySQL. Este artigo aprofunda 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 compreender suas métricas de desempenho existentes, você pode definir expectativas realistas e identificar áreas para melhoria durante o processo de migração. Este guia fornece o conhecimento necessário 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ê pretende otimizar o desempenho da consulta, melhorar a escalabilidade ou garantir uma experiência de usuário consistente, este artigo fornece as informações necessárias para atingir suas metas de desempenho.

Pré-requisitos

Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Planos de teste

Descriçã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 de hardware adequado e de um excelente design de aplicações. Itens como CPU, memória, disco e rede devem ser dimensionados e configurados adequadamente para a carga prevista. O hardware e a configuração fazem parte da equação de desempenho do sistema. O desenvolvedor deve entender a carga de consulta do banco de dados e as consultas mais caras para executar. Concentrar-se 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 aterrissagem do Azure para as cargas de trabalho de dados migradas. A maioria dos sistemas são executados 24 horas por dia, 7 dias por semana e têm diferentes tempos de pico de carga. É 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, exploramos os parâmetros do servidor de origem e como eles são essenciais para a imagem da linha de base de desempenho geral. Os parâmetros do servidor não devem ser ignorados durante um projeto de migração.

Ferramentas

Abaixo estão as ferramentas usadas para reunir métricas do servidor e 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 dimensionamento associadas.

• Telemetria MySQL Enterprise: Esta ferramenta de edição empresarial não gratuita pode fornecer uma lista ordenada das consultas mais caras, métricas do servidor, E/S de arquivos e informações de topologia

• Percona Monitoring and Management (PMM) : a melhor solução de monitoramento de banco de dados de código aberto. Ele ajuda a reduzir a complexidade, otimizar o desempenho e melhorar a segurança de ambientes de banco de dados críticos para os negócios, independentemente do local implantado.

Parâmetros do servidor

As configurações padrão do servidor MySQL podem não suportar adequadamente uma carga de trabalho. Há uma infinidade de parâmetros de servidor no MySQL, mas na maioria dos casos, a equipe de migração deve se concentrar em um punhado. Os seguintes parâmetros devem ser avaliados nos ambientes de origem e de destino . Configurações incorretas podem afetar a velocidade da migração. Revisitamos esses parâmetros novamente quando executamos as etapas de migração.

• innodb_buffer_pool_size: Um valor grande garante 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çar com innodb_log_file_size = 512M (dando 1 GB de logs de refazer) deve dar muito espaço para gravações. Aplicativos com uso intensivo de gravação usando MySQL 5.6 ou superior devem começar com innodb_log_file_size = 4G.

• max_connections: Este parâmetro pode ajudar a aliviar o Too many connections erro. O padrão é 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 também pode precisar aumentar.

• innodb_file_per_table: Essa configuração informa ao InnoDB se ele deve armazenar dados e índices no espaço de tabela compartilhado ou em um arquivo separate.ibd para cada tabela. Ter um arquivo por tabela permite que o servidor recupere espaço quando as tabelas são descartadas, truncadas ou reconstruídas. Os bancos de dados que contêm muitas tabelas não devem usar a tabela por configuração de arquivo. A partir do MySQL 5.6, o valor padrão é ON. As versões anteriores do banco de dados devem definir a configuração como ON antes de carregar os dados. Essa configuração afeta apenas as tabelas recém-criadas.

• innodb_flush_log_at_trx_commit: A configuração padrão de um significa que o InnoDB é totalmente compatível 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 nos logs de refazer. Definir o parâmetro como 2 é um pouco menos confiável porque as transações confirmadas serão liberadas para os logs de refazer apenas uma vez por segundo. O risco pode ser aceitável em algumas situações mestras, e é um bom valor para uma réplica. Um valor de 0 permite um melhor desempenho do sistema, mas o servidor de banco de dados tem maior probabilidade de perder alguns dados durante uma falha. A linha inferior é usar o valor 0 apenas para uma réplica.

• innodb_flush_method: Esta configuração controla como os dados e logs são liberados no disco. Use O_DIRECT quando estiver na presença de um controlador RAID de hardware com um cache de write-back protegido por bateria. Use fdatasync (valor padrão) para outros cenários.

• innodb_log_buffer_size: Esta configuração é o tamanho do buffer para transações que ainda não foram confirmadas. O valor padrão (1 MB) é aceitável. Transações com grandes campos de blob/texto podem preencher rapidamente o buffer e acionar carga de E/S extra. Olhe para a Innodb_log_waits variável de status e, se não for 0, aumente innodb_log_buffer_size.

• query_cache_size: O cache de consultas é um gargalo bem conhecido que pode ser visto durante a simultaneidade moderada. O valor inicial deve ser definido como 0 para desativar o cache, por exemplo, query_cache_size = 0. Este é o padrão no MySQL 5.6 e posterior.

• log_bin: Esta definição permite o registo binário. A habilitação do log binário é obrigatória para que o servidor atue como um mestre de replicação.

• server_id: Essa configuração é exclusiva para servidores de identidade em topologias de replicação.

• expire_logs_days: Esta configuração controla quantos dias os logs binários serão automaticamente limpos.

• skip_name_resolve: usuário para executar a resolução de nome de host do cliente. Se o DNS estiver lento, a conexão será lenta. Ao desativar a resolução de nomes, as instruções GRANT devem usar apenas endereços IP. Quaisquer declarações GRANT anteriores precisariam ser refeitas para usar o PI.

Execute o seguinte comando para exportar os parâmetros do servidor para um arquivo para revisão. Usando alguma análise simples, a saída pode reaplicar os mesmos parâmetros de servidor após a migração, se apropriado, para o Banco de Dados do Azure para o servidor MySQL. Referência : Configure 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 padrão do servidor instalado 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 aterrissagem do Azure após a migração. Se alguma configuração tiver sido modificada do padrão na instância da zona de aterrissagem do Azure de destino, verifique se elas serão redefinidas 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 de parâmetros de servidor que não podem ser configurados, consulte Parâmetros de servidor não configuráveis.

Saída e entrada

Os parâmetros do servidor MySQL de origem e destino devem ser modificados para cada ferramenta de migração de dados e caminho para suportar a 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 do que uma ferramenta de thread único.

Analise todos os parâmetros de tempo limite que possam ser afetados pelos conjuntos de dados. Estes são, entre outros:

• connect_timeout

• wait_timeout

Além disso, revise todos os parâmetros que afetam os máximos:

• max_allowed_packet

Cenário da Primeira Guerra Mundial

A Primeira Guerra Mundial revisou a carga de trabalho do banco de dados da Conferência e determinou que tinha uma pequena carga. Embora um servidor de camada básica funcionasse para eles, eles não queriam executar o trabalho mais tarde para migrar para outra camada. O servidor que está sendo implantado acabará hospedando as outras cargas de trabalho de dados do MySQL, então eles escolheram a General Performance camada.

Ao rever 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.

Próximo passo