Migrar o MySQL local para o Banco de Dados do Azure para MySQL: gerenciamento pós-migração
O gerenciamento pós-migração é crucial para mover bancos de dados MySQL de ambientes locais para o Banco de Dados do Azure para MySQL. Este artigo se aprofunda nas tarefas e práticas recomendadas essenciais para gerenciar seus bancos de dados após a migração. Você pode garantir que seus bancos de dados operem de forma eficiente e segura no ambiente do Azure, concentrando-se no monitoramento, ajuste de desempenho, segurança e manutenção. Este guia fornece insights e estratégias necessárias para gerenciar seus bancos de dados migrados com eficiência, enfrentar possíveis desafios e usar os recursos avançados do Azure para otimizar o desempenho e a confiabilidade. Se você pretende aprimorar o desempenho do banco de dados, garantir a segurança de dados ou simplificar as tarefas de manutenção, este artigo o equipará com o conhecimento para obter um gerenciamento pós-migração bem-sucedido.
Pré-requisitos
Monitoramento e alertas
Depois que a migração for concluída com êxito, a próxima fase será gerenciar os novos recursos de carga de trabalho de dados baseados em nuvem. As operações de gerenciamento incluem atividades do painel de controle e do plano de dados. As atividades do painel de controle são aquelas relacionadas aos recursos do Azure em comparação com o plano de dados, que está dentro do recurso do Azure (neste caso, o MySQL).
O Banco de Dados do Azure para MySQL fornece a capacidade de monitorar esses dois tipos de atividades operacionais usando ferramentas baseadas no Azure, como o Azure Monitor, o Log Analytics e o Microsoft Sentinel. Além das ferramentas baseadas no Azure, os sistemas de SIEM (gerenciamento de eventos e informações de segurança) também podem ser configurados para consumir esses logs.
Seja qual for a ferramenta usada para monitorar as novas cargas de trabalho baseadas em nuvem, os alertas precisam ser criados para alertar o Azure e os administradores de banco de dados de qualquer atividade suspeita. Se um evento de alerta específico tiver um caminho de correção bem definido, os alertas poderão disparar runbooks automatizados do Azure para resolver o evento.
A primeira etapa para criar um ambiente totalmente monitorado é permitir que os dados de log do MySQL fluam para o Azure Monitor. Veja Configurar e acessar os logs de auditoria do Banco de Dados do Azure para MySQL no portal do Azure para obter mais informações.
Depois que os dados de log estiverem fluindo, use a linguagem de consulta KQL (Kusto Query Language) para consultar as várias informações de log. Os administradores que não estão familiarizados com o KQL podem encontrar uma folha de referências de SQL para KQL aqui ou a página Introdução às consultas de log no Azure Monitor.
Por exemplo, para obter o uso de memória do Banco de Dados do Azure para MySQL:
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "memory\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
Para obter o uso da CPU:
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "cpu\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
Depois de criar a consulta KQL, você criará alertas de log com base nessas consultas.
Parâmetros do Servidor
Como parte da migração, é provável que os parâmetros do servidor local tenham sido modificados para dar suporte a uma saída rápida. Além disso, foram feitas modificações nos parâmetros do Banco de Dados do Azure para MySQL para dar suporte a uma entrada rápida. Os parâmetros do servidor do Azure devem ser definidos novamente para os valores originais otimizados para a carga de trabalho local após a migração.
No entanto, não deixe de examinar os parâmetros do servidor e fazer alterações neles de maneira apropriada para a carga de trabalho e o ambiente. Alguns valores que eram ótimos para um ambiente local podem não ser ideais para um ambiente baseado em nuvem. Além disso, ao planejar migrar os parâmetros locais atuais para o Azure, verifique se eles podem, na verdade, ser definidos.
Alguns parâmetros não podem ser modificados no Banco de Dados do Azure para MySQL.
Módulo PowerShell
O portal do Azure e o Windows PowerShell podem ser usados para gerenciar o Banco de Dados do Azure para MySQL. Para começar a trabalhar com o PowerShell, instale os cmdlets do Azure PowerShell para MySQL com o seguinte comando do PowerShell:
Install-Module -Name Az.MySql
Depois que os módulos forem instalados, veja tutoriais como o seguinte para aprender maneiras de aproveitar o script das suas atividades de gerenciamento:
Tutorial: Criar um Banco de Dados do Azure para MySQL usando o PowerShell
Como fazer backup e restaurar um banco de dados do Azure para o servidor MySQL usando o PowerShell
Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL com o PowerShell
Como criar e gerenciar réplicas de leitura no Banco de Dados do Azure para MySQL com o PowerShell
Reiniciar um servidor do Banco de Dados do Azure para MySQL com o PowerShell
Processo de atualização do Banco de Dados do Azure para MySQL
Como o Banco de Dados do Azure para MySQL é uma oferta de PaaS, os administradores não são responsáveis pelo gerenciamento das atualizações no sistema operacional nem do software MySQL. No entanto, é importante estar ciente de que o processo de atualização pode ser aleatório e, ao ser implantado, interromperá as cargas de trabalho do servidor do MySQL. Planeje esses tempos de inatividade redirecionando as cargas de trabalho para uma réplica de leitura caso a instância específica entre no modo de manutenção.
Observação
Esse estilo de arquitetura de failover pode exigir alterações na camada de dados dos aplicativos para dar suporte a esse tipo de cenário de failover. Se a réplica de leitura for mantida como uma réplica de leitura e não for promovida, o aplicativo poderá apenas ler dados e poderá falhar quando qualquer operação tentar gravar informações no banco de dados.
O recurso Notificação de manutenção planejada informa os proprietários de recursos no prazo de até 72 horas antes da instalação de um patch de segurança crítico ou de atualização. Os administradores de banco de dados podem precisar notificar os usuários do aplicativo sobre manutenção planejada e não planejada.
Observação
As notificações de manutenção do Banco de Dados do Azure para MySQL são extremamente importantes. A manutenção do banco de dados pode deixar seu banco de dados e os aplicativos conectados inativos por um tempo.
Cenário da WWI
A WWI decidiu utilizar os logs de atividades do Azure e habilitar o log do MySQL para o fluxo para um workspace do Log Analytics. Esse workspace está configurado para fazer parte do Azure Sentinel para que os eventos de Análise de Ameaças sejam exibidos e os incidentes criados.
Os DBAs do MySQL instalaram os cmdlets do Azure PowerShell para o Banco de Dados do Azure para MySQL a fim de tornar o gerenciamento do MySQL Server automatizado em comparação com a necessidade de fazer logon no portal do Azure a cada vez.
Lista de verificação de gerenciamento
Crie alertas de recursos para itens comuns, como CPU e memória.
Verifique se os parâmetros do servidor estão configurados para a carga de trabalho de dados de destino após a migração.
Gere scripts de tarefas administrativas comuns.
Configurar notificações para eventos de manutenção, como atualizações e patches. Notificar os usuários, conforme necessário.