Share via

Migração automática no local da Base de Dados do Azure para MySQL - Servidor Único para Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

A migração automática in-loco do Banco de Dados do Azure para MySQL – Servidor Único para Servidor Flexível é uma migração in-loco iniciada por serviço durante a janela de manutenção planejada para cargas de trabalho de banco de dados de Servidor Único com SKU Básico, de Uso Geral ou Otimizado para Memória, armazenamento de dados usado< = 20 GiB e sem recursos complexos (CMK, AAD, Réplica de Leitura, Link Privado) habilitados. Os servidores elegíveis são identificados pelo serviço e são enviados passos de detalhes de notificação antecipada para rever os detalhes da migração.

A migração in-loco oferece uma experiência de migração offline altamente resiliente e autorrecuperável durante uma janela de manutenção planejada, com menos de 5 minutos de tempo de inatividade. Ele usa tecnologia de backup e restauração para um tempo de migração mais rápido. Essa migração elimina 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 todo o conjunto de recursos e propriedades (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.
  • O switch DNS e a substituição são executados com sucesso dentro da janela de manutenção planejada com o mínimo de tempo de inatividade, permitindo a manutenção da mesma cadeia de conexão pós-migração. Os aplicativos cliente se conectam perfeitamente ao servidor flexível de destino sem atualizações manuais orientadas pelo usuário. Além de ambos os formatos de cadeia de conexão (Servidor Único e Servidor Flexível) serem suportados no Servidor Flexível migrado, ambos os formatos de nome de usuário – username@server_name e nome de usuário também são suportados no Servidor Flexível migrado.
  • O Servidor Flexível migrado está online e agora pode ser gerenciado por meio do portal/CLI do Azure. O Servidor Único Parado é excluído sete dias após a migração.

Nota

Se a instância do Servidor Único tiver armazenamento V1 de uso geral, a instância agendada passará por uma operação de reinicialização adicional 12 horas antes do horário de migração agendado. 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.

Elegibilidade

  • Se você possui uma carga de trabalho de Servidor Único com SKU Básico, de Uso Geral ou Otimizado para Memória, armazenamento de dados usado <= 20 GiB e sem recursos complexos (CMK, AAD, Réplica de Leitura, Link Privado) habilitados, agora você pode se nomear (se ainda não estiver agendado pelo serviço) para migração automática enviando os detalhes do servidor por meio deste formulário.

Configurar alertas de migração e revisar o cronograma de migração

Os servidores elegíveis para a migração automática in-loco recebem uma notificação prévia do serviço.

A seguir estão descritas as maneiras de verificar e configurar notificações de migração automática:

  • Os proprietários de assinaturas de Servidores Únicos agendados para migração automática recebem uma notificação por e-mail.
  • Configure alertas de integridade do serviço para receber agendamento de migração in-loco e notificações de progresso por e-mail/SMS seguindo as etapas aqui.
  • Verifique a notificação de migração in-loco no portal do Azure seguindo as etapas aqui.

A seguir estão descritas as maneiras de revisar seu cronograma de migração depois de receber a notificação de migração automática in-loco:

Nota

A agenda de migração será bloqueada 7 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 um banner do portal com informações sobre sua agenda de migração.
  • Para Servidores Únicos agendados para migração automática, uma nova folha Migração é acesa no portal. Pode rever a agenda de migração ao navegar para o painel Migração da instância do Servidor Único.
  • Se desejar adiar a migração, você pode 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 seu Servidor Único tiver SKU de Uso Geral, você terá a outra opção para habilitar a Alta Disponibilidade ao revisar o cronograma de migração. Como a Alta Disponibilidade só pode ser ativada durante o tempo de criação de um Servidor Flexível MySQL, é altamente recomendável que você habilite esse recurso ao revisar o cronograma de migração.

Verificações de pré-requisitos para migração automática in-loco

  • A instância do Servidor Único deve estar no 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.
  • Para instância de servidor único com SSL habilitado, certifique-se de ter todos os três certificados (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA e DigiCertGlobalRootCA Root CA) disponíveis no armazenamento raiz confiável. Além disso, se você tiver o certificado fixado à cadeia de conexão, crie um certificado de CA combinado com todos os três certificados antes da migração automática agendada para garantir a continuidade de negócios pós-migração.
  • O mecanismo MySQL não garante nenhuma ordem de classificação se não houver nenhuma cláusula 'SORT' presente nas consultas. Após a migração automática in-loco, você pode 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 Banco de Dados do Azure de origem para MySQL Single Server 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 incompatibilidades de codificação após a migração para o Servidor Flexível.
  • Se o Banco de Dados do Azure de origem para MySQL Single Server tiver nomes de regra de firewall superiores a 80 caracteres, renomeie-os para garantir que o comprimento do nome seja inferior a 80 caracteres. (O comprimento do nome da regra de firewall suportado no Servidor Flexível é de 80 caracteres, enquanto no Servidor Único o comprimento permitido é de 12, 8 caracteres.)
  • Se o Banco de Dados do Azure de origem para MySQL Single Server utilizar portas não padrão, como 3308,3309 e 3310, altere sua porta de conectividade para 3306, pois as portas não padrão mencionadas acima não são suportadas no Servidor Flexível.

Como o MySQL Flexible Server 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 VCores com base nos detalhes da tabela a seguir.

    Escalão de Preço do Servidor Único VCores de Servidor Único Camada de servidor flexível Nome SKU flexível do servidor
    Básica 1 Expansível Standard_B1s
    Básica 2 Expansível Standard_B2s
    Fins Gerais 4 GeneralPurpose Standard_D4ds_v4
    Fins Gerais 8 GeneralPurpose Standard_D8ds_v4
    Fins Gerais 16 GeneralPurpose Standard_D16ds_v4
    Fins Gerais 32 GeneralPurpose Standard_D32ds_v4
    Fins Gerais 64 GeneralPurpose Standard_D64ds_v4
    Otimizada para Memória 4 MemóriaOtimizado Standard_E4ds_v4
    Otimizada para Memória 8 MemóriaOtimizado Standard_E8ds_v4
    Otimizada para Memória 16 MemóriaOtimizado Standard_E16ds_v4
    Otimizada para Memória 32 MemóriaOtimizado Standard_E32ds_v4

  • A versão, região, *tamanho de armazenamento, assinatura e grupo de recursos do MySQL para o Servidor Flexível de destino é igual ao 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 no Banco de Dados do Azure para MySQL - Servidor Flexível.

  • Ambos os formatos de nome de usuário – username@server_name (Servidor Único) e nome de usuário (Servidor Flexível) são suportados no Servidor Flexível migrado.

  • Ambos os formatos de cadeia de conexão – Servidor Único e Servidor Flexível são suportados no Servidor Flexível migrado.

  • Para instância de Servidor Único com armazenamento de Consulta habilitado, o parâmetro de servidor 'slow_query_log' na instância de destino é definido como ON para garantir a paridade de recursos ao migrar para o Servidor Flexível. Para determinadas cargas de trabalho, isso pode afetar o desempenho e, se você observar qualquer degradação de desempenho, defina esse parâmetro de servidor como 'OFF' na instância do Servidor flexível.

Passos pós-migração

Nota

Após a migração, não reinicie a instância do Servidor Único interrompida, pois isso pode prejudicar 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:
    • Monitorando as configurações da página (Alertas, Métricas e Configurações de diagnóstico)
    • Todos os scripts Terraform/CLI que você hospeda para gerenciar sua instância de Servidor Único devem ser atualizados com referências de Servidor Flexível.
  • Para instância de Servidor Único com armazenamento de Consulta habilitado, o parâmetro de servidor 'slow_query_log' na instância de destino é definido como ON 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 qualquer degradação de desempenho, defina esse parâmetro de servidor como 'OFF' na instância do Servidor Flexível.
  • Para instância de Servidor Único com a 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ê migra automaticamente para o Azure Defender for Cloud :
Propriedade Configuração
properties.disabledAlertas Você pode desabilitar tipos de alerta específicos usando a plataforma Microsoft Defender for Cloud. Para obter mais informações, consulte o artigo Guia Suprimir alertas do Microsoft Defender for Cloud.
properties.emailAccountAdmins, properties.emailAddresses Você pode definir centralmente a notificação por email para o Microsoft Defender for Cloud Alerts para todos os recursos em uma assinatura. Para obter mais informações, consulte o artigo Guia de início rápido: configurar notificações por email para alertas de segurança.
properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint A plataforma Microsoft Defender for Cloud expõe alertas através do Azure Resource Graph. Você pode exportar alertas para um armazenamento 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 for Cloud.

Perguntas mais frequentes (FAQs)

P. Por que estou sendo migrado automaticamente?

A. O seu Base de Dados do Azure para MySQL – a instância do Servidor Único é elegível para migração no local para a nossa oferta principal Base de Dados do Azure para MySQL – Servidor Flexível. Esta migração no local removerá a sobrecarga para migrar manualmente o servidor e garantirá que pode tirar partido das vantagens do Servidor Flexível, incluindo um melhor preço e desempenho, controlo granular sobre a configuração da base de dados e janelas de manutenção personalizadas.

P. Como ocorre a automigração? O que tudo isso migra?

A. O Servidor Flexível é aprovisionado para corresponder aos mesmos VCores e armazenamento do servidor único. Em seguida, o Servidor Único de origem é colocado no estado parado, o instantâneo do ficheiro de dados é tirado e copiado para o Servidor Flexível de destino. O comutador DNS é executado para encaminhar todas as ligações existentes para o destino e o Servidor Flexível de destino é colocado online. A migração automática migra os ficheiros de dados de todo o servidor (incluindo esquema, dados, inícios de sessão) para além dos parâmetros do servidor (todos os parâmetros de servidor modificados na origem são copiados para parâmetros de servidor de destino e não modificados ocupam o valor predefinido definido pelo Servidor Flexível) e as regras de firewall. Esta é uma migração offline onde vê um período de indisponibilidade de até 5 minutos ou menos.

P. Como posso configurar ou visualizar alertas de migração in-loco?

A. Seguem-se as formas de configurar alertas:

  • Configure alertas de integridade do serviço para receber agendamento de migração in-loco e notificações de progresso por e-mail/SMS seguindo as etapas aqui.
  • Verifique a notificação de migração in-loco no portal do Azure seguindo as etapas aqui.

P. Como posso adiar a migração agendada?

A. Pode rever a agenda de migração ao navegar para o painel Migração da instância do Servidor Único. Se quiser adiar a migração, pode adiar por um mês no máximo ao navegar para o painel Migração da instância do servidor único no portal do Azure e agendar novamente a migração ao selecionar outra janela de migração no prazo 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. Esta migração no local pode ser adiada mensalmente até 16 de setembro de 2024.

P. Que nome de utilizador e cadeia de ligação seriam suportados para o Servidor Flexível migrado? ​​

A. Ambos os formatos de nome de usuário - username@server_name (formato de servidor único) e nome de usuário (formato de servidor flexível) são suportados para o servidor flexível migrado e, portanto, você não precisa atualizá-los para manter a continuidade do aplicativo após a migração. Além disso, ambos os formatos de cadeia de conexão (formato de servidor único e flexível) também são suportados para o servidor flexível migrado.

P. Como ativar HA (High Availability) para o meu servidor auto-migrado?

A. Por predefinição, a migração automática configura a migração para uma instância não HA. Uma vez que a HA só pode ser ativada no tempo de criação do servidor, deve ativar a HA antes da atualização automática agendada através da opção de edição de agenda de atualização automática no portal. A HA só pode ser ativada para FINS Gerais\SKUs Otimizados para Memória no Servidor Flexível de destino, uma vez que a migração de SKU Básico para Expansível não suporta a configuração ha.

P. Eu vejo uma diferença de preço na minha potencial mudança do MySQL Basic Single Server para o MySQL Flexible Server?

A. Poucos servidores poderão ver 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 agenda de migração automática no portal), uma vez que 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 (0,1$ no Servidor Único; 0,115$ no Servidor Flexível) para Servidor Flexível é ligeiramente superior ao Servidor Único. Para os servidores afetados, este aumento de preços no Servidor Flexível proporciona um melhor débito e desempenho em comparação com o Servidor Único

Próximos passos