Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
A otimização de bancos de dados MySQL após a migração de ambientes locais para o Banco de Dados do Azure para MySQL é essencial para maximizar o desempenho e a eficiência. Este artigo explora as principais estratégias e práticas recomendadas para otimizar seus bancos de dados no ambiente do Azure. Você pode garantir que seus bancos de dados operem em seu potencial máximo, concentrando-se no desempenho da consulta, indexação, alocação de recursos e ajuste de configuração. Este guia fornece as informações e técnicas necessárias para identificar e resolver gargalos de desempenho, usar os recursos avançados do Azure e obter o desempenho ideal do banco de dados. Se você pretende melhorar os tempos de resposta, melhorar a escalabilidade ou reduzir os custos operacionais, este artigo o equipa com o conhecimento para otimizar seus bancos de dados MySQL no Azure.
Pré-requisitos
Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Gerenciamento Pós-Migração
Monitore o desempenho do hardware e da consulta
Além dos logs de auditoria e atividade, o desempenho do servidor também pode ser monitorado com o Azure Metrics. As métricas do Azure são fornecidas em uma frequência de um minuto e os alertas podem ser configurados a partir delas. Para obter mais informações, consulte Monitoramento no Banco de Dados do Azure para MySQL para obter detalhes sobre que tipo de métricas podem ser monitoradas.
Como mencionado anteriormente, o monitoramento de métricas como o cpu_percent ou memory_percent pode ser importante ao decidir atualizar a camada de banco de dados. Valores consistentemente altos podem indicar que uma atualização de camada é necessária.
Além disso, se a CPU e a memória não parecerem ser o problema, os administradores poderão explorar opções baseadas em banco de dados, como indexação e modificações de consulta para consultas de baixo desempenho.
Para encontrar consultas com baixo desempenho, execute o seguinte:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
Informações sobre o desempenho da consulta
Além dos aspetos básicos de monitoramento do servidor, o Azure fornece ferramentas para monitorar o desempenho da consulta do aplicativo. Corrigir ou melhorar consultas pode levar a aumentos significativos na taxa de transferência da consulta. Use a ferramenta Query Performance Insight para analisar as consultas de execução mais longa e determinar se é possível armazenar esses itens em cache se eles forem determinísticos dentro de um período definido ou modificar as consultas para aumentar seu desempenho.
O slow\_query\_log pode ser configurado para mostrar consultas lentas nos arquivos de log do MySQL (o padrão é OFF). O long\_query\_time parâmetro server pode alertar os usuários para longos tempos de consulta (o padrão é 10 segundos).
Atualizar a camada
O portal do Azure pode ser usado para dimensionar entre de General Purpose e Memory Optimized. Se uma Basic camada for escolhida, não há opção de atualizar a camada para General Purpose ou Memory Optimized posteriormente. No entanto, é possível utilizar outras técnicas para executar uma migração/atualização para uma nova instância do Banco de Dados do Azure para MySQL.
Para obter um exemplo de um script que migra de camadas básicas para outra camada de servidor, consulte Atualização de camadas básicas para fins gerais ou Otimização de memória no Banco de Dados do Azure para MySQL.
Dimensionar o servidor
Dentro da camada, é possível dimensionar núcleos e memória para os limites mínimo e máximo permitidos nessa camada. Se o monitoramento mostrar um esgotamento contínuo da CPU ou da memória, siga as etapas para aumentar a escala para atender à sua demanda.
Mover regiões
Mover um banco de dados para uma região diferente do Azure depende da abordagem e da arquitetura. Dependendo da abordagem, isso pode causar tempo de inatividade do sistema.
O processo recomendado é o mesmo que utilizar réplicas de leitura para failover de manutenção. No entanto, em comparação com o método de manutenção planejada mencionado acima, a velocidade para failover é mais rápida quando uma camada de failover foi implementada no aplicativo. O aplicativo só deve ficar inativo por alguns momentos durante o processo de failover da réplica de leitura. Mais detalhes são abordados na seção Continuidade de negócios e recuperação de desastres.
Cenário da Primeira Guerra Mundial
Os usuários de negócios e aplicativos da Primeira Guerra Mundial expressaram um alto nível de entusiasmo em relação à capacidade de dimensionar o banco de dados sob demanda. Eles também estavam interessados em usar o Query Performance Insight para determinar se o desempenho de consultas de longa duração precisava ser resolvido.
Eles optaram por utilizar um servidor de réplica de leitura para qualquer possível failover ou cenários somente leitura necessários.
A equipe de migração, trabalhando com os engenheiros do Azure, configurou consultas KQL para monitorar possíveis problemas com o desempenho do servidor MySQL. As consultas KQY foram configuradas com alertas para problemas de eventos por e-mail para o banco de dados e a equipe da conferência.
Eles optaram por monitorar quaisquer problemas potenciais por enquanto e implementar livros de execução da Automação do Azure posteriormente, se necessário, para melhorar a eficiência operacional.
Lista de verificação de otimização
Monitore consultas lentas.
Revise periodicamente o painel do Performance Insight.
Utilize o monitoramento para impulsionar atualizações de nível e decisões de dimensionamento.
Considere a mudança de regiões dos usuários ou das necessidades do aplicativo.