Use a recuperação de desastres (RD) avançada

Esta página descreve como usar a recuperação de desastres (RD) avançada. A recuperação de desastres avançada oferece duas capacidades principais:

  • A comutação por falha de réplica permite-lhe comutar por falha a sua instância principal para a réplica de recuperação de desastres imediatamente em caso de falha da região. Para o Cloud SQL para SQL Server, a réplica de DR é uma réplica em cascata.
  • A comutação permite-lhe inverter as funções da instância principal e de uma réplica de recuperação de desastres sem perda de dados. Pode usar a comutação para restaurar uma implementação ao respetivo estado de implementação original após a comutação por falha de réplicas ou pode usar a comutação para testar a recuperação de desastres.

A recuperação após desastre avançada só é suportada em instâncias da edição Cloud SQL Enterprise Plus.

Antes de começar

Se planeia usar o Google Cloud SDK, tem de usar a versão 502.0.0 ou posterior. Para verificar a versão do SDK Google Cloud, execute gcloud --version. Para atualizar o SDK do Google Cloud, execute gcloud components update.

Para instalar o SDK do Google Cloud, consulte o artigo Instale a CLI gcloud.

Crie uma réplica de recuperação de desastres

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

Faça uma comutação

Depois de criar uma réplica de recuperação de desastres, pode executar a operação de comutação. No entanto, como prática recomendada, evite realizar a operação de comutação nas seguintes circunstâncias:

  • A instância principal está a ser usada ativamente.
  • Estão em curso operações de administração, como a cópia de segurança automática ou a ativação ou desativação da alta disponibilidade (HA).

Para evitar um limite de tempo, considere fazer a mudança quando o volume de transações for baixo.

Quando a comutação estiver concluída, a operação faz uma cópia de segurança da nova instância principal (a antiga réplica de recuperação de desastres) assim que a nova instância principal for promovida. Esta cópia de segurança pode demorar entre 5 e 15 minutos a ser concluída, consoante o tamanho do disco. Após a conclusão desta cópia de segurança, se quiser usar a PITR na instância promovida, tem de ativar manualmente a PITR. Para mais informações sobre as considerações da utilização da PITR com a DR avançada, consulte o artigo Use a PITR com a DR avançada.

Após a conclusão da operação de comutação, vai reparar que a direção da replicação é invertida.

Depois de a instância principal antiga ser reconfigurada como uma réplica de leitura, o ponto final de gravação de DNS, que anteriormente 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 comutação, faça o seguinte:

  • Se ainda não o fez, crie uma réplica de recuperação de desastres.
  • Verifique se a instância principal e a réplica de recuperação de desastres estão online.
  • Se estiver a usar um ponto final de gravação de DNS, verifique se a configuração SSL da instância principal e da réplica de recuperação de desastres é a mesma. Por exemplo, se a réplica de DR estiver configurada para aplicar a encriptação SSL, mas a instância principal permitir ligações não encriptadas, os clientes não vão conseguir estabelecer ligação à nova instância principal após a conclusão da operação de comutação.
  • Faça uma cópia de segurança a pedido da instância principal. Esta cópia de segurança é uma precaução caso precise de recuperar de falhas inesperadas.

Realize a operação de comutação

gcloud

Para executar a operação de comutação, execute o seguinte comando:

gcloud sql instances switchover REPLICA_NAME

Substitua as seguintes variáveis:

  • REPLICA_NAME: o nome da réplica de recuperação de desastres com a qual quer que a instância principal troque de funções.

Terraform

Para iniciar a operação de comutação, use um recurso do Terraform. Para tornar a réplica de recuperação de desastres a nova instância principal, use o primeiro exemplo. O exemplo contém comentários para as alterações de configuração do Terraform que tem de fazer para mudar a instância principal e a réplica de recuperação de desastres.

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

Depois de fazer as alterações, atualize a réplica principal e de recuperação de desastres executando o comando terraform plan. Verifique se o resultado inclui Plan: 0 to add, 1 to change, 0 to destroy. Para realizar a mudança, execute terraform apply.

Neste ponto, o principal original é uma réplica da nova instância principal. No entanto, essa alteração não se reflete automaticamente no estado do Terraform. Para tornar a instância principal original uma réplica da nova instância principal no seu estado do Terraform, use o segundo exemplo. O segundo exemplo fornece comentários que descrevem as alterações que tem de fazer após executar o primeiro exemplo.

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

Se o estado do Terraform for atualizado com êxito, quando executar terraform plan no segundo exemplo, é apresentada uma mensagem semelhante à seguinte:

No changes. Your infrastructure matches the configuration.

Se executar o comando terraform apply, recebe uma mensagem semelhante à seguinte:

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

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

Método HTTP e URL: 

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

Para enviar o seu pedido, expanda uma destas opções:

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

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

Método HTTP e URL: 

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

Para enviar o seu pedido, expanda uma destas opções:

Deve receber uma resposta JSON semelhante à seguinte:

Realize a recuperação de desastres invocando uma comutação por falha de réplica

Em caso de falha da região ou desastre, pode executar a recuperação de desastres invocando uma operação de comutação por falha de réplica para a réplica de recuperação de desastres designada. Para fazer uma comutação por falha de réplica, promove a réplica de recuperação de desastres. Ao contrário da comutação, a promoção da réplica de DR é imediata.

Uma vez que a réplica de recuperação de desastres assume imediatamente a função da instância principal, é possível que a réplica não tenha todos os dados da instância principal antiga devido ao atraso na replicação. Por este motivo, uma ativação pós-falha de réplica pode incorrer em perda de dados.

Como parte do processo de promoção, a comutação por falha de réplica faz uma cópia de segurança da nova instância principal (a antiga réplica de RD) imediatamente após a réplica de RD se tornar a nova instância principal. Após a conclusão desta cópia de segurança, a recuperação num ponto específico no tempo (PITR) é totalmente ativada na nova instância principal. Esta cópia de segurança pode demorar entre 5 e 15 minutos a ser concluída, consoante o tamanho do disco da nova (e antiga) instância principal. Durante este período de cópia de segurança, a PITR não está disponível.

Quando a instância principal antiga volta a ficar online, o processo de comutação por falha da réplica faz uma cópia de segurança. Após esta cópia de segurança, a instância principal antiga é recriada como uma réplica de leitura da nova instância principal.

Para mais informações sobre as considerações da utilização da PITR com a DR avançada, consulte Use a PITR com a DR avançada.

Depois de invocar a operação de comutação por falha da réplica, o ponto final de gravação de DNS, que anteriormente era resolvido para a instância principal antiga, é resolvido para a nova instância principal.

Antes de começar

Antes de poder fazer uma comutação por falha de réplica, faça o seguinte:

Realize a operação de comutação por falha da réplica

gcloud

Para invocar uma comutação por falha de uma 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 RD

REST v1

Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

  • PROJECT_ID: o ID ou o número do projeto do Google Cloud projeto da instância principal e da réplica de recuperação de desastres.
  • REPLICA_NAME: o nome da réplica de RD.
  • ENABLE_REPLICA_FAILOVER: defina como true para usar a comutação por falha de réplica. Se definir como false, a API usa o método promoteReplica normal sem a comutação por falha 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 o seu pedido, expanda uma destas opções:

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

  • PROJECT_ID: o ID ou o número do projeto do Google Cloud projeto da instância principal e da réplica de recuperação de desastres.
  • REPLICA_NAME: o nome da réplica de RD.
  • ENABLE_REPLICA_FAILOVER: defina como true para usar a comutação por falha de réplica. Se definir como false, a API usa o método promoteReplica normal sem a comutação por falha 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 o seu pedido, expanda uma destas opções:

Deve receber uma resposta JSON semelhante à seguinte:

Verifique o estado de uma comutação por falha de réplica

A comutação por falha de réplicas ocorre em duas fases. A primeira fase é a promoção da réplica de recuperação de desastres. A segunda fase é a recriação da instância principal antiga como uma réplica de leitura.

Para verificar o estado da comutação por falha de réplicas, verifique o estado de cada fase.

  1. Verifique o estado da primeira fase.

    Consola

    Para verificar se a réplica de recuperação de desastres foi promovida a uma instância autónoma, faça o seguinte:

    1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

      Aceda a Instâncias do Cloud SQL

    2. Encontre o nome da réplica de recuperação de desastres que promoveu.
    3. Verifique se o SQL Server VERSION é apresentado na coluna Tipo para a nova instância principal.

    gcloud

    Pode verificar o estado 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 RD promovida

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

    instanceType: CLOUD_SQL_INSTANCE

  2. Para validar a conclusão da segunda fase, verifique o registo de operações na instância para a mensagem RECONFIGURE_OLD_PRIMARY.

    A apresentação desta mensagem depende do momento em que a instância principal antiga volta a ficar online, o que pode demorar minutos ou dias em caso de desastre.

    Para mais informações sobre como verificar os registos de operações numa instância, consulte o artigo Ver registos de instâncias.

Use PITR com DR avançado

Quer se trate de uma comutação ou de uma comutação por falha de réplica, se a réplica de DR for promovida a uma instância principal e quiser usar a PITR na instância promovida, tem de ativar manualmente a PITR.

Depois de a PITR ser ativada, aplicam-se as políticas de retenção do registo de transações e da configuração de cópia de segurança. Se não especificar valores para estas definições, é aplicado o valor predefinido de 14 dias.

Para mais informações, consulte o artigo Use a PITR.

Depois de a PITR ser ativada na nova instância principal, pode restaurar a instância para qualquer momento durante o qual seja uma instância principal ativa.

Divisão de cérebros durante a comutação por falha de réplica

É possível que ocorra uma divisão de cérebros quando a instância principal continua a aceitar escritas enquanto uma réplica é promovida através da comutação por falha de réplicas. Depois de a réplica ser promovida, quando a instância principal antiga estiver novamente disponível, é reconstruída como uma réplica da instância promovida e é feita uma cópia de segurança final. Esta cópia de segurança pode ser usada para recuperar quaisquer dados de divisão de cérebro que não tenham sido escritos na réplica promovida.

Eliminação de cópias de segurança e registos de transações em réplicas

Se uma instância principal que foi ativada com PITR e cópias de segurança se tornar uma réplica de leitura, a última política de retenção de PITR e cópias de segurança do seu tempo como instância principal é preservada e aplicada durante o seu tempo como réplica. Embora a nova instância principal não esteja a fazer cópias de segurança, as cópias de segurança antigas e os registos de transações usados para a recuperação pontual são eliminados na réplica de leitura de acordo com a última política configurada.

Por exemplo, se a instância estiver configurada para ter cópias de segurança automáticas diárias e manter 7 cópias de segurança com 7 dias de registos de PITR, quando esta instância se torna uma réplica de leitura, tudo o que tiver mais de 7 dias é eliminado uma vez por dia.

Se precisar de eliminar cópias de segurança mais cedo, pode removê-las manualmente. Para mais informações, consulte o artigo Elimine uma cópia de segurança.

Recomendações para o VPC Service Controls e a RD avançada

Se usar os VPC Service Controls, certifique-se de que os seus perímetros de serviço permitem as comunicações necessárias para todas as operações de recuperação, como as operações de recuperação num determinado momento (PITR), especialmente quando usa as CMEK com chaves num projeto diferente.

As operações de DR avançadas, como a comutação e a comutação por falha de réplicas, podem ativar ou reconfigurar funcionalidades como a PITR, que podem ser bloqueadas pelos VPC Service Controls se os perímetros de serviço não estiverem configurados corretamente para a CMEK e o acesso à chave entre projetos.

  • Mantenha o projeto da chave do KMS no mesmo perímetro que a instância: como prática recomendada, inclua o projeto que contém a chave do KMS no mesmo perímetro do VPC Service Controls que as suas instâncias do Cloud SQL.
  • Use uma ponte de perímetro: como opção secundária (menos recomendada), pode usar uma ponte de perímetro para ligar projetos em perímetros diferentes.
  • Teste: use o modo de teste do VPC Service Controls para testar os seus procedimentos de DR (como a comutação) e identificar potenciais violações do VPC Service Controls sem aplicação.

Para mais informações, consulte o artigo Configure VPC Service Controls.

Limitações

  • Não pode 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 respetivos registos de transações para recuperação num determinado momento (PITR) no disco. Para verificar onde uma instância armazena os respetivos registos para a PITR, consulte o artigo Verifique a localização de armazenamento dos registos de transações usados para a PITR.

  • Não pode designar uma réplica externa como réplica de DR.

  • O Terraform não é suportado para operações de comutação por falha de réplicas.

  • Não pode usar a Google Cloud consola para realizar operações de comutação por falha ou comutação de réplicas.

Resolver problemas

Problema Resolução de problemas
A operação de comutação falhou.
    Certifique-se de que a instância cumpre todos os requisitos da réplica de DR(réplica em cascata) indicados.
  • Verifique o volume de transações na base de dados. Se o volume de transações for elevado, a operação pode exceder o tempo limite. Considere tentar novamente a operação quando a carga de transações for inferior.
A operação de comutação falhou e a instância principal está bloqueada no modo só de leitura. Reinicie a base de dados para repor a instância principal no modo de escrita.
A operação de comutação foi concluída, mas a Google Cloud consola não mostra as novas funções invertidas para as instâncias. Atualize o navegador para mostrar a topologia atualizada.
A operação de comutação por falha da réplica falhou.
  • Certifique-se de que criou uma réplica de DR para a instância principal e que a réplica de DR está online.
  • Se a comutação por falha para a réplica de recuperação de desastres tiver falhado, promova-a a uma réplica de leitura normal (não de recuperação de desastres).

O que se segue?