Migrar MySQL – Servidor flexível para suporte à zona de disponibilidade
Este guia descreve como migrar o MySQL – Servidor Flexível do suporte à zona de indisponibilidade para o suporte à zona de disponibilidade.
Você pode configurar o Banco de Dados do Azure para o Servidor Flexível MySQL para usar um dos dois modelos de arquitetura de alta disponibilidade (HA):
Arquitetura HA da mesma zona (zonal). Essa opção é recomendada para redundância de infraestrutura com latência de rede mais baixa, pois o servidor primário e os servidores em espera estarão na mesma zona de disponibilidade. Ela oferece alta disponibilidade sem a necessidade de configurar a redundância do aplicativo entre as zonas. A HA na mesma zona é recomendada quando você deseja obter o nível mais alto de disponibilidade em uma só zona de disponibilidade com a latência de rede mais baixa. A HA na mesma zona está disponível em todas as regiões do Azure nas quais é possível usar o Banco de Dados do Azure para MySQL – Servidor flexível. Para saber mais sobre a arquitetura HA da mesma zona, consulte Arquitetura HA da mesma zona.
Arquitetura HA com redundância de zona. Essa opção é recomendada para isolamento completo e redundância da infraestrutura entre várias zonas de disponibilidade. Ela oferece o nível mais alto de disponibilidade, mas exige que você configure a redundância do aplicativo entre as zonas. A HA com redundância de zona é recomendada quando você deseja obter o nível mais alto de disponibilidade para qualquer falha de infraestrutura na zona de disponibilidade e quando a latência na zona de disponibilidade é aceitável. Ela pode ser habilitada somente quando o servidor é criado. A HA com redundância de zona está disponível em um subconjunto de regiões do Azure em que a região oferece suporte a várias zonas de disponibilidade e compartilhamentos de arquivos Premium com redundância de zona estão disponíveis. Para saber mais sobre a arquitetura HA com redundância de zona, consulte Arquitetura HA com redundância de zona.
Para migrar sua carga de trabalho existente de HA zonal (HA de mesma zona) para HA com redundância de zona, você precisará fazer o seguinte:
Implante e configure um novo servidor que tenha sido configurado para HA com redundância de zona.
Siga as diretrizes de migração neste documento para mover seus recursos para o novo servidor.
Pré-requisitos
Para migrar para o suporte à zona de disponibilidade:
Você precisará de pelo menos um dos dois servidores a seguir:
Um servidor de origem que está executando o Banco de Dados do Azure para MySQL Flexible Server em uma região que não oferece suporte a zonas de disponibilidade.
Um Banco de Dados do Azure para Servidor Flexível MySQL que não estava habilitado para HA no momento da criação.
Importante
Se você provisionou originalmente seu Banco de Dados do Azure para MySQL Flexible Server como um servidor não-HA, você pode simplesmente habilitá-lo para a arquitetura HA da mesma zona. No entanto, se você quiser habilitá-lo para a arquitetura HA com redundância de zona, será necessário implementar uma das opções de migração disponíveis listadas neste artigo.
Você precisará criar um servidor de destino que esteja executando o Banco de Dados do Azure para MySQL Flexible Server em uma região que ofereça suporte a zonas de disponibilidade. Para obter mais informações sobre como criar um Banco de Dados do Azure para o Servidor Flexível MySQL, consulte Usar o portal do Azure para criar um Banco de Dados do Azure para o Servidor Flexível MySQL. Certifique-se de que o servidor criado esteja configurado para redundância de zona habilitando HA e selecionando a opção Zone-Redundant .
Dica
Se você quiser a flexibilidade de poder se mover entre HA zonal (mesma zona) e HA redundante de zona no futuro, poderá provisionar seu Banco de Dados do Azure para o Servidor Flexível MySQL com HA redundante de zona habilitada durante a criação do servidor. Depois que o servidor for provisionado, você poderá desabilitar a HA.
Requisitos de tempo de inatividade
As migrações podem ser categorizadas como online ou offline:
• Migração offline. Se o aplicativo pode arcar com tempo de inatividade, as migrações offline sempre são a escolha de preferência, pois são simples e fáceis de executar. Com uma migração offline, o servidor de origem é colocado offline e um despejo e restaurações dos bancos de dados são executados no servidor de destino. Essa opção exigirá mais tempo de inatividade. A duração do tempo de inatividade é determinada pelo tempo necessário para executar a restauração no servidor de destino.
• Migração online. Essa opção tem um tempo de inatividade mínimo e é a melhor escolha se você quiser menos tempo de inatividade. O servidor de origem permite atualizações, e a solução de migração se encarregará de replicar as alterações em andamento entre o servidor de origem e de destino, juntamente com o despejo inicial e a restauração no destino.
Opção de migração 1: migração offline
Você pode migrar de um Banco de Dados do Azure para Servidor Flexível para outro usando uma das ferramentas a seguir. Ambas as opções exigirão tempo de inatividade.
Serviço de Migração de Dados (DMS). Para saber como migrar o MySQL Flexible Server para outro com DMS, consulte Migrate Azure Database for MySQL - Single Server to Flexible Server offline using DMS through the Azure portal. Embora o tutorial descreva as etapas para migrar do Servidor Único MySQL do Azure para o Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Banco de Dados do Azure para Servidor Flexível MySQL que não oferece suporte a zonas de disponibilidade para outro que ofereça suporte a zonas de disponibilidade.
Ferramentas de código aberto. Você pode migrar offline com ferramentas de código aberto, como MySQL Workbench, mydumper/myloader ou mysqldump para fazer backup e restaurar o banco de dados. Para obter informações sobre como usar essas ferramentas, consulte Opções para migrar o Banco de Dados do Azure para MySQL - Servidor Único para Servidor Flexível. Embora o tutorial descreva as etapas para migrar do Servidor Único MySQL do Azure para o Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Banco de Dados do Azure para Servidor Flexível MySQL que não oferece suporte a zonas de disponibilidade para outro que ofereça suporte a zonas de disponibilidade.
Opção de migração 2: Migração online
Você pode migrar de um Banco de Dados do Azure para Servidor Flexível para outro com tempo de inatividade mínimo para seus aplicativos usando uma das seguintes ferramentas:
Serviço de Migração de Dados (DMS). Para saber como migrar o MySQL Flexible Server para outro com DMS, consulte Migrate Azure Database for MySQL - Single Server to Flexible Server online using DMS through the Azure portal. Embora o tutorial descreva as etapas para migrar do Servidor Único MySQL do Azure para o Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Banco de Dados do Azure para Servidor Flexível MySQL que não oferece suporte a zonas de disponibilidade para outro que ofereça suporte a zonas de disponibilidade.
Ferramentas de código aberto. Você pode usar uma combinação de ferramentas de código aberto, como mydumper/myloader , juntamente com a replicação de Data-in. Para saber como configurar a Replicação de Entrada de Dados, consulte Como configurar o Banco de Dados do Azure para a Replicação de Dados MySQL.
Importante
A replicação de entrada de dados não é compatível com servidores habilitados para HA. A solução alternativa é provisionar o servidor de destino com HA com redundância de zona primeiro e, em seguida, desabilitar a HA antes de configurar a replicação de dados. Quando a replicação for concluída, habilite a HA com redundância de zona novamente no servidor de destino.
Próximas etapas
Saiba mais sobre: