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

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.

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.

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.