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 na movimentação de bancos de dados MySQL de ambientes locais para o Banco de Dados do Azure para MySQL. Este artigo aprofunda as tarefas essenciais e as práticas recomendadas 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 informações e estratégias necessárias para gerenciar seus bancos de dados migrados de forma eficaz, enfrentar possíveis desafios e usar os recursos avançados do Azure para otimizar o desempenho e a confiabilidade. Se você pretende melhorar o desempenho do banco de dados, garantir a segurança dos dados ou simplificar as tarefas de manutenção, este artigo o equipa com o conhecimento necessário para obter um gerenciamento pós-migração bem-sucedido.

Pré-requisitos

Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Migração de Dados com o MySQL Workbench

Monitorização 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 gestão incluem as atividades do plano de controlo e do plano de dados. As atividades do plano de controle são aquelas relacionadas aos recursos do Azure versus o plano de dados, que está dentro do recurso do Azure (neste caso, 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 Azure Monitor, Log Analytics e Microsoft Sentinel. Além das ferramentas baseadas no Azure, os sistemas de gerenciamento de eventos e informações de segurança (SIEM) 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 avisar o Azure e os administradores de banco de dados sobre qualquer atividade suspeita. Se um evento de alerta específico tiver um caminho de correção bem definido, os alertas poderão disparar livros de execução automatizados do Azure para abordar o evento.

A primeira etapa para criar um ambiente totalmente monitorado é permitir que os dados de log do MySQL fluam para o Azure Monitor. Referência : Configure e acesse logs de auditoria para o Banco de Dados do Azure para MySQL no portal do Azure para obter mais informações.

Quando 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 não familiarizados com o KQL podem encontrar uma folha de cheat do SQL para KQL aqui ou na 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ê cria 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 oferecer suporte a uma saída rápida. Além disso, foram feitas modificações no Banco de Dados do Azure para parâmetros MySQL para dar suporte a uma entrada rápida. Os parâmetros do servidor do Azure devem ser redefinidos para seus valores otimizados de carga de trabalho local original após a migração.

No entanto, certifique-se de revisar e fazer alterações nos parâmetros do servidor que sejam apropriadas 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 a migração dos parâmetros locais atuais para o Azure, verifique se eles podem de fato ser definidos.

Alguns parâmetros não podem ser modificados no Banco de Dados do Azure para MySQL.

Módulo do 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 usar 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, consulte tutoriais como os seguintes para aprender maneiras de aproveitar o script de suas atividades de gerenciamento:

• Tutorial: Projetar 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 usando o PowerShell

• Aumentar automaticamente o armazenamento no Banco de Dados do Azure para o servidor MySQL usando o PowerShell

• Como criar e gerenciar réplicas de leitura no Banco de Dados do Azure para MySQL usando o PowerShell

• Reinicie o Banco de Dados do Azure para o servidor MySQL usando 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 ou no software MySQL. No entanto, é importante estar ciente de que o processo de atualização pode ser aleatório e, ao ser implantado, pode parar as cargas de trabalho do servidor MySQL. Planeje esses períodos 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.

Nota

Esse estilo de arquitetura de failover pode exigir alterações na camada de dados de 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 só poderá ler dados e poderá falhar quando qualquer operação tentar gravar informações no banco de dados.

O recurso de notificação de manutenção planejada informa os proprietários de recursos com até 72 horas de antecedência da instalação de uma atualização ou patch de segurança crítico. Os administradores de banco de dados podem precisar notificar os usuários do aplicativo sobre manutenção planejada e não planejada.

Nota

As notificações de manutenção do Banco de Dados do Azure para MySQL são incrivelmente importantes. A manutenção do banco de dados pode desativar seu banco de dados e aplicativos conectados por um período de tempo.

Cenário da Primeira Guerra Mundial

A Primeira Guerra Mundial decidiu utilizar os logs de atividade do Azure e permitir que o log do MySQL fluísse para um espaço de trabalho do Log Analytics. Este espaço de trabalho está configurado para fazer parte do Microsoft Sentinel de modo a que quaisquer eventos do Threat Analytics sejam apresentados e incidentes criados.

Os DBAs MySQL instalaram o Banco de Dados do Azure para cmdlets do PowerShell do Azure MySQL para tornar o gerenciamento do Servidor MySQL automatizado em vez de ter que fazer logon no portal do Azure a cada vez.

Lista de verificação de gestão

• Crie alertas de recursos para coisas 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.

• Script de tarefas administrativas comuns.

• Configure notificações para eventos de manutenção, como atualizações e patches. Notifique os usuários conforme necessário.

Próximo passo

Migrar o MySQL local para o Banco de Dados do Azure para MySQL: Otimização