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


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.

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:

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.

    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
.

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"

    A página "Instâncias" mostra a réplica principal ativada para alta disponibilidade e a
réplica de leitura.

    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 lista suspensa da métrica mostra várias opções, incluindo Atraso
de replicação.

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

    O gráfico "Atraso de replicação" tem opções de visualização que variam de uma hora a
30 dias.

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:

    As páginas "Instâncias" mostram o estado de duas instâncias:
a principal original e a principal nova.

    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):

    A página "Instâncias" mostra a nova principal ativada para alta disponibilidade e uma nova
réplica de leitura.

  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:

    A página "Instâncias" mostra apenas a nova réplica principal e a réplica de leitura.

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

  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