Sobre a recuperação de desastres (DR) no Cloud SQL

Nesta página, apresentamos a recuperação de desastres no Cloud SQL.

Visão geral

No Google Cloud, a recuperação de desastres (DR, na sigla em inglês) do banco de dados se trata de fornecerva continuidade do processamento, especificamente quando uma região falhar ou ficar indisponível. O Cloud SQL é um serviço regional, quando o Cloud SQL está configurado para alta disponibilidade. Portanto, se a região do Google Cloud que hospeda um banco de dados do Cloud SQL ficar indisponível, o banco de dados do Cloud SQL também ficará.

Para continuar o processamento, é preciso disponibilizar o banco de dados em uma região secundária o mais rápido possível. O plano de DR requer que você configure uma réplica de leitura entre regiões no Cloud SQL. Um failover baseado em exportação/importação ou backup/restauração também é possível, mas essa abordagem demora mais, especialmente para bancos de dados grandes.

Os cenários de negócios a seguir são exemplos que garantem uma configuração de failover entre regiões:

  • O contrato de nível de serviço do aplicativo comercial é maior que o contrato de nível de serviço do Cloud SQL regional (99,99% de disponibilidade, dependendo da edição do Cloud SQL). Ao fazer o failover para outra região, você pode reduzir uma falha.
  • Todos os níveis do aplicativo comercial já são multirregionais e podem continuar o processamento quando ocorre uma falha na região. A configuração de failover entre regiões garante a disponibilidade contínua de um banco de dados.
  • O objetivo de tempo de recuperação obrigatório (RTO, na sigla em inglês) e o objetivo do ponto de recuperação (RPO, na sigla em inglês) estão em minutos, e não em horas. Fazer o failover para outra região é mais rápido do que recriar um banco de dados.

Em geral, há duas variantes para o processo de DR:

  • Um banco de dados faz o failover para uma região secundária. Depois que o banco de dados estiver pronto e for usado por um aplicativo, ele se tornará o novo banco de dados principal e permanecerá como principal.
  • Um banco de dados faz o failover para uma região secundária, mas volta para a região principal depois que esta é recuperada da falha.

Nesta visão geral de recuperação de desastres do banco de dados do Google Cloud SQL, descrevemos a segunda variante: quando um banco de dados com falha é recuperado e retorna à região primária. A variante desse processo de DR é especialmente relevante para bancos de dados que precisam ser executados na região principal devido à latência da rede ou porque alguns recursos estão disponíveis apenas na região principal. Com essa variante, o banco de dados é executado na região secundária apenas durante a duração da falha na região principal.

Arquitetura de recuperação de desastres

O diagrama a seguir mostra a arquitetura mínima que aceita DR de banco de dados para uma instância de alta disponibilidade do Cloud SQL:

As instâncias principal e em espera estão localizadas em uma região e a réplica de leitura está em uma segunda região.

A arquitetura funciona da seguinte maneira:

  • Duas instâncias do Cloud SQL, uma instância principal e uma instância em espera, estão localizadas em duas zonas separadas dentro de uma única região (a região principal). As instâncias são sincronizadas com discos permanentes regionais.
  • Uma instância do Cloud SQL (a réplica de leitura entre regiões) está localizada em uma segunda região (a região secundária). No caso de DR, a réplica de leitura entre regiões está configurada para sincronizar (usando a replicação assíncrona) com a instância principal usando uma configuração de réplica de leitura.

As instâncias principal e em espera compartilham o mesmo disco regional. Por isso, seus estados são idênticos.

Como essa configuração usa a replicação assíncrona, é possível que a réplica de leitura entre regiões demore para a instância principal. Como resultado, quando ocorre um failover, o RPO da réplica de leitura entre regiões provavelmente é diferente de zero.

Processo de recuperação de desastres (DR)

O processo de recuperação de desastres (DR) começa quando a região principal fica indisponível. Para retomar o processamento em uma região secundária, você aciona um failover da instância principal, promovendo uma réplica de leitura entre regiões. O processo de DR descreve as etapas operacionais que precisam ser executadas manual ou automaticamente para reduzir a falha regional e estabelecer uma instância principal em execução em uma região secundária.

O diagrama a seguir mostra o processo de DR:

Quando a região 1 ficar indisponível, a réplica de leitura original será promovida para ser a principal.

O processo de DR consiste nas etapas a seguir:

  1. A região principal (R1), que está executando a instância principal, fica indisponível.
  2. A equipe de operações reconhece e confirma formalmente o desastre e decide se um failover é necessário.
  3. Se for necessário um failover, promova a réplica de leitura entre regiões na região secundária (R2) para que ela seja a nova instância principal.
  4. As conexões do cliente são reconfiguradas para retomar o processamento na nova instância principal e acessar a instância principal no R2.

Esse processo inicial estabelece novamente um banco de dados principal em funcionamento. Porém, ela não estabelece uma arquitetura de DR completa, em que a nova instância principal tem uma instância em espera e uma réplica de leitura entre regiões.

Um processo de DR completo garante que a única instância, a nova principal, esteja ativada para alta disponibilidade e tenha uma réplica de leitura entre regiões. Um processo completo de DR também fornece um fallback para a implantação original na região principal original.

Como fazer failover para uma região secundária

O processo completo de DR é uma extensão do processo básico porque adiciona etapas para estabelecer uma arquitetura completa de DR após um failover. No diagrama a seguir, mostramos uma arquitetura completa de DR de banco de dados após o failover:

Os clientes começam a acessar a nova instância principal e uma réplica de leitura é configurada em uma terceira região.

O processo completo de DR de banco de dados consiste nas seguintes etapas:

  1. A região principal (R1), que está executando o banco de dados principal, torna-se indisponível.
  2. A equipe de operações reconhece e confirma formalmente o desastre e decide se um failover é necessário.
  3. Se for necessário um failover, promova a réplica de leitura entre regiões na região secundária (R2) para que ela seja a nova instância principal.
  4. As conexões do cliente são reconfiguradas para acessar e processar na nova instância principal (R2).
  5. Uma nova instância em espera é criada, iniciada em R2 e adicionada à instância principal. A instância em espera está em uma zona diferente da instância principal. A instância principal agora está altamente disponível porque uma instância em espera foi criada para ela.
  6. Em uma terceira região (R3), uma nova réplica de leitura entre regiões é criada e anexada à instância principal. Neste ponto, uma arquitetura de recuperação de desastres completa é recriada e está em operação.

Se a região principal original (R1) ficar disponível antes da implementação da etapa 6, a réplica de leitura entre regiões poderá ser colocada na região R1, em vez de na região R3, imediatamente. Nesse caso, o fallback para a região principal original (R1) é menos complexo e requer menos etapas.

Como evitar um estado de "dupla personalidade"

Uma falha na região principal (R1) não significa que a instância principal original e a instância em espera são automaticamente encerradas, removidas ou tornadas inacessíveis quando R1 fica disponível novamente. Se R1 estiver disponível, os clientes poderão ler e gravar dados (mesmo por acidente) na instância principal original. Nesse caso, uma situação de "dupla personalidade" pode ser desenvolvida, em que alguns clientes acessam dados desatualizados no antigo banco de dados principal e outros clientes acessam dados novos no novo banco de dados principal, gerando problemas na sua empresa.

Para evitar uma situação assim, certifique-se de que os clientes não possam mais acessar a instância principal original depois que R1 estiver disponível. O ideal é tornar a instância principal original inacessível antes que os clientes comecem a usar a nova instância principal e, em seguida, excluir a instância principal original assim que ela ficar inacessível.

Como estabelecer um backup inicial após o failover

Quando você promove a réplica de leitura entre regiões como a nova principal em um failover, as transações na nova principal podem não ser totalmente sincronizadas com as transações da principal original. Portanto, essas transações não estão disponíveis na nova instância.

Como prática recomendada, faça backup imediato da nova instância principal no início do failover e antes que os clientes acessem o banco de dados. Esse backup representa um estado consistente e conhecido no ponto do failover. Esses backups podem ser importantes para fins regulatórios ou para recuperar um estado conhecido se os clientes encontrarem problemas ao acessar o novo principal.

Voltando à região primária original

Conforme descrito anteriormente, neste documento são fornecidas as etapas para voltar à região original (R1). Há duas versões diferentes do processo de fallback.

  • Se você criou a nova réplica de leitura entre regiões em uma região terciária (R3), será preciso criar outra (segunda) réplica de leitura entre regiões na região principal (R1).
  • Se você criou a nova réplica de leitura entre regiões na região principal (R1), não será necessário criar outra réplica de leitura entre regiões na R1.

Depois que a réplica de leitura entre regiões existir em R1, a instância do Cloud SQL poderá voltar para R1. Como esse fallback é acionado manualmente e não é baseado em uma falha, é possível escolher um dia e horário adequados para essa atividade de manutenção.

Assim, para ter uma DR completa que tenha uma réplica de leitura principal, em espera e entre regiões, você precisa de dois failovers. O primeiro failover é acionado pela falha (um failover verdadeiro) e o segundo failover restabelece a implantação inicial (fallback).

A substituição para a região principal original (R1) consiste nas seguintes etapas:

  1. Promover a réplica entre regiões recém-criada na região primária original (R1).
  2. Reconfigure os aplicativos para que eles se conectem à nova instância principal.
  3. Crie uma réplica entre regiões para a nova instância principal na região de DR (R2).
  4. Opcional: para evitar a execução de várias instâncias principais independentes, limpe a instância principal na região de DR (R2).

A seguir