Esta página foi traduzida pela API Cloud Translation.

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

MySQL | PostgreSQL | SQL Server

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 do 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. Esse backup pode levar de 5 a 15 minutos para ser concluído, dependendo do tamanho do disco. Após a conclusão do backup, se você quiser usar a PITR na instância promovida, ative a PITR manualmente. 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 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:

curl (Linux, macOS ou Cloud Shell)

Observação: o comando a seguir pressupõe que você fez login na CLI gcloud com sua conta de usuário executando gcloud init ou gcloud auth login, ou usando o Cloud Shell, que faz login automaticamente na CLI gcloud. . É possível verificar a conta ativa atual executando gcloud auth list.

execute o seguinte comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Observação: o comando a seguir pressupõe que você fez login na CLI gcloud com sua conta de usuário executando gcloud init ou gcloud auth login . É possível verificar a conta ativa atual executando gcloud auth list.

execute o seguinte comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Você receberá uma resposta JSON semelhante a esta:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

curl (Linux, macOS ou Cloud Shell)

execute o seguinte comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

execute o seguinte comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Você receberá uma resposta JSON semelhante a esta:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

curl (Linux, macOS ou Cloud Shell)

execute o seguinte comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

execute o seguinte comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Você receberá uma resposta JSON semelhante a esta:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

curl (Linux, macOS ou Cloud Shell)

execute o seguinte comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

execute o seguinte comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Você receberá uma resposta JSON semelhante a esta:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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.

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
```
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

Seja uma alternância ou failover de réplica, se a réplica de DR for promovida a uma instância principal e você quiser usar a PITR na instância promovida, será necessário ativar a PITR manualmente.

Depois que a PITR é ativada, a configuração de backup e as políticas de retenção de registros de transações são aplicadas. Se você não especificar valores para essas configurações, o valor padrão de 14 dias será aplicado.

Para mais informações, consulte Usar a PITR.

Depois que a PITR for ativada na nova instância principal, será possível restaurar a instância para qualquer momento em que ela for uma instância principal ativa.

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 realizar 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

Confira todos os serviços doGoogle Cloud disponíveis em locais do mundo todo.
Leia sobre a observabilidade do banco de dados
Monitorar instâncias do Cloud SQL

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

Antes de começar

Criar uma réplica de DR

Realizar uma alternância

Antes de começar

Executar a operação de alternância

gcloud

REST v1

curl (Linux, macOS ou Cloud Shell)

PowerShell (Windows)

Resposta

REST v1beta4

curl (Linux, macOS ou Cloud Shell)

PowerShell (Windows)

Resposta

Executar a DR invocando uma réplica de failover

Antes de começar

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

gcloud

REST v1

curl (Linux, macOS ou Cloud Shell)

PowerShell (Windows)

Resposta

REST v1beta4

curl (Linux, macOS ou Cloud Shell)

PowerShell (Windows)

Resposta

Verificar o status de um failover de réplica

Console

gcloud

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

Cérebro dividido durante failover da réplica

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

Limitações

Resolver problemas

A seguir