Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

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

MySQL | PostgreSQL | SQL Server

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.

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 principal e secundária da base de dados que a instância principal, com o MySQL 8.0.31 ou posterior
Tem de ter o registo binário ativado. Não pode desativar o registo binário enquanto a instância for uma réplica de recuperação de desastres designada.

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

Além de usar os valores predefinidos, a réplica de recuperação de desastres não pode ter nenhuma das seguintes flags configuradas:
- replicate_do_db
- replicate_ignore_db
- replicate_do_table
- replicate_wild_do_table
- replicate_ignore_table
- replicate_wild_ignore_table

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

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

Aceda a Instâncias do Cloud SQL
Encontre a instância principal.
Na coluna Ações, clique no menu Mais ações.
Selecione Criar réplica de leitura.
No campo ID da instância, introduza um nome para a réplica de recuperação de desastres.
No campo Versão da base de dados, é selecionada automaticamente a mesma versão principal da instância principal.
Se estiver a usar o MySQL 8.0, no campo Versão secundária, mantenha a versão secundária pré-selecionada. A réplica de recuperação de desastres e a instância principal têm de partilhar a mesma versão secundária da base de dados.
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.
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.
Para Formas de máquinas, selecione o mesmo tipo de máquina que a sua instância principal.
Para Sinalizações, configure todas as sinalizações necessárias para a sua base de dados.
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, MYSQL_8_0_31.
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   = "mysql-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "MYSQL_8_0"
  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 binary logging.
      enabled            = true
      binary_log_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 = "mysql-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 = "MYSQL_8_0"
  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 Trusted 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 principal e secundária da instância principal, por exemplo, MYSQL_8_0_31. 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:

curl (Linux, macOS ou Cloud Shell)

Nota: O comando seguinte pressupõe que tem sessão iniciada na CLI gcloud com a sua conta de utilizador executando gcloud init ou gcloud auth login, ou usando o Cloud Shell, que inicia automaticamente sessão na CLI gcloud. Pode verificar a conta atualmente ativa executando o comando gcloud auth list.

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Nota: O comando seguinte pressupõe que iniciou sessão na CLI do Google Cloud com a sua conta de utilizador executando gcloud init ou gcloud auth login .gcloud Pode verificar a conta atualmente ativa executando o comando gcloud auth list.

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

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

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 Trusted 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 principal e secundária da instância principal, por exemplo, MYSQL_8_0_31. 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:

curl (Linux, macOS ou Cloud Shell)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

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

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:

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

Aceda a Instâncias do Cloud SQL
Encontre e selecione a instância principal. É apresentada a página Vista geral da instância principal.
No menu de navegação, clique em Réplicas.
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.
Para a réplica, clique no botão more_vert Ações e selecione Designar como réplica de DR.
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   = "mysql-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "MYSQL_8_0"
  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}:mysql-dr-replica-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 binary logging.
      enabled            = true
      binary_log_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 = "mysql-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 = "MYSQL_8_0"
  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
  # 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:

curl (Linux, macOS ou Cloud Shell)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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:

curl (Linux, macOS ou Cloud Shell)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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:

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

Aceda a Instâncias do Cloud SQL
Encontre e selecione a instância principal. É apresentada a página Vista geral da instância principal.
No menu de navegação, clique em Réplicas.
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.
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:

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

Aceda a Instâncias do Cloud SQL
Encontre e selecione a instância principal. É apresentada a página Vista geral da instância principal.
No menu de navegação, clique em Réplicas.
Na lista de réplicas de leitura, verifique se MySQL 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 Trusted 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:

curl (Linux, macOS ou Cloud Shell)

Execute o seguinte comando:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Execute o seguinte comando:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "MYSQL_8_0_31",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "MYSQL_8_0_31",
  "maintenanceVersion": "MYSQL_8_0_31.R20240207.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

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

curl (Linux, macOS ou Cloud Shell)

Execute o seguinte comando:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Execute o seguinte comando:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "MYSQL_8_0_31",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "MYSQL_8_0_31",
  "maintenanceVersion": "MYSQL_8_0_31.R20240207.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

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:

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

Aceda a Instâncias do Cloud SQL
Encontre a instância de réplica.
Verifique se MySQL 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 Trusted 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:

curl (Linux, macOS ou Cloud Shell)

Execute o seguinte comando:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME"

PowerShell (Windows)

Execute o seguinte comando:

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

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

Deve receber um código de estado de êxito (2xx) e uma resposta vazia.

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

curl (Linux, macOS ou Cloud Shell)

Execute o seguinte comando:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME"

PowerShell (Windows)

Execute o seguinte comando:

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

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

Deve receber um código de estado de êxito (2xx) e uma resposta vazia.

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:

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

Aceda a Instâncias do Cloud SQL
Encontre e selecione a instância principal. É apresentada a página Vista geral da instância principal.
No menu de navegação, clique em Réplicas.
Na lista de réplicas de leitura, encontre a réplica de leitura entre regiões que quer remover.
Para a réplica, clique no botão more_vert Ações e selecione Remover como réplica de DR.
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 Trusted 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:

curl (Linux, macOS ou Cloud Shell)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

curl (Linux, macOS ou Cloud Shell)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

PowerShell (Windows)

Guarde o corpo do pedido num ficheiro com o nome request.json, e execute o seguinte comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

Aceda a Instâncias do Cloud SQL
Encontre a réplica de DR designada da instância principal.
Clique na instância de réplica de DR. É apresentada a página Vista geral da réplica de DR.
Clique no botão Mudar.
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.
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             = "mysql-original-primary-instance"
  region           = "us-east1"
  database_version = "MYSQL_8_0"
  instance_type    = "CLOUD_SQL_INSTANCE"

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

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled            = true
      binary_log_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             = "mysql-dr-replica-instance"
  region           = "us-west2"
  database_version = "MYSQL_8_0"
  # 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 binary logging for the new primary instance.
      enabled            = true
      binary_log_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             = "mysql-original-primary-instance"
  region           = "us-east1"
  database_version = "MYSQL_8_0"
  # 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 = "mysql-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 because this instance is now a replica.
      enabled            = false
      binary_log_enabled = true
    }
  }
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "mysql-dr-replica-instance"
  region           = "us-west2"
  database_version = "MYSQL_8_0"
  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
      binary_log_enabled = true
    }
  }
  deletion_protection = false
}

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

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/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/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Deve receber uma resposta JSON semelhante à seguinte:

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 qualquer um dos dados do pedido, faça as seguintes substituições:

PROJECT_ID: o ID ou o número do projeto da Trusted 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:

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

Deve receber uma resposta JSON semelhante à seguinte:

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"
}

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.

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:

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

Aceda a Instâncias do Cloud SQL
Encontre a réplica de DR designada da instância principal.
Clique na instância de réplica de DR. É apresentada a página Vista geral da réplica de DR.
Clique no botão Replicação de segurança.
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.
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 Trusted 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:

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

Deve receber uma resposta JSON semelhante à seguinte:

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 qualquer um dos dados do pedido, faça as seguintes substituições:

PROJECT_ID: o ID ou o número do projeto do Trusted 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:

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

Deve receber uma resposta JSON semelhante à seguinte:

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"
}

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.

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 Trusted 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 MySQL 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
```
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.

Se estiver desativada, o indicador de configuração do binlog é ativado para ativar a PITR.

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

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 o PITR, que podem ser bloqueadas pelos VPC Service Controls se os perímetros de serviço não estiverem configurados corretamente para o 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 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.	Certifique-se de que a instância cumpre todos os requisitos de réplica de recuperação de desastres indicados. Verifique o volume de transações na base de dados. A comutação protege os registos binários da instância principal no Cloud Storage antes de realizar a comutação. 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 Trusted 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 uma réplica de recuperação de desastres está designada para a instância principal e está online. 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).
Não consigo saber se a replicação não está a ocorrer	Ligue-se à réplica e escreva: show slave status; Se a replicação estiver a ocorrer, a primeira coluna "`Slave_IO_State`" mostra "`Waiting for master to send event`" e o campo "`Last_IO_Error`" está vazio. Se a replicação não estiver a ocorrer, a primeira coluna `"Slave_IO_State"` mostra `"Connecting to master"`. e o campo `"Last_IO_Error"` mostra um erro semelhante a `"error connecting to master 'cloudsqlreplica@x.x.x.x:3306"`. Também pode ver o estado da replicação das réplicas no painel de controlo de monitorização do Cloud SQL. Para mais informações, consulte o artigo Monitorize instâncias do Cloud SQL.
Recebeu a seguinte mensagem de erro: `"Instance was converted into a replica between the target PITR time and the last available base backup. PITR logs are not available for the period instance was a replica. Please clone from the instance that was primary at time %s"`	Não pode realizar PITR para um período de tempo em que uma instância foi sujeita a uma comutação para uma réplica. Os registos PITR não estão disponíveis para o período em que a instância era uma réplica. Reveja a lista de operações da instância para determinar se a instância era uma réplica nesse momento Use a lista de operações para determinar qual foi a instância principal nesse momento. Clone essa instância para realizar a PITR.
Recebeu a seguinte mensagem de erro: `"You can only designate a disaster recovery (DR) replica for primary instances that are storing their PITR logs in Cloud Storage. PITR logs of the instance %s are not stored in Cloud Storage"`	A sua instância principal ainda não mudou a localização de armazenamento dos respetivos registos de transações para o Cloud Storage. Pode tentar novamente depois de mudar a localização de armazenamento dos registos de transações ou pode tentar designar uma réplica de DR para uma instância principal diferente. Para mais informações sobre como mover a localização do armazenamento dos registos de transações usados para a PITR, consulte o artigo Usar a recuperação num ponto específico no tempo (PITR).
Recebeu a seguinte mensagem de erro: `"The specified failover dr replica name REPLICA_NAME must be one of the replicas of the primary instance INSTANCE_NAME`."	Para mais informações sobre como designar uma réplica de recuperação de desastres e a sintaxe de comando correta, consulte o artigo Designar a réplica de recuperação de desastres para a instância principal.

O que se segue?

Veja todos os Trusted Cloud by S3NS serviços disponíveis em localizações em todo o mundo.
Leia acerca da observabilidade da base de dados
Monitorize instâncias do Cloud SQL