Automigração in-loco do Banco de Dados do Azure para MySQL – de servidor único para servidor flexível
APLICA-SE A:
Banco de Dados do Azure para MySQL – Servidor único
A Automigração in loco do Banco de Dados do Azure para MySQL – Servidor Único para Servidor Flexível é uma migração no local iniciada pelo serviço durante a janela de manutenção planejada para as cargas de trabalho do banco de dados do Servidor Único com SKU de Uso Básico, Geral ou Otimizado para Memória, armazenamento de dados usado <= 20 GiB e nenhum recurso complexo (CMK, AAD, Réplica de Leitura, Link Privado) habilitado. Os servidores qualificados são identificados pelo serviço e recebem uma notificação prévia detalhando as etapas para revisar os detalhes da migração.
A migração in-loco fornece uma experiência de migração offline altamente resiliente e com autorrecuperação durante uma janela de manutenção planejada, com menos de 5 minutos de tempo de inatividade. Ela usa a tecnologia de backup e restauração para um tempo de migração mais rápido. Essa migração remove a sobrecarga para migrar manualmente seu servidor e garantir que você possa aproveitar os benefícios do Servidor Flexível, incluindo melhor preço e desempenho, controle granular sobre a configuração do banco de dados e janelas de manutenção personalizadas. A seguir estão descritas as principais fases da migração:
- O Servidor Flexível de Destino é implantado, herdando todas as propriedades e conjunto de recursos (incluindo parâmetros de servidor e regras de firewall) do Servidor Único de origem. O Servidor Único de origem é definido como somente leitura e o backup do Servidor Único de origem é copiado para o Servidor Flexível de destino.
- A alternância e a substituição de DNS são executadas com êxito dentro da janela de manutenção planejada com tempo de inatividade mínimo, permitindo a manutenção da mesma cadeia de conexão após a migração. Os aplicativos cliente se conectam perfeitamente ao servidor flexível de destino sem atualizações manuais controladas pelo usuário. Além dos formatos de cadeia de conexão (Servidor Único e Flexível) terem suporte no Servidor Flexível migrado, ambos os formatos de nome de usuário – username@server_name e nome de usuário – também têm suporte no Servidor Flexível migrado.
- O Servidor Flexível migrado está online e já pode ser gerenciado por meio do portal/CLI do Azure. O Servidor único interrompido é excluído sete dias após a migração.
Observação
Se sua instância de Servidor Único tiver armazenamento de Uso Geral V1, sua instância agendada passará por uma operação de reinicialização adicional 12 horas antes do horário de migração agendada. Essa operação de reinicialização serve para habilitar o parâmetro de servidor log_bin necessário para atualizar a instância para o armazenamento V2 de Uso Geral antes de passar pela migração automática in-loco.
Qualificação
- Se você possui uma carga de trabalho de Servidor Único com SKU Básica, De Uso Geral ou Otimizado para Memória, armazenamento de dados usado <= 20 GiB e nenhum recurso complexo (CMK, AAD, Réplica de Leitura, Link Privado) habilitado, agora você pode nomear a si mesmo (se ainda não estiver agendado pelo serviço) para migração automática enviando os detalhes do servidor por meio desse formulário.
Configurar alertas de migração e revisar o agendamento de migração
Os servidores qualificados para a automigração in-loco são enviados uma notificação antecipada pelo serviço.
A seguir estão descritas as maneiras de verificar e configurar notificações de automigração:
- Os proprietários de assinaturas para Servidores Únicos agendados para a migração automática recebem uma notificação por email.
- Configure alertas de integridade do serviço para receber notificações de agendamento de migração in-loco e de progresso por email/SMS seguindo estas etapas.
- Verifique a notificação no portal do Azure sobre a migração in-loco seguindo estas etapas.
A seguir estão descritas as maneiras de revisar seu agendamento de migração depois de receber a notificação de migração automática no local:
Observação
O agendamento de migração será bloqueado sete dias antes da janela de migração agendada, após a qual você não poderá reagendar.
- A página de visão geral do Servidor Único para sua instância exibe uma faixa do portal com informações sobre sua agenda de migração.
- Para servidores únicos agendados para a automigração, uma nova folha Migração é acesa no portal. Você pode examinar o agendamento de migração navegando até a folha Migração da instância do Servidor Único.
- Se você quiser adiar a migração, poderá adiar por um mês de cada vez navegando até a folha Migração de sua instância de servidor único no portal do Azure e reagendando a migração selecionando outra janela de migração dentro de um mês.
- Se o servidor único tiver SKU de Uso Geral, você terá a outra opção para habilitar a Alta Disponibilidade ao revisar o agendamento de migração. Como a Alta Disponibilidade só pode ser habilitada durante a criação de um Servidor Flexível do MySQL, é altamente recomendável habilitar esse recurso ao revisar o agendamento de migração.
Verificações de pré-requisito para migração automática no local
- A instância de Servidor Único deve estar em estado pronto e não deve estar no estado interrompido durante a janela de manutenção planejada para que a migração automática ocorra.
- Na instância de Servidor Único com SSL habilitado, verifique se você tem todos os três certificados (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA e DigiCertGlobalRootCA Root CA), disponíveis no repositório raiz confiável. Além disso, se você tiver o certificado fixado na cadeia de conexão, crie um certificado de AC combinado com todos os três certificados antes da migração automática agendada para garantir a continuidade dos negócios após a migração.
- O mecanismo MySQL não garantirá nenhuma ordem de classificação se não houver nenhuma cláusula “SORT” presente em consultas. Após a migração automática in-loco, você poderá observar uma alteração na ordem de classificação. Se preservar a ordem de classificação for crucial, certifique-se de que suas consultas sejam atualizadas para incluir a cláusula “SORT” antes da migração automática in-loco agendada.
- Se o Servidor Único do Banco de Dados do Azure para MySQL de origem tiver a versão do mecanismo v8.x, certifique-se de atualizar a versão do driver do cliente .NET do servidor de origem para 8.0.32 para evitar qualquer incompatibilidade de codificação após a migração para o Servidor Flexível.
- Se o Servidor Único do Banco de Dados do Azure para MySQL de origem tiver nomes de regras de firewall superiores a 80 caracteres, renomeie-os para garantir que o comprimento do nome seja menor que 80 caracteres. (O comprimento do nome da regra de firewall com suporte no Servidor Flexível é de 80 caracteres, enquanto no Servidor Único o comprimento permitido é de 12 8 caracteres.)
Como o Servidor Flexível MySQL de destino é provisionado automaticamente?
A camada de computação e a SKU para o servidor flexível de destino são provisionadas com base na camada de preços do servidor único de origem e nos VCores com base nos detalhes da tabela a seguir.
Tipo de preço do servidor único VCores do servidor único Camada do Servidor Flexível Nome do SKU do Servidor Flexível Basic 1 Com capacidade de intermitência Standard_B1s Basic 2 Com capacidade de intermitência Standard_B2s Uso Geral 4 GeneralPurpose Standard_D4ds_v4 Uso Geral 8 GeneralPurpose Standard_D8ds_v4 Uso Geral 16 GeneralPurpose Standard_D16ds_v4 Uso Geral 32 GeneralPurpose Standard_D32ds_v4 Uso Geral 64 GeneralPurpose Standard_D64ds_v4 Otimizado para memória 4 MemoryOptimized Standard_E4ds_v4 Otimizado para memória 8 MemoryOptimized Standard_E8ds_v4 Otimizado para memória 16 MemoryOptimized Standard_E16ds_v4 Otimizado para memória 32 MemoryOptimized Standard_E32ds_v4 A versão do MySQL, a região, o *tamanho do armazenamento, a assinatura e o grupo de recursos do Servidor Flexível de destino são iguais aos do Servidor Único de origem.
Para servidores únicos com menos de 20 GiB de armazenamento, o tamanho do armazenamento é definido como 20 GiB, pois esse é o limite mínimo de armazenamento em Banco de Dados do Azure para MySQL – Servidor Flexível.
Os formatos de nome de usuário – username@server_name (Servidor Único) e nome de usuário (Servidor Flexível) – têm suporte no Servidor Flexível migrado.
Ambos os formatos de cadeia de conexão – Servidor Único e Servidor Flexível – têm suporte no Servidor Flexível migrado.
Para a instância de Servidor Único com o repositório de consultas habilitado, o parâmetro do servidor 'slow_query_log' na instância de destino está definido como ATIVADO para garantir a paridade de recursos ao migrar para o Servidor Flexível. Para determinadas cargas de trabalho, isso poderá afetar o desempenho e, se você observar alguma degradação no desempenho, defina esse parâmetro do servidor como "DESATIVADO" na instância do Servidor Flexível.
Etapas pós-migração
Observação
Após a migração, não reinicie a instância de Servidor Único interrompida, pois isso pode dificultar a conectividade do cliente e do aplicativo.
- Copie as seguintes propriedades do Servidor Único de origem para que a operação de migração pós-in-loco do Servidor Flexível de destino seja concluída com êxito:
- Configurações de página de monitoramento (alertas, métricas e configurações de diagnóstico)
- Todos os scripts Terraform/CLI hospedados para gerenciar sua instância de Servidor Único devem ser atualizados com referências de Servidor Flexível.
- Para a instância de Servidor Único com o repositório de consultas habilitado, o parâmetro do servidor 'slow_query_log' na instância de destino está definido como ATIVADO para garantir a paridade de recursos ao migrar para o Servidor Flexível. Observe que, para determinadas cargas de trabalho, isso pode afetar o desempenho e, se você observar alguma degradação no desempenho, defina esse parâmetro do servidor como "DESATIVADO" na instância do Servidor Flexível.
- Para a instância de Servidor Único com Proteção Avançada contra Ameaças habilitada, considere configurar as seguintes propriedades após a migração automática na tabela a seguir para manter a paridade à medida que você é migrado automaticamente para o Azure Defender para Nuvem:
| Propriedade | Configuration |
|---|---|
| properties.disabledAlerts | Você pode desabilitar tipos de alerta específicos usando a plataforma Microsoft Defender para Nuvem. Para obter mais informações, consulte o artigo Suprimir alertas do guia do Microsoft Defender para Nuvem. |
| properties.emailAccountAdmins, properties.emailAddresses | Você pode definir centralmente a notificação por email dos Alertas do Microsoft Defender para Nuvem para todos os recursos em uma assinatura. Para obter mais informações, consulte o artigo Início Rápido: configurar notificações por email para alertas de segurança. |
| properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint | A plataforma Microsoft Defender para Nuvem expõe alertas por meio do Azure Resource Graph. Você pode exportar alertas para um repositório diferente e gerenciar a retenção separadamente. Para obter mais informações sobre a exportação contínua, consulte o artigo Configurar a exportação contínua no portal do Azure – Microsoft Defender para Nuvem. |
Perguntas frequentes (FAQs)
Q. Por que estou sendo migrado automaticamente?
a. Sua instância do Banco de Dados do Azure para MySQL – Servidor Único está qualificada para migração in-loco para nossa oferta principal do Banco de Dados do Azure para MySQL – Servidor Flexível. Essa migração in-loco removerá a sobrecarga para migrar manualmente seu servidor e garantir que você possa aproveitar os benefícios do Servidor Flexível, incluindo melhor preço & desempenho, controle granular sobre a configuração do banco de dados e janelas de manutenção personalizadas.
P. Como a automigração ocorre? Quais são todos os itens migrados?
a. O Servidor Flexível é provisionado para corresponder aos mesmos VCores e armazenamento do Servidor Único. Em seguida, o Servidor Único de origem é colocado no estado parado e um instantâneo do arquivo de dados é obtido e copiado para o Servidor Flexível de destino. A alteração de DNS é executada para rotear todas as conexões existentes para o destino, e o Servidor Flexível de destino é colocado online. A migração automática migra todos os arquivos de dados do servidor inteiro (incluindo esquema, dados, logons) além de parâmetros de servidor (todos os parâmetros de servidor modificados na origem são copiados para o destino, parâmetros de servidor não modificados assumem o valor padrão definido pelo Servidor Flexível) e regras de firewall. Esta é uma migração offline em que você vê um tempo de inatividade de até 5 minutos ou menos.
Q. Como posso configurar ou exibir alertas de migração in-loco?
R. A seguir, são apresentadas as formas de se configurar alertas:
- Configure alertas de integridade do serviço para receber notificações de agendamento de migração in-loco e de progresso por email/SMS seguindo as etapas aqui.
- Verifique a notificação de migração in-loco no portal do Azure seguindo as etapas aqui.
Q. Como posso adiar a migração agendada?
a. Você pode examinar o agendamento de migração navegando até a folha Migração da instância do Servidor Único. Se você quiser adiar a migração, poderá adiar por um mês no máximo navegando até a folha Migração de sua instância de servidor único no portal do Azure e agendando novamente a migração selecionando outra janela de migração dentro de um mês. Os detalhes da migração serão bloqueados 7 dias antes da janela de migração agendada, após a qual você não poderá reagendar. Essa migração in-loco pode ser adiada mensalmente até 16 de setembro de 2024.
P. Qual nome de usuário e cadeia de conexão teriam suporte para o Servidor Flexível migrado?
R. Os formatos de nome de usuário – username@server_name (formato de Servidor Único) e nome de usuário (formato de Servidor Flexível) têm suporte para o Servidor Flexível migrado e, portanto, você não precisará atualizá-los para manter a continuidade do aplicativo após a migração. Além disso, os dois formatos de cadeia de conexão (formato de Servidor Único e Flexível) também têm suporte para o Servidor Flexível migrado.
P. Como habilitar a HA (alta disponibilidade) para meu servidor migrado automaticamente??
a. Por padrão, a migração automática configura a migração para uma instância não HA. Como a HA só pode ser habilitada no momento da criação do servidor, você deve habilitar a HA antes da automigração agendada usando a opção de edição de agendamento de automigração no portal. A HA só pode ser habilitada para uso geral\SKUs com otimização de memória no servidor flexível de destino, pois a migração de SKU de básico para com capacidade de intermitência não dá suporte à configuração de HA.
Q. Vejo uma diferença de preços na minha possível mudança do Servidor Único Básico do MySQL para o Servidor Flexível do MySQL??
a. Alguns poucos servidores podem ter um pequeno aumento de preço após a migração (os custos estimados podem ser vistos clicando na opção de edição de agendamento de automigração no portal), pois o limite mínimo de armazenamento em ambas as ofertas é diferente (5 GiB no Servidor Único; 20 GiB no Servidor Flexível) e o custo de armazenamento (US$ 0,1 no Servidor Único; US$ 0,115 no Servidor Flexível) para Servidor Flexível é ligeiramente maior que para Servidor Único. Para servidores afetados, esse aumento de preço no Servidor Flexível fornece melhor taxa de transferência e desempenho em comparação com o Servidor Único