Usar a recuperação avançada de desastres (DR)

Nesta página, descrevemos como usar a recuperação avançada de desastres (DR). A DR avançada oferece dois recursos principais:

  • O failover da réplica permite fazer o failover da instância principal para a réplica de DR imediatamente em caso de falha regional. No Cloud SQL para SQL Server, a réplica de DR é uma réplica em cascata.
  • A alternância permite reverter os papéis da instância principal e uma réplica de DR sem perda de dados. É possível usar a alternância para restaurar uma implantação ao estado original de implantação após o failover da réplica. Também é possível usar a alternância para testar a DR.

A DR avançada tem suporte apenas nas instâncias da edição Cloud SQL Enterprise Plus.

Antes de começar

Se você planeja usar o SDK Google Cloud, use a versão 502.0.0 ou posterior. Para verificar a versão do SDK Google Cloud, execute gcloud --version. Para atualizar o SDK Google Cloud, execute gcloud components update.

Para instalar o SDK Google Cloud, consulte Instalar a CLI gcloud.

Criar uma réplica de DR

Antes de usar a DR avançada, crie uma réplica em cascata da instância principal em uma região diferente.

Realizar uma alternância

Depois de criar uma réplica de DR, execute a operação de alternância. No entanto, como prática recomendada, evite realizar a operação de alternância nas seguintes circunstâncias:

  • A instância principal está sendo usada ativamente.
  • As operações de administrador estão em andamento, como backup automatizado ou a ativação ou desativação da alta disponibilidade (HA, na sigla em inglês).

Para evitar um tempo limite, considere fazer uma alternância quando o volume de transações estiver baixo.

Quando a alternância é concluída, a operação faz um backup da nova instância principal (a antiga réplica de DR) assim que a nova instância principal é promovida. Após a conclusão do backup, a recuperação pontual (PITR, na sigla em inglês) será totalmente ativada na nova instância principal. Esse backup pode levar de 5 a 15 minutos para ser concluído, dependendo do tamanho do disco. A cobertura da PITR só começa após a conclusão desse backup. Para saber mais sobre as considerações sobre o uso da PITR com DR avançada, consulte Usar PITR com DR avançada.

Após a conclusão da operação de alternância, você vai perceber que a direção da replicação está invertida.

Depois que a instância principal antiga é reconfigurada como uma réplica de leitura, o endpoint de gravação do DNS, que antes era resolvido para a instância principal antiga, é resolvido para a nova instância principal.

Antes de começar

Antes de realizar a operação de alternância, faça o seguinte:

  • Crie uma réplica de DR, caso ainda não tenha feito isso.
  • Verifique se a instância principal e a réplica de DR estão on-line.
  • Se você estiver usando um endpoint de gravação de DNS, verifique se a configuração SSL da instância principal e da réplica de DR são iguais. Por exemplo, se a réplica de DR estiver configurada para aplicar a criptografia SSL, mas a instância principal permitir conexões não criptografadas, os clientes não poderão se conectar à nova instância principal após a conclusão da operação de alternância.
  • Faça um backup sob demanda da instância principal. Esse backup é uma precaução caso você precise se recuperar de falhas inesperadas.

Executar a operação de alternância

gcloud

Para executar a operação de alternância, execute o seguinte comando:

gcloud sql instances switchover REPLICA_NAME

Substitua as seguintes variáveis:

  • REPLICA_NAME: o nome da réplica de DR com que você quer que a instância principal troque de papel.

REST v1

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • REPLICA_NAME: o nome da réplica de DR.

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • REPLICA_NAME: o nome da réplica de DR.

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

Executar a DR invocando uma réplica de failover

No caso de uma falha regional ou um desastre, é possível executar a DR invocando uma operação de failover de réplica para sua réplica de DR designada. Para executar um failover de réplica, promova a réplica de DR. Diferente da alternância, a promoção da réplica de DR é imediata.

Como a réplica de DR assume o papel da instância principal imediatamente, é possível que a réplica não tenha todos os dados da instância principal antiga devido ao atraso da replicação. Por esse motivo, um failover de réplica pode incorrer na perda de dados.

Como parte do processo de promoção, o failover da réplica recebe um backup da nova instância principal (a antiga réplica de DR) logo depois que a réplica de DR se torna a nova instância principal. Após a conclusão do backup, a recuperação pontual (PITR, na sigla em inglês) será totalmente ativada na nova instância principal. Esse backup pode levar de 5 a 15 minutos para ser concluído, dependendo do tamanho do disco da instância principal nova (e antiga). Durante o período de backup, a PITR não estará disponível.

Quando a instância principal antiga fica on-line novamente, o processo de failover da réplica usa um backup. Depois que esse backup é realizado, a instância principal antiga é recriada como uma réplica de leitura da nova instância principal.

Para saber mais sobre as considerações sobre o uso da PITR com DR avançada, consulte Usar PITR com DR avançada.

Depois de invocar a operação de failover da réplica, o endpoint de gravação do DNS, que antes era resolvido para a instância principal antiga, é resolvido para a nova instância principal.

Antes de começar

Antes de executar um failover de réplica, faça o seguinte:

  • Crie uma réplica de DR, caso ainda não tenha feito isso.
  • Verifique se a réplica de DR está on-line e íntegra.

Executar a operação de failover da réplica

gcloud

Para invocar um failover de réplica para a réplica de DR, use o seguinte comando:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Substitua a seguinte variável:

  • REPLICA_NAME: o nome da réplica de DR

REST v1

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • REPLICA_NAME: o nome da réplica de DR.
  • ENABLE_REPLICA_FAILOVER: defina como true para usar o failover de réplica. Se você definir como false, a API usará o método promoteReplica normal sem failover de réplica.

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • REPLICA_NAME: o nome da réplica de DR.
  • ENABLE_REPLICA_FAILOVER: defina como true para usar o failover de réplica. Se você definir como false, a API usará o método promoteReplica normal sem failover de réplica.

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

Verificar o status de um failover de réplica

O failover da réplica ocorre em duas fases. A primeira fase é a promoção da réplica de DR. A segunda fase é a recriação da instância principal antiga como uma réplica de leitura.

Para verificar o status do failover da réplica, verifique o status de cada fase.

  1. Verificar o status da primeira fase.

    Console

    Para verificar se a réplica de DR foi promovida a uma instância independente, faça o seguinte:

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

      Acesse "Instâncias do Cloud SQL"

    2. Encontre o nome da réplica de DR que você promoveu.
    3. Verifique se SQL Server VERSION aparece na coluna Tipo da nova instância principal.

    gcloud

    Verifique o status executando o seguinte comando:

    gcloud sql instances describe DR_REPLICA_NAME

    Substitua a seguinte variável:

    • DR_REPLICA_NAME: o nome da réplica de DR promovida

    Na saída, verifique se o campo a seguir aparece e a réplica se tornou uma instância principal autônoma do Cloud SQL:

    instanceType: CLOUD_SQL_INSTANCE

  2. Para verificar a conclusão da segunda fase, acesse o registro de operações na instância para a mensagem RECONFIGURE_OLD_PRIMARY.

    A aparência dessa mensagem depende de quando a instância principal antiga retorna on-line, o que pode levar minutos ou dias em caso de um desastre.

    Para mais informações sobre como verificar os registros de operações em uma instância, consulte Ver registros da instância.

Usar a recuperação pontual (PITR, na sigla em inglês) com DR avançada

Com a alternância e o failover de réplica, assim que a réplica de DR é promovida a uma instância principal, as seguintes alterações ocorrem para oferecer suporte ao backup e à PITR:

  • A configuração de backup, incluindo qualquer programação de backup automatizada, é copiada da instância principal antiga para a nova.

  • Um novo backup é usado para dar suporte à PITR na nova instância principal.

  • A política de retenção de registros de transações é copiada da instância principal antiga para a nova.

Para a configuração de backup e as políticas de retenção de registros de transações, recomendamos que você verifique se as configurações herdadas da instância principal antiga estão corretas para a nova instância principal.

Início da cobertura da PITR

No final da operação de alternância, o Cloud SQL programa backups automatizados e faz o primeiro backup da nova instância principal. Se você quiser que a cobertura da PITR comece mais cedo, recomendamos verificar se o primeiro backup foi bem-sucedido. A instância principal recém-promovida tem cobertura de PITR somente após a conclusão do primeiro backup automatizado.

Para mais informações sobre como ver os backups disponíveis para uma instância, consulte Ver uma lista de backups.

Cobertura PITR para instâncias durante alternância e failover de réplica

Quando uma instância participa de uma operação de alternância ou de failover de réplica, ela passa tempo como uma réplica de leitura. A PITR e a restauração de um backup têm suporte durante o período que a instância passa como réplica de leitura e como instância principal.

É possível executar a PITR para um momento antes da alternância, quando a instância era principal. Para operações de alternância e failover de réplica, o Cloud SQL inicia um backup de melhor esforço para a nova instância principal assim que a nova instância principal é promovida. A PITR só é ativada na instância promovida após a conclusão desse backup. Esse backup pode levar de 5 a 15 minutos para ser concluído, dependendo do tamanho do disco.

Cérebro dividido durante failover da réplica

É possível que o cérebro dividido ocorra quando a instância principal continua aceitando gravações enquanto uma réplica é promovida usando o failover da réplica. Depois que a réplica é promovida, quando a instância principal antiga fica disponível novamente, ela é reconstruída como uma réplica da instância promovida e um backup final é feito. Esse backup pode ser usado para recuperar todos os dados de divisão de cérebro que não foram gravados na réplica promovida.

Exclusão de backups e registros de transações em réplicas

Se uma instância principal que foi ativada com a PITR e os backups se tornar uma réplica de leitura, o último backup e a política de retenção de PITR do período como uma instância primária serão preservados e aplicados durante o período como réplica. Mesmo que a nova instância principal não faça backups, os backups e os registros de transações antigos usados para a PITR serão excluídos na réplica de leitura de acordo com a última política configurada.

Por exemplo, se a instância estiver configurada para ter backups automatizados diários e manter sete backups com sete dias de registros PITR, quando essa instância se tornar uma réplica de leitura, tudo o que tiver mais de sete dias será excluído uma vez por dia.

Se for necessário excluir os backups antes, você poderá removê-los manualmente. Para mais informações, consulte Excluir um backup.

Limitações

  • A DR avançada não é compatível com instâncias do Cloud SQL que usam o Private Service Connect. A DR avançada oferece suporte ao acesso a serviços privados.

  • Não é possível designar uma instância de réplica de leitura da edição Cloud SQL Enterprise Plus como réplica de DR se a instância principal armazenar os registros de transação para recuperação pontual (PITR, na sigla em inglês) no disco. Para verificar o local em que uma instância armazena os registros para PITR, consulte Verificar o local de armazenamento dos registros de transação usados para a PITR.

  • Não é possível designar uma réplica externa como uma réplica de DR.

  • O Terraform não tem suporte para operações de failover de alternância ou de réplica.

  • Não é possível usar o console do Google Cloud para executar operações de failover ou switchover de réplica.

Resolver problemas

Problema Solução de problemas
Falha na operação de alternância.
    Verifique se a instância atende a todos os requisitos de réplica de DR (cascata) declarados.
  • Verifique o volume de transações no banco de dados. Se o volume de transações for alto, a operação poderá atingir o tempo limite. Tente realizar a operação novamente quando a carga da transação for menor.
A operação de alternância falhou, e a instância principal está travada no modo somente leitura. Execute uma reinicialização do banco de dados para trazer a instância principal de volta ao modo de gravação.
A operação de alternância foi concluída, mas o console do Google Cloud não mostra os novos papéis invertidos para as instâncias. Atualize seu navegador para mostrar a topologia atualizada.
Falha na operação de failover da réplica.
  • Verifique se você criou uma réplica de DR para a instância principal e se a réplica de DR está on-line.
  • Se o failover para a réplica de DR falhar, promova a uma réplica de leitura normal (não DR).

A seguir