Migrar o MySQL – Servidor Flexível para o suporte à zona de disponibilidade
Este guia descreve como migrar o MySQL – Servidor Flexível do suporte à zona de não disponibilidade para o suporte à zona de disponibilidade.
Você pode configurar o Servidor Flexível do Banco de Dados do Azure para MySQL para usar um dos dois modelos de arquitetura de alta disponibilidade (HA):
Arquitetura de HA na 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 de HA na mesma zona, consulte Arquitetura de HA na mesma zona.
Arquitetura de 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 dá suporte a várias zonas de disponibilidade e há compartilhamentos de arquivo Premium com redundância de zona disponíveis. Para saber mais sobre a arquitetura de HA com redundância de zona, consulte Arquitetura de Ha com redundância de zona.
Para migrar sua carga de trabalho existente de HA zonal (HA na mesma zona) para HA com redundância de zona, você precisará fazer o seguinte:
Implantar e configurar um novo servidor que foi configurado para HA com redundância de zona.
Seguir 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 Servidor Flexível do Banco de Dados do Azure para MySQL em uma região que não dá suporte a zonas de disponibilidade.
Um Banco de Dados do Azure para MySQL – Servidor Flexível que não estava habilitado para HA no momento da criação.
Importante
Se você tiver provisionado originalmente o Servidor Flexível do Banco de Dados do Azure para MySQL como um servidor não HA, poderá simplesmente habilitá-lo para arquitetura de HA na mesma zona. No entanto, se você quiser habilitá-lo para a arquitetura de HA com redundância de zona, precisará implementar uma das opções de migrações disponíveis listadas neste artigo.
Você precisará criar um servidor de destino que esteja executando o Servidor Flexível do Banco de Dados do Azure para MySQL em uma região que dê suporte a zonas de disponibilidade. Para obter mais informações sobre como criar um Servidor Flexível do Banco de Dados do Azure para MySQL, consulte Usar o portal do Azure para criar um Servidor Flexível do Banco de Dados do Azure para MySQL. Verifique se o servidor criado está configurado para redundância de zona habilitando a HA e selecionando a opção Com redundância de zona.
Dica
Se você quiser a flexibilidade de poder se mover entre HA zonal (mesma zona) e HA com redundância de zona no futuro, poderá provisionar seu Servidor Flexível do Banco de Dados do Azure para MySQL com HA com redundância de zona 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 tempo de inatividade mínimo e é a melhor opção se você quiser menos tempo de inatividade. O servidor de origem permite atualizações e a solução de migração cuidará da replicação das alterações contínuas entre o servidor de origem e de destino, juntamento 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 Banco de Dados (DMS). Para saber como migrar o Servidor Flexível do MySQL para outro com DMS, consulte Migrar Banco de Dados do Azure para MySQL – Servidor Único para Servidor Flexível offline usando DMS por meio do portal do Azure. Embora o tutorial descreva as etapas para migrar do Servidor Único do MySQL do Azure para Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Servidor Flexível do Banco de Dados do Azure para MySQL que não dá 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 MySQL do Azure para Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Servidor Flexível do Banco de Dados do Azure para MySQL que não dá 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 tempo de inatividade mínimo para seus aplicativos usando uma das seguintes ferramentas:
Serviço de Migração de Banco de Dados (DMS). Para saber como migrar o Servidor Flexível do MySQL para outro com DMS, consulte Migrar o Banco de Dados do Azure para MySQL – Servidor Único para Servidor Flexível online usando DMS por meio do portal do Azure. Embora o tutorial descreva as etapas para migrar do Servidor Único do MySQL do Azure para Servidor Flexível, você pode usar o mesmo procedimento para migrar dados de um Servidor Flexível do Banco de Dados do Azure para MySQL que não dá 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 junto com a Replicação de Dados. Para saber como configurar a Replicação de Dados, consulte Como configurar a Replicação de Dados do Banco de Dados do Azure para MySQL.
Importante
Não há suporte para a Replicação de Dados 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. Depois que 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: