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 é preferida para redundância de infraestrutura com menor latência de rede porque os servidores primário e em espera estarão na mesma zona de disponibilidade. Ele fornece alta disponibilidade sem a necessidade de configurar redundância de aplicativos entre zonas. A HA de mesma zona é preferida quando você deseja atingir o mais alto nível de disponibilidade em uma única zona de disponibilidade com a menor latência de rede. A HA da mesma zona está disponível em todas as regiões do Azure onde você pode usar o Banco de Dados do Azure para MySQL - Servidor Flexível. Para saber mais sobre a arquitetura HA de mesma zona, consulte Arquitetura de HA de mesma zona.
Arquitetura HA com redundância de zona. Essa opção é preferida para isolamento completo e redundância de infraestrutura em várias zonas de disponibilidade. Ele fornece o mais alto nível de disponibilidade, mas exige que você configure a redundância de aplicativos entre zonas. A HA com redundância de zona é preferida quando você deseja atingir o mais alto nível de disponibilidade contra qualquer falha de infraestrutura na zona de disponibilidade e quando a latência na zona de disponibilidade é aceitável. Ele pode ser ativado somente quando o servidor é criado. A HA com redundância de zona está disponível em um subconjunto de regiões do Azure onde 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 (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 orientações 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 o Servidor Flexível MySQL 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 o Servidor Flexível MySQL como um servidor não HA, pode simplesmente habilitá-lo para a arquitetura HA da mesma zona. No entanto, se você quiser habilitá-lo para arquitetura HA com redundância de zona, precisará 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 o Servidor Flexível MySQL 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 do MySQL. Certifique-se de que o servidor criado está configurado para redundância de zona, ativando HA e selecionando a opção Zone-Redundant .
Gorjeta
Se você quiser a flexibilidade de poder se mover entre HA zonal (mesma zona) e redundante de zona no futuro, você pode provisionar seu Banco de Dados do Azure para 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 o HA.
Requisitos de tempo de inatividade
As migrações podem ser categorizadas como online ou offline:
• Migração offline. Se o seu aplicativo puder suportar algum tempo de inatividade, as migrações offline são sempre a escolha preferida, 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. Esta opção exigirá o maior 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. Esta 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 contínuas entre o servidor de origem e o servidor 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 seguintes ferramentas. Ambas as opções exigirão tempo de inatividade.
Serviço de Migração de Dados (DMS). Para saber como migrar o Servidor Flexível MySQL para outro com DMS, consulte Migrar o Banco de Dados do Azure para MySQL - Servidor Único para Servidor Flexível offline usando o DMS por meio do portal do Azure. Embora o tutorial descreva as etapas para migrar do Servidor Único do Azure MySQL 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 dá 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 do Azure MySQL 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 dá 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 o mínimo de tempo de inatividade para seus aplicativos usando uma das seguintes ferramentas:
Serviço de Migração de Dados (DMS). Para saber como migrar o Servidor Flexível MySQL para outro com DMS, consulte Migrar o Banco de Dados do Azure para MySQL - Servidor Único para Servidor Flexível online usando o DMS por meio do portal do Azure. Embora o tutorial descreva as etapas para migrar do Servidor Único do Azure MySQL 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 dá 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 dados. Para saber como configurar a Replicação de Dados, consulte Como configurar o Banco de Dados do Azure para Replicação de Dados MySQL.
Importante
A replicação de dados não é suportada para 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óximos passos
Saiba mais sobre: