Recuperação de desastres do Cloud SQL para MySQL: um processo completo de failover e fallback

---

Observação: neste documento ou seção, há menções a um ou mais termos que o Google considera desrespeitosos ou ofensivos. Os termos são usados porque são palavras-chave no software descrito no documento.

Neste tutorial, descrevemos um processo completo de failover e fallback de recuperação de desastres (DR) no Cloud SQL para MySQL usando réplicas de leitura entre regiões.

Neste tutorial, você configura uma instância de alta disponibilidade (HA) do Cloud SQL para MySQL para DR e simula uma falha. Em seguida, você passa pelo processo de DR para recuperar sua implantação inicial depois que a falha é resolvida.

Importante: este tutorial se aplica somente à recuperação de desastres (DR) geral, disponível para todas as instâncias do Cloud SQL para MySQL. Se você estiver usando o Cloud SQL Enterprise Plus, terá a opção de usar a recuperação avançada de desastres (DR). Para mais informações sobre a DR avançada, consulte Recuperação avançada de desastres e Como usar a recuperação de desastres (DR) avançada. A DR avançada está em Prévia.

Este tutorial se destina a arquitetos de bancos de dados, administradores e engenheiros.

Para ter uma visão geral de como funciona a recuperação de desastres do SQL, consulte Sobre a recuperação de desastres no Cloud SQL.

Objetivos

• Criar uma instância de alta disponibilidade do Cloud SQL para MySQL.
• Implantar uma réplica de leitura entre regiões no Google Cloud usando o Cloud SQL para MySQL.
• Simular um desastre e failover com o Cloud SQL para MySQL.
• Entender as etapas para recuperar sua implantação inicial usando um fallback com o Cloud SQL para MySQL.

Este documento se concentra apenas nos processos de failover e fallback de DR entre regiões. Para informações sobre um processo de failover de alta disponibilidade de região única, consulte Visão geral da configuração de alta disponibilidade.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Cloud SQL

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

Fase 1: como configurar uma instância de banco de dados de alta disponibilidade para DR

As fases a seguir (1 a 3) orientam você em um processo completo de failover e fallback. Todos os comandos são executados usando o comando gcloud no Cloud Shell. Para simplificar o processo, o tutorial usa configurações padrão quando possível (por exemplo, a versão padrão do Cloud SQL). No seu ambiente de produção, você pode adicionar outras configurações.

Definir as variáveis de ambiente

Nesta seção, fornecemos exemplos de variáveis de ambiente que definem os vários nomes e regiões necessários para os comandos executados neste tutorial. É possível ajustar esses exemplos de variáveis para atender às suas necessidades.

As tabelas a seguir descrevem nomes de instâncias, seus papéis e regiões de implantação para cada fase do processo de DR e fallback neste tutorial. Também é possível fornecer seus próprios nomes e regiões.

Fase inicial
Nome da instância	Papel	Região
instance-1	Principal	us-west1
instance-2	Espera	us-west1
instance-3	Réplica de leitura entre regiões	us-west2

Fase de desastres
Nome da instância	Papel	Região
instance-3	Principal	us-west2
instance-4	Espera	us-west2
instance-5	Réplica de leitura entre regiões	us-west3
instance-6	Réplica de leitura entre regiões	us-west1

Fase de fallback (final)
Nome da instância	Papel	Região
instance-6	Principal	us-west1
instance-7	Espera	us-west1
instance-8	Réplica de leitura entre regiões	us-west2

Observação: os nomes de instância instance-2, instance-4 e instance-7 não são usados por você na criação de instâncias do Cloud SQL. Essas instâncias serão criadas automaticamente ao ativar a alta disponibilidade na instance-1, instance-3 e instance-6. O motivo para fornecer os nomes adicionais é poder consultar as instâncias de alta disponibilidade criadas automaticamente e ter um esquema de nomenclatura consistente que corresponda às instâncias reais do Cloud SQL que estão sendo criadas.

.

Os nomes de instância nas tabelas anteriores não são codificados com os papéis. Em uma situação de DR, a função de uma instância pode mudar. Por exemplo, uma réplica pode se tornar a principal. Se o nome da nova principal contiver a palavra replica, poderão surgir confusão e conflitos. Portanto, recomendamos não codificar nomes de instâncias com a função ou o papel que executam.

As tabelas anteriores listam os nomes das instâncias em espera. Mesmo que este tutorial não use um failover de alta disponibilidade, ele inclui os nomes das instâncias em espera para garantir a integridade.

A fase de fallback recria a implantação original da fase inicial nas mesmas regiões originais. No entanto, em um fallback, os nomes das instâncias precisam ser alterados porque os nomes originais não ficam imediatamente disponíveis mesmo após a exclusão da instância original. Para dar suporte à criação rápida de instâncias na fase de fallback, use nomes de instância que não correspondam aos nomes usados na fase inicial.

• No Cloud Shell, defina as variáveis de ambiente que se baseiam nas especificações das tabelas anteriores:

  export primary_name=instance-1
  export primary_tier=db-n1-standard-2
  export primary_region=us-west1
  export primary_root_password=my-root-password
  export primary_backup_start_time=22:00
  export cross_region_replica_name=instance-3
  export cross_region_replica_region=us-west2
  

  Se você quiser usar um nível diferente para sua instância principal, liste os níveis disponíveis e atribua um valor diferente ao primary_tier:

  gcloud sql tiers list
  

  Para uma lista de regiões em que é possível implantar o Cloud SQL, consulte Configurações de instâncias.

Criar uma instância principal do banco de dados

1. No Cloud Shell, crie uma única instância do Cloud SQL:

   gcloud sql instances create $primary_name \
       --tier=$primary_tier \
       --region=$primary_region
   

   O comando gcloud é pausado até a instância ser criada.

2. Defina a senha raiz:

   gcloud sql users set-password root \
       --host=% \
       --instance $primary_name \
       --password $primary_root_password
   

Criar um banco de dados principal

1. No Cloud Shell, faça login no shell do MySQL e insira a senha raiz no prompt:

   gcloud sql connect $primary_name --user=root
   

2. No prompt do MySQL, crie um banco de dados e faça upload dos dados de teste:

   CREATE DATABASE guestbook;
   
   USE guestbook;
   
   CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));
   
   INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
   INSERT INTO entries (guestName, content) values ("second guest", "Me too!");
   

3. Verifique se os dados foram confirmados com êxito:

   SELECT * FROM entries;
   

   Verifique se duas linhas de dados são retornadas.

4. Saia do shell do MySQL:

   exit;
   

Neste momento, você tem um único banco de dados que inclui uma tabela e alguns dados de teste.

Alterar a instância principal para uma instância de banco de dados de alta disponibilidade

Só é possível configurar o Cloud SQL como um sistema regional de alta disponibilidade, não como um sistema entre regiões. A configuração de uma réplica de leitura entre regiões é diferente da configuração do Cloud SQL como um sistema entre regiões. Para mais informações, consulte Como ativar e desativar a alta disponibilidade em uma instância.

• No Cloud Shell, crie uma instância do Cloud SQL ativada para alta disponibilidade:

  gcloud sql instances patch $primary_name \
      --availability-type REGIONAL \
      --enable-bin-log \
      --backup-start-time=$primary_backup_start_time
  

Adicionar uma réplica de leitura entre regiões para DR com atualização automática

As etapas a seguir são suficientes para criar uma réplica de leitura entre regiões para este tutorial:

1. No Cloud Shell, configure uma réplica de leitura entre regiões:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

2. Opcional: para verificar se o banco de dados foi replicado, acesse a página Instâncias do Cloud SQL no Console do Google Cloud.

   Acesse "Instâncias"

   

   O Console do Google Cloud mostra que a instância principal (instance-1) está ativada para alta disponibilidade e que existe uma réplica de leitura entre regiões (instance-3).

3. Usando a mesma senha raiz para a instância principal, faça login na réplica de leitura entre regiões:

   gcloud sql connect $cross_region_replica_name --user=root
   

4. No prompt do MySQL, selecione os dados para garantir o funcionamento da replicação:

   USE guestbook;
   
   SELECT * FROM entries;
   

5. Saia do shell do MySQL:

   exit;
   

Para detalhes sobre como configurar uma réplica de leitura entre regiões completa, consulte a documentação do Cloud SQL

Para grandes bancos de dados em um ambiente de produção, recomendamos fazer backup do banco de dados principal e criar a réplica de leitura entre regiões a partir do backup. Essa etapa reduz o tempo necessário para que a réplica de leitura seja sincronizada com o banco de dados principal. Esse processo está descrito na próxima seção. No entanto, é possível pular esta etapa e continuar com a Fase 2.

Adicionar uma réplica de leitura entre regiões com base em um arquivo dump

Uma maneira de otimizar a criação de uma réplica de leitura entre regiões é sincronizar a réplica de um estado de banco de dados principal anterior e consistente em vez de sincronizar no momento do acesso à nova réplica principal. Essa otimização requer a criação de um arquivo dump que a réplica usa como estado inicial.

Consulte Como replicar de um servidor externo para o Cloud SQL (v1.1) para ver as etapas de criação de uma réplica com base em um arquivo dump. Essa abordagem pode ser útil para grandes bancos de dados de produção. No entanto, este tutorial ignora essa etapa porque o conjunto de dados de teste é pequeno o suficiente para uma replicação completa.

Fase 2: como simular um desastre (falha na região)

Nesta fase, você simulará a interrupção de uma região principal em uma configuração de produção tornando o banco de dados primário indisponível.

Verificar o atraso da réplica de leitura entre regiões

Nas etapas a seguir, você determina o atraso da replicação da réplica de leitura entre regiões:

1. No Console do Google Cloud, acesse a página Instâncias do Cloud SQL.

   Acesse "Instâncias"

2. Clique na réplica de leitura (instance-3).

3. Na lista suspensa de métricas, clique em Atraso de replicação:

   

   A métrica muda para Atraso de replicação. O gráfico não mostra atrasos:

   

O ideal é que o atraso da replicação seja zero quando ocorre uma falha de região principal, já que um atraso de zero garante que todas as transações sejam replicadas. Caso contrário, algumas transações podem não ser replicadas. Nesse caso, a réplica de leitura entre regiões não conterá todas as transações confirmadas na principal.

Tornar a instância principal indisponível

Nas etapas a seguir, você simula um desastre interrompendo a principal. Se uma réplica de leitura entre regiões estiver anexada à principal, será necessário primeiro desanexar a réplica. Caso contrário, não será possível interromper a instância do Cloud SQL.

1. No Cloud Shell, remova a réplica de leitura entre regiões da principal:

   gcloud sql instances patch $cross_region_replica_name \
       --no-enable-database-replication
   

   Quando solicitado, aceite a opção para continuar.

2. Pare a instância principal do banco de dados:

   gcloud sql instances patch $primary_name --activation-policy NEVER
   

Implementar DR

1. No Cloud Shell, promova a réplica de leitura entre regiões a uma instância autônoma:

   gcloud sql instances promote-replica $cross_region_replica_name
   

   Quando solicitado, aceite a opção para continuar. A página Instâncias do Cloud SQL mostra a antiga réplica de leitura entre regiões (instance-3) como a nova principal e a antiga principal (instance-1) como interrompida:

   

   Depois de promover a réplica de leitura entre regiões como a nova principal, você a ativa para alta disponibilidade. Como prática recomendada, atualize as variáveis de ambiente com a nomenclatura correta.

2. Atualize as variáveis de ambiente:

   export former_primary_name=$primary_name
   export primary_name=$cross_region_replica_name
   export primary_tier=db-n1-standard-2
   export primary_region=$cross_region_replica_region
   export primary_root_password=my-root-password
   export primary_backup_start_time=22:00
   export cross_region_replica_name=instance-5
   export cross_region_replica_region=us-west3
   

3. Inicie a nova principal:

   gcloud sql instances patch $primary_name --activation-policy ALWAYS
   

4. Ative a nova instância principal como uma instância regional de alta disponibilidade:

   gcloud sql instances patch $primary_name \
       --availability-type REGIONAL \
       --enable-bin-log \
       --backup-start-time=$backup_start_time
   

5. Crie uma réplica de leitura entre regiões em uma terceira região:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

   Em uma etapa anterior, você define a variável de ambiente cross_region_replica_region como us-west3.

   Após a conclusão do failover, a página Instâncias do Cloud SQL no Console do Google Cloud mostra que a nova principal (instance-3) está ativada como alta disponibilidade e tem uma réplica de leitura entre regiões (instance-5):

   

6. (Opcional) Se você tiver backups regulares, siga o processo descrito anteriormente para sincronizar a nova principal com a versão de backup mais recente.

7. Opcional: se estiver usando um proxy do Cloud SQL, configure-o para usar a nova principal e retomar o processamento do aplicativo.

Lidar com uma falha curta na região

É possível que a falha que aciona um failover seja resolvida antes que o failover seja concluído. Nesse caso, convém cancelar o processo de failover e continuar usando a instância principal original do Cloud SQL na região em que ocorreu a falha.

Dependendo do estado específico do processo de failover, a réplica de leitura entre regiões já pode ter sido promovida. Nesse caso, você precisa excluí-la e recriar uma réplica de leitura entre regiões.

Excluir a principal original para evitar uma situação de "dupla personalidade"

Para evitar uma situação de "dupla personalidade", é preciso excluir a principal original (ou torná-la inacessível para os clientes do banco de dados).

Após um failover, pode ocorrer uma situação de "dupla personalidade" quando os clientes fazem gravações no banco de dados principal original e no novo banco de dados principal ao mesmo tempo. Nesse caso, o conteúdo dos dois bancos de dados é inconsistente. Após um failover, o banco de dados principal original fica desatualizado e não pode receber nenhum tráfego de leitura ou gravação.

• No Cloud Shell, exclua o principal original:

  gcloud sql instances delete $former_primary_name
  

  Quando solicitado, aceite a opção para continuar.

  No Console do Google Cloud, a página Instâncias do Cloud SQL não mostra mais a instância principal original (instance-1) como parte da implantação:

  

Fase 3: como implementar um fallback

Para implementar um fallback na sua região original (R1) depois que ele estiver disponível, siga o mesmo processo descrito na Fase 2. Esse processo é resumido da seguinte forma:

1. Crie uma segunda réplica de leitura entre regiões na região original (R1). Neste ponto, a principal tem duas réplicas de leitura entre regiões, uma na região R3 e outra na região R1.

2. Promova a réplica de leitura entre regiões na R1 como a principal final.

3. Ative a alta disponibilidade para a principal final.

4. Crie uma réplica de leitura entre regiões da principal final em us-west2.

5. Para evitar uma situação de "dupla personalidade", exclua todas as instâncias que não são mais necessárias (a principal original e a réplica de leitura entre regiões na R3).

Como discutido antes, é uma prática recomendada criar um backup inicial que contenha o estado inicial definido para o novo banco de dados principal.

A implantação final agora tem uma réplica principal de alta disponibilidade (com o nome instance-6) e uma réplica de leitura entre regiões (com o nome instance-8).

Como comparar as vantagens e desvantagens de uma DR manual e uma automática

A tabela a seguir discute as vantagens e desvantagens da implementação de um processo de DR manual ou automática. O objetivo não é determinar uma abordagem correta versus incorreta, mas fornecer critérios para ajudar você a determinar a melhor abordagem para suas necessidades.

Execução manual	Execução automática
Vantagens: Você tem um controle rígido sobre cada etapa. Você pode ver, resolver e documentar imediatamente qualquer problema no processo. Você pode ver e analisar cada etapa do processo durante um failover.	Vantagens: É possível implementar e testar processos de failover. A automação oferece uma implementação mais rápida e minimiza os atrasos. A implementação é independente dos operadores humanos, do conhecimento deles e da disponibilidade deles.
Desvantagens: A implementação manual de etapas do processo atrasa o processo. Erros de digitação humana podem gerar problemas. O teste do processo geralmente envolve vários papéis e tempo, o que pode desencorajar testes regulares.	Desvantagens: Se ocorrer um erro imprevisto, você precisará depurar durante o failover de produção. Se você encontrar erros durante o processo, precisará de scripts para escolher (recuperar) onde o processo parou. É necessário ter conhecimento suficiente do script e da implementação dele para entender o comportamento que ele tem, especialmente em situações de erro.

Como prática recomendada, comece com uma implementação manual. Em seguida, execute a implementação voluntariamente (preferencialmente em produção) de maneira regular para garantir que o processo manual funcione e que todos os membros da equipe conheçam os papéis e as responsabilidades deles. Recomendamos que você defina o processo manual em um documento passo a passo do processo. Após cada implementação, confirme ou refine o documento do processo.

Depois de ajustar o processo e ter certeza de que ele é confiável, você determina se o processo será automatizado. Se você selecionar e implementar um processo automatizado, será preciso testá-lo regularmente na produção para garantir que ele seja implementado de maneira confiável.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto do Google Cloud criado para este tutorial.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

A seguir

• Leia sobre a recuperação de desastres do Cloud SQL.
• Leia sobre recuperação de desastres para o MySQL no Compute Engine.
• Saiba mais sobre arquiteturas de recuperação de desastres para falhas de infraestrutura em nuvem.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.