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.
  • 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.

Designe uma réplica de RD

Para realizar a recuperação de desastres avançada, primeiro tem de designar uma réplica de RD entre regiões.

Requisitos da instância principal

A instância principal tem de ser uma instância da edição Cloud SQL Enterprise Plus e ter uma réplica de recuperação de desastres designada.

Tem de ativar a recuperação pontual (PITR) na instância principal. Para ativar a PITR, consulte o artigo Use a recuperação pontual (PITR).

Se estiver a criar a instância do Cloud SQL com um ponto final de gravação de DNS, a instância principal tem de ter a mesma configuração SSL que a réplica de DR designada antes de invocar a operação de comutação ou de replicação de tolerância a falhas. Por exemplo, se configurar a réplica de DR para aplicar a encriptação SSL, mas a instância principal permitir ligações não encriptadas, os clientes não vão conseguir ligar-se à nova instância principal após a conclusão da operação de comutação ou de failover.

Requisitos de réplica de RD

A réplica de leitura de recuperação de desastres designada tem de cumprir os seguintes requisitos:

  • Tem de ser uma instância da edição Enterprise Plus do Cloud SQL
  • Tem de ser a mesma versão da base de dados que a instância principal, com o PostgreSQL 12 ou posterior

  • Tem de estar numa região separada da instância principal

  • Tem de ser uma réplica de leitura direta; não pode ser uma réplica em cascata

  • Se estiver configurado com uma flag que exija que a réplica tenha um valor igual ou superior ao da instância principal, a flag tem de ser configurada com um valor igual ao da instância principal. Tenha em atenção que, dependendo do tipo de máquina (nível) e do tamanho da instância da réplica de DR, os valores predefinidos podem ser diferentes, mesmo que não os tenha definido explicitamente. Estas flags são as seguintes:

    • max_connections
    • max_worker_processes
    • max_wal_senders
    • max_prepared_transactions
    • max_parallel_workers
    • max_locks_per_transaction
    • max_parallel_maintenance_workers
    • max_parallel_workers_per_gather

  • Não pode ter a flag cloudsql.logical_decoding configurada; não pode ter nenhuma ranhura lógica nem replicação lógica configurada

  • Tem de armazenar os registos de transações usados para PITR no Cloud Storage

  • Não pode ser uma réplica externa

Recomendações de réplicas de RD

Esta secção fornece recomendações para a sua réplica de recuperação de desastres. As seguintes recomendações podem ajudar a evitar problemas de desempenho na sua implementação:

  • Use o mesmo tamanho do disco que a instância principal ou ative o crescimento automático.
  • Use uma configuração de HA consistente. Se ativar a HA na instância principal, também deve ativar a HA na réplica de DR.
  • Use uma configuração de cache de dados consistente. Se ativar a cache de dados na instância principal, também deve ativar a cache de dados na réplica de recuperação de desastres.
  • Configure todas as flags de base de dados adequadas para a réplica de recuperação de desastres antes e depois de quaisquer operações de comutação ou de replicação de tolerância a falhas.
  • Use o mesmo tipo (nível) e tamanho de máquina para a instância principal e a réplica de recuperação de desastres.

Crie uma réplica para satisfazer os requisitos de réplica de RD

Se a instância principal ainda não tiver uma réplica de leitura entre regiões que satisfaça os requisitos da réplica de DR, crie uma.

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Encontre a instância principal.
  3. Na coluna Ações, clique no menu Mais ações.
  4. Selecione Criar réplica de leitura.
  5. No campo ID da instância, introduza um nome para a réplica de recuperação de desastres.
  6. No campo Versão da base de dados, é selecionada automaticamente a mesma versão principal da instância principal.
  7. Na secção Escolha uma região e a disponibilidade por zona da página, faça o seguinte:
    • Selecione uma região _diferente_ da região da sua instância principal.
    • Opcional. Selecione Várias zonas para a réplica de recuperação de desastres.
    • Opcional. Selecione as zonas principais e secundárias para a réplica de DR.
  8. Na secção Personalize a sua instância da página, pode atualizar as definições da sua réplica de recuperação de desastres. Para mais detalhes sobre cada definição, consulte a página Acerca das definições da instância.
  9. Para Formas de máquinas, selecione o mesmo tipo de máquina que a sua instância principal.
  10. Para Sinalizações, configure todas as sinalizações necessárias para a sua base de dados.
  11. Clique em Criar réplica.

O Cloud SQL cria uma cópia de segurança da instância principal e cria a réplica. Regressa à página da instância para o servidor principal.

gcloud

Para criar uma réplica que cumpra os requisitos de uma réplica de recuperação de desastres, execute o seguinte comando:

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

Substitua as seguintes variáveis:

  • REPLICA_NAME: o nome da réplica de RD.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • REPLICA_REGION_NAME: especifique uma região diferente da região da instância principal.
  • DATABASE_VERSION: especifique a string de versão que corresponde à versão principal e secundária da base de dados da instância principal, por exemplo, POSTGRES_16.

    As versões principais e secundárias da base de dados têm de ser iguais para a réplica principal e de recuperação de desastres.

  • MACHINE_TYPE: especifique o mesmo tipo de máquina que a instância principal. Recomendamos que o tipo de máquina corresponda ao tipo de máquina da instância principal.
  • AVAILABILITY_TYPE: se a instância principal estiver configurada para alta disponibilidade, recomendamos que especifique REGIONAL para ativar a alta disponibilidade.
  • EDITION: especifique ENTERPRISE_PLUS.

Terraform

Para criar uma réplica de recuperação de desastres, use um recurso do Terraform.

resource "google_sql_database_instance" "original-primary" {
  name   = "postgres-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and point-in-time-recovery (PITR).
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name = "postgres-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "POSTGRES_12"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

REST v1

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

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • 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.
  • String da versão DATABASE_VERSION: que corresponde à versão da base de dados da instância principal, por exemplo, POSTGRES_16. A versão da base de dados tem de ser a mesma para a réplica principal e de recuperação de desastres.
  • REPLICA_NAME: o nome da instância de réplica de RD que está a criar.
  • REPLICA_REGION: a região da instância de réplica de RD. A região da réplica tem de ser diferente da região da instância principal.
  • MACHINE_TYPE: especifique o mesmo tipo de máquina que a instância principal. Recomendamos que selecione o mesmo tipo de máquina que a instância principal.
  • AVAILABILITY_TYPE: se a instância principal estiver configurada para alta disponibilidade, recomendamos que especifique REGIONAL para ativar a alta disponibilidade.

Método HTTP e URL: 

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

Corpo JSON do pedido: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • 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.
  • String da versão DATABASE_VERSION: que corresponde à versão da base de dados da instância principal, por exemplo, POSTGRES_16. A versão da base de dados tem de ser a mesma para a réplica principal e de recuperação de desastres.
  • REPLICA_NAME: o nome da instância de réplica de RD que está a criar.
  • REPLICA_REGION: a região da instância de réplica de RD. A região da réplica tem de ser diferente da região da instância principal.
  • MACHINE_TYPE: especifique o mesmo tipo de máquina que a instância principal. Recomendamos que o tamanho do disco corresponda ao tamanho do disco da instância principal.
  • AVAILABILITY_TYPE: se a instância principal estiver configurada para alta disponibilidade, recomendamos que especifique REGIONAL para ativar a alta disponibilidade.

Método HTTP e URL: 

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

Corpo JSON do pedido: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Designe a réplica de DR para a instância principal

Os procedimentos seguintes descrevem como designar uma das réplicas entre regiões de uma instância principal como uma réplica de DR para comutação ou replicação de tolerância a falhas.

Consola

Para designar uma réplica de recuperação de desastres para uma instância principal, 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 e selecione a instância principal. É apresentada a página Vista geral da instância principal.
  3. No menu de navegação, clique em Réplicas.
  4. Na lista de réplicas de leitura, encontre a réplica de leitura entre regiões que quer designar como réplica de recuperação de desastres.
  5. Para a réplica, clique no botão more_vert Ações e selecione Designar como réplica de DR.
  6. Clique em Confirm.

gcloud

Para designar uma réplica de DR para uma instância principal, use o seguinte comando:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

Substitua as seguintes variáveis:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • REPLICA_NAME: o nome da réplica de RD.

Terraform

Para designar uma réplica de recuperação de desastres para uma instância principal, use um recurso do Terraform.

data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    # Designate the DR replica.
    # The format for setting the DR replica is `project-id:dr-replica-name`.
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name                 = "postgres-dr-replica-instance"
  region               = "us-west2"
  database_version     = "POSTGRES_12"
  instance_type        = "READ_REPLICA_INSTANCE"
  master_instance_name = google_sql_database_instance.original-primary.name

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

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

REST v1

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

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • REPLICA_NAME: o nome da réplica de RD.

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON do pedido: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • REPLICA_NAME: o nome da réplica de RD.

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON do pedido: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Altere a designação da réplica de recuperação de desastres

Se a réplica cumprir os requisitos, pode designar uma réplica diferente como réplica de recuperação de desastres. A réplica de DR antiga perde a designação de réplica de DR.

Consola

Para alterar a réplica de recuperação de desastres de uma instância principal, 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 e selecione a instância principal. É apresentada a página Vista geral da instância principal.
  3. No menu de navegação, clique em Réplicas.
  4. Na lista de réplicas de leitura, encontre a réplica de leitura entre regiões que quer designar como a nova réplica de DR.
  5. Para a réplica, clique no botão more_vert Ações e selecione Designar como réplica de DR.

gcloud

Para alterar a réplica de DR, execute novamente o comando designate e especifique uma réplica de DR diferente.

REST

Para alterar a réplica de recuperação de desastres, faça novamente o pedido da API designate e especifique uma réplica de recuperação de desastres diferente.

Veja a designação da réplica de RD

Pode verificar que réplica de recuperação de desastres está atribuída à instância principal através da CLI gcloud ou da API Cloud SQL Admin. Também pode verificar se uma réplica é uma réplica de DR designada.

Para saber qual a réplica de DR designada para uma instância principal, use o seguinte procedimento.

Consola

Para saber qual a réplica de leitura que é a réplica de DR designada para uma instância primária, 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 e selecione a instância principal. É apresentada a página Vista geral da instância principal.
  3. No menu de navegação, clique em Réplicas.
  4. Na lista de réplicas de leitura, verifique se PostgreSQL disaster recovery replica é apresentado na coluna Tipo para a réplica de DR designada.

gcloud

Para saber qual é a instância de DR designada de uma instância principal, use o seguinte comando:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Substitua a seguinte variável:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal

O resultado deste comando contém o campo denominado failoverDrReplica que identifica a réplica de recuperação de desastres designada.

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 que contém a instância.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.

Método HTTP e URL: 

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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 que contém a instância.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.

Método HTTP e URL: 

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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

Deve receber uma resposta JSON semelhante à seguinte:

Para verificar se uma réplica é uma réplica de DR, use um dos seguintes procedimentos.

Consola

Para verificar se uma instância de réplica é uma réplica de DR, 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 a instância de réplica.
  3. Verifique se PostgreSQL disaster recovery replica é apresentado na coluna Tipo para a réplica de DR designada.

gcloud

Para verificar se uma instância de réplica é uma réplica de DR, execute o seguinte comando:

gcloud sql instances describe REPLICA_NAME

Substitua a seguinte variável:

  • REPLICA_NAME: o nome da réplica de leitura que quer verificar

Se a réplica for uma réplica de DR, o resultado do comando contém o campo drReplica=true.

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 que contém a instância.
  • REPLICA_NAME: o nome da réplica.

Método HTTP e URL: 

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

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 que contém a instância.
  • REPLICA_NAME: o nome da réplica.

Método HTTP e URL: 

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Remova a réplica de RD

Pode limpar a designação de réplica de recuperação de desastres de uma instância principal. No entanto, se não for atribuída nenhuma réplica de recuperação de desastres a uma instância principal, não pode realizar a comutação ou a comutação por falha de réplica.

Consola

Para remover uma réplica de recuperação de desastres designada de uma instância principal, 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 e selecione a instância principal. É apresentada a página Vista geral da instância principal.
  3. No menu de navegação, clique em Réplicas.
  4. Na lista de réplicas de leitura, encontre a réplica de leitura entre regiões que quer remover.
  5. Para a réplica, clique no botão more_vert Ações e selecione Remover como réplica de DR.
  6. Clique em Confirm.

gcloud

Para remover a designação de réplica de recuperação de desastres, execute o seguinte comando na instância principal:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

Substitua a seguinte variável:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal da qual quer remover a réplica de DR designada

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.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • Defina o campo failoverDrReplicaName como uma string vazia.

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON do pedido: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • Defina o campo failoverDrReplicaName como uma string vazia.

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON do pedido: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Faça uma comutação

Depois de designar 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. Após a conclusão desta cópia de segurança, a recuperação num determinado momento (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. A cobertura da PITR só começa depois de esta cópia de segurança estar concluída. 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:

  • Designe uma réplica de DR. Só pode fazer uma comutação entre a instância principal e a réplica de recuperação de desastres designada.
  • Verifique se a instância principal e a réplica de recuperação de desastres estão online.
  • Certifique-se de que a réplica de recuperação de desastres está a executar a mesma versão da base de dados que a instância principal, ou seja, o PostgreSQL 12 ou posterior.
  • Certifique-se de que a PITR está ativada na instância principal. Para ativar a PITR, consulte o artigo Use a recuperação pontual (PITR).
  • Certifique-se de que a instância principal e a réplica de recuperação de desastres não têm a flag cloudsql.logical_decoding configurada. Nenhuma das instâncias pode ter slots lógicos ou replicação lógica configurados.
  • 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 DR é 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

Consola

Para realizar a operação de comutação, 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 a réplica de DR designada da instância principal.
  3. Clique na instância de réplica de DR. É apresentada a página Vista geral da réplica de DR.
  4. Clique no botão Mudar.
  5. Na página Realize a comutação entre a réplica principal e a de recuperação de desastres, introduza o nome da instância principal no campo ID da instância.
  6. Clique em Comutação.

gcloud

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

gcloud sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

Substitua as seguintes variáveis:

  • REPLICA_NAME: o nome da réplica de DR designada com a qual quer que a instância principal troque de funções.
  • TIMEOUT_DURATION: opcional. O período de limite de tempo para permitir a conclusão das operações da base de dados na instância.

    • Se não especificar este parâmetro, a operação de comutação inclui um limite de tempo de 10 minutos.

    Pode aumentar o valor deste limite de tempo especificando o parâmetro --db-timeout. Substitua TIMEOUT_DURATION por uma duração de período de até 24 horas, incluindo uma notação inicial para o formato. Por exemplo, para 30 segundos, especifique 30s. Para 24 horas, especifique 24h. Também pode especificar unidades fracionárias do período usando decimais até 9 casas. Por exemplo, para 30,5 minutos, especifique 30.5m.

    Se não tiver operações pendentes, pode diminuir o valor deste limite de tempo.

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.

#
# This sample provides the first part of the switchover operation and turns the DR replica
# into the new primary instance.
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  # Remove or comment out the master_instance_name from the DR replica.
  # master_instance_name = google_sql_database_instance.original-primary.name
  # Add the original primary instance to a list of replicas for the new primary.
  replica_names = [google_sql_database_instance.original-primary.name]

  # Designate the original primary instance as the DR replica of the new primary instance.
  # The format for setting the DR replica is `project-id:dr-replica-name`.
  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Add a backup configuration section to enable automated backups and point-in-time-recovery (PITR) for the new primary instance.
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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.

# This sample provides the second part of the switchover operation and makes the original primary instance
# a replica of the new primary instance. After you run `terraform apply` for this sample, you'll see
# the following message:
#
# "No changes. Your infrastructure matches the configuration.
#
# Terraform has compared your real infrastructure against your configuration and found no differences,
# so no changes are needed.
#
# Apply complete! Resources: 0 added, 0 changed, 0 destroyed."
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  # Change instance type for the original primary from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  # Set master_instance_name to the the new primary instance, the old DR replica.
  master_instance_name = "postgres-dr-replica-instance"
  # replica_names = [] # If you previously defined a replica_names field in your template, then delete the DR replica
  # (new primary) from the list of replicas.  Don't delete the entire replica_names field.
  # Instead set the field to an empty string. For example, replica_names = [""].

  replication_cluster {
    # This instance no longer requires a designated DR replica since it's a replica.
    # Remove the DR replica designation by setting the field to an empty string.
    failover_dr_replica_name = ""
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Disable automated backups and PITR because this instance is now a replica.
      enabled                        = false
      point_in_time_recovery_enabled = false
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"
  replica_names    = [google_sql_database_instance.original-primary.name]


  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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 DR invocando uma comutação por falha de réplica

Em caso de falha da região ou desastre, pode executar a DR invocando uma operação de comutação por falha de réplica para a réplica de DR designada. Para fazer uma comutação por falha de réplica, promove a réplica de recuperação de desastres designada. 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:

  • Se ainda não o fez, designe uma réplica de recuperação de desastres. Só pode realizar uma comutação por falha de réplica entre a instância principal e a réplica de recuperação de desastres designada.
  • Certifique-se de que a réplica de recuperação de desastres está online e em bom estado.
  • Certifique-se de que a réplica de recuperação de desastres está a executar a mesma versão da base de dados que a instância principal, ou seja, o PostgreSQL 12 ou posterior.
  • Certifique-se de que a PITR está ativada na instância principal. Para ativar a PITR, consulte o artigo Use a recuperação pontual (PITR).
  • Certifique-se de que a instância principal e a réplica de recuperação de desastres não têm a flag cloudsql.logical_decoding configurada. Nenhuma das instâncias pode ter espaços lógicos ou replicação lógica configurados. Se invocar a comutação por falha da réplica e o primário original tiver a descodificação lógica ativada, quando o primário original se torna uma réplica de leitura, todos os slots lógicos configurados na instância primária original são perdidos.

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

Consola

Para realizar a operação de comutação por falha da réplica, 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. Clique na instância de réplica de DR. É apresentada a página Vista geral da réplica de DR.
  3. Clique no botão Replicação de segurança.
  4. Na página Realize uma comutação por falha da réplica entre a réplica principal e a de recuperação de desastres, introduza o nome da instância principal no campo ID da instância para confirmar que quer continuar com a operação.
  5. Para iniciar a comutação por falha da réplica, clique em Replica Failover (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 PostgreSQL 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

Com a comutação e a comutação por falha da réplica, assim que a réplica de DR é promovida a uma instância principal, ocorrem as seguintes alterações para suportar a cópia de segurança e a PITR:

  • A configuração da cópia de segurança, incluindo qualquer agendamento de cópias de segurança automatizado, é copiada da instância principal antiga para a nova instância principal.

  • É feita uma nova cópia de segurança para suportar a PITR na nova instância principal.

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

Tanto para a configuração de cópia de segurança como para as políticas de retenção de registos de transações, recomendamos que verifique se as definições herdadas da instância principal antiga estão corretas para a nova instância principal.

Início da cobertura de PITR

No final da operação de comutação, o Cloud SQL agenda cópias de segurança automáticas e faz a primeira cópia de segurança da nova instância principal. Se quiser que a cobertura de PITR comece o mais cedo possível, recomendamos que verifique se a primeira cópia de segurança foi bem-sucedida. A instância principal recém-promovida tem cobertura de PITR apenas após a conclusão bem-sucedida da primeira cópia de segurança automatizada.

Para mais informações sobre como ver as cópias de segurança disponíveis para uma instância, consulte o artigo Ver uma lista de cópias de segurança.

Cobertura da PITR para instâncias durante a comutação e a comutação por falha de réplicas

Quando uma instância participa numa comutação ou numa operação de comutação por falha de réplica, a instância passa algum tempo como uma réplica de leitura. A PITR e o restauro de uma cópia de segurança são suportados durante o período em que a instância funciona como uma réplica de leitura e como uma instância principal.

Pode executar a PITR para um momento anterior à comutação quando a instância era uma instância principal. Para as operações de comutação e de comutação por falha de réplica, o Cloud SQL inicia uma cópia de segurança de melhor esforço para a nova instância principal assim que a nova instância principal é promovida. A PITR é ativada na instância promovida apenas após a conclusão desta cópia de segurança. Esta cópia de segurança pode demorar entre 5 e 15 minutos a ser concluída, consoante o tamanho do disco.

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 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 período em que era uma instância principal é preservada e aplicada durante o período em que é uma 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.

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 uma réplica de DR.

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

Resolver problemas

Problema Resolução de problemas
A operação de comutação falhou.
  • Verifique o volume de transações na base de dados. Se o volume de transações for elevado, a operação pode exceder o limite de tempo. 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.
  • Se a comutação por falha para a réplica de recuperação de desastres falhou, promova-a a uma réplica de leitura normal (não de recuperação de desastres).

O que se segue?