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

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

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

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

Antes de começar

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

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

Designar uma réplica de DR

Para executar a DR avançada, primeiro é necessário designar uma réplica de DR entre regiões.

Requisitos de réplica de DR

A réplica de leitura de DR designada precisa atender aos seguintes requisitos:

  • Precisa ser uma instância da edição Cloud SQL Enterprise Plus
  • Precisa ser a mesma versão principal e secundária do banco de dados que a instância principal, executando o MySQL 8.0.31 ou posterior
  • Precisa estar em uma região separada da instância principal
  • Precisa ser uma réplica de leitura direta. Não pode ser uma réplica em cascata
  • Além de usar os valores padrão, a réplica de DR 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
  • É necessário armazenar os registros de transação usados para a PITR no Cloud Storage.
  • Não pode ser uma réplica externa

Recomendações de réplicas de DR

Nesta seção, fornecemos recomendações para sua réplica de DR. As recomendações a seguir podem ajudar a evitar problemas de desempenho na implantação:

  • Use o mesmo tamanho de disco que a instância principal ou ative o crescimento automático.
  • Use uma configuração de alta disponibilidade consistente. Se você ativar a alta disponibilidade na instância principal, ative também a alta disponibilidade na réplica de DR.
  • Use uma configuração consistente de cache de dados. Se você ativar o cache de dados na instância principal, ative também o cache de dados na réplica de DR.
  • Configure as flags de banco de dados apropriadas para sua réplica de DR antes e depois de qualquer operação de alternância ou de failover de réplica.

Criar uma réplica para atender aos requisitos de réplica de DR

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

Console

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

    Acesse "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, insira um nome para a réplica de DR.
  6. No campo Database version, MySQL 8.0 já está selecionado.
  7. No campo Minor version, mantenha a versão secundária pré-selecionada. A réplica de DR e a instância principal precisam compartilhar a mesma versão secundária do banco de dados.
  8. Na seção Escolher uma disponibilidade por região e 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 DR.
    • Opcional. Selecione as zonas primárias e secundárias para a réplica de DR.
  9. Na seção Personalizar sua instância da página, é possível atualizar as configurações da sua réplica de DR. Para mais detalhes sobre cada configuração, consulte a página de configurações da instância.
  10. Em Formas de máquina, selecione o mesmo tipo de máquina da instância principal.
  11. Em Flags, configure as flags necessárias para seu banco de dados.
  12. Clique em Criar réplica.

O Cloud SQL cria um backup da instância principal e cria a réplica. Você retorna à página da instância principal.

gcloud

Para criar uma réplica que atenda aos requisitos de uma réplica de DR, 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 DR.
  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • REPLICA_REGION_NAME: especifique uma região diferente da instância principal.
  • DATABASE_VERSION: especifique a string da versão que corresponde às versões principal e secundária do banco de dados da instância principal. Por exemplo, MYSQL_8_0_31.

    As versões principal e secundária do banco de dados precisam ser as mesmas para a réplica principal e de DR.

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

REST v1

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

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • DATABASE_VERSION: string de versão que corresponde às versões principal e secundária do banco de dados da instância principal, por exemplo, MYSQL_8_0_31. As versões principal e secundária do banco de dados precisam ser as mesmas para a réplica principal e de DR.
  • REPLICA_NAME: o nome da instância da réplica de DR que você está criando.
  • REPLICA_REGION: a região da instância de réplica de DR. A região da réplica precisa ser diferente da região da instância principal.
  • MACHINE_TYPE: especifique o mesmo tipo de máquina da instância principal. Recomendamos que você selecione o mesmo tipo de máquina da instância principal.
  • AVAILABILITY_TYPE: se a instância principal estiver configurada para alta disponibilidade, recomendamos que você especifique REGIONAL para ativar a alta disponibilidade.

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
  "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 a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

  • PRIMARY_INSTANCE_NAME: o nome da instância principal.
  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • DATABASE_VERSION: string de versão que corresponde às versões principal e secundária do banco de dados da instância principal, por exemplo, MYSQL_8_0_31. As versões principal e secundária do banco de dados precisam ser as mesmas para a réplica principal e de DR.
  • REPLICA_NAME: o nome da instância da réplica de DR que você está criando.
  • REPLICA_REGION: a região da instância de réplica de DR. A região da réplica precisa ser diferente da região da instância principal.
  • MACHINE_TYPE: especifique o mesmo tipo de máquina da 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 você especifique REGIONAL para ativar a alta disponibilidade.

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
  "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 a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

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

Os procedimentos a seguir descrevem como designar uma das réplicas entre regiões de uma instância principal como uma réplica de DR para alternância ou failover de réplica.

Console

Para designar uma réplica de DR para uma instância principal, faça o seguinte:

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre e selecione a instância primária. A página Visão geral da instância principal é exibida.
  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 você quer designar como a réplica de DR.
  5. Para a réplica, clique no botão Ações more_vert e selecione Designar como réplica de DR.
  6. Clique em Confirmar.

gcloud

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

gcloud beta 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 DR.

REST v1

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

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

Método HTTP e URL: 

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

Corpo JSON da solicitação:

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

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

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

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

Método HTTP e URL: 

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

Corpo JSON da solicitação:

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

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

Você receberá uma resposta JSON semelhante a esta:

Alterar a designação da réplica de DR

Se a réplica atender aos requisitos, será possível designar uma réplica diferente como a réplica de DR. A antiga réplica de DR perde a designação de réplica de DR.

Console

Para alterar a réplica de DR para uma instância principal, faça o seguinte:

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre e selecione a instância primária. A página Visão geral da instância principal é exibida.
  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 você quer designar como a nova réplica de DR.
  5. Para a réplica, clique no botão Ações more_vert e selecione Designar como réplica de DR.

gcloud

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

REST

Para alterar a réplica de DR, faça a solicitação de API designada novamente e especifique uma réplica de DR diferente.

Visualizar a designação da réplica de DR

É possível verificar qual réplica de DR está atribuída à instância principal usando a gcloud CLI ou a API Cloud SQL Admin. Também é possível verificar se uma réplica é uma réplica de DR designada.

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

Console

Para descobrir qual réplica de leitura é a réplica de DR designada para uma instância principal, faça o seguinte:

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre e selecione a instância primária. A página Visão geral da instância principal é exibida.
  3. No menu de navegação, clique em Réplicas.
  4. Na lista de réplicas de leitura, verifique se MySQL disaster recovery replica aparece na coluna Tipo da réplica de DR designada.

gcloud

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

gcloud beta sql instances describe PRIMARY_INSTANCE_NAME

Substitua a seguinte variável:

  • PRIMARY_INSTANCE_NAME: o nome da instância principal

A saída desse comando contém o campo chamado failoverDrReplica, que identifica a réplica de DR designada.

REST v1

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud 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 a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud 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 a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

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

Console

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

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre a instância da réplica.
  3. Verifique se MySQL disaster recovery replica aparece na coluna Tipo da 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 beta sql instances describe REPLICA_NAME

Substitua a seguinte variável:

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

Se a réplica for de DR, a saída do comando conterá o campo drReplica=true.

REST v1

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud 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 a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud que contém a instância.
  • REPLICA_NAME: o nome da réplica.

Método HTTP e URL: 

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

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

Você receberá uma resposta JSON semelhante a esta:

Remover a réplica de DR

É possível limpar a designação de réplica de DR de uma instância principal. No entanto, se nenhuma réplica de DR estiver atribuída a uma instância principal, não será possível realizar alternância ou failover de réplica.

Console

Para remover uma réplica de DR designada de uma instância principal, faça o seguinte:

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre e selecione a instância primária. A página Visão geral da instância principal é exibida.
  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 você quer remover.
  5. Para a réplica, clique no botão Ações more_vert e selecione Remover como réplica de DR.
  6. Clique em Confirmar.

gcloud

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

gcloud beta 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 você quer remover a réplica de DR designada

REST v1

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • 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 da solicitação:

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

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

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

  • PROJECT_ID: o ID ou número do projeto do Google Cloud da instância principal e da réplica de DR.
  • 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/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON da solicitação:

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

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

Você receberá uma resposta JSON semelhante a esta:

Realizar uma alternância

Depois de designar uma réplica de DR, você pode executar a operação de alternância. No entanto, como prática recomendada, evite realizá-la nas seguintes circunstâncias:

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

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

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

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

Antes de começar

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

  • Designar uma réplica de DR. Só é possível executar a alternância entre a instância principal e a réplica de DR designada.
  • Verifique se a instância principal e a réplica de DR estão on-line.
  • Faça um backup sob demanda da instância principal. Esse backup é uma precaução caso você precise se recuperar de falhas inesperadas.

Executar a operação de alternância

Console

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

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre a réplica de DR designada da instância principal.
  3. Clique na instância de réplica de DR. A página Visão geral da réplica de DR é exibida.
  4. Clique no botão Alternar.
  5. Na página Fazer alternância entre a réplica de leitura principal e da DR, insira o nome da instância principal no campo ID da instância.
  6. Clique em Alternar.

gcloud

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

gcloud beta 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 que você quer que a instância principal troque de papel.
  • TIMEOUT_DURATION: opcional. O tempo limite para permitir a conclusão das operações do banco de dados na instância.

    • Se você não especificar esse parâmetro, a operação de alternância incluirá um tempo limite de 10 minutos.

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

    Se você não tiver operações pendentes, diminua o valor desse tempo limite.

REST v1

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

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

Método HTTP e URL: 

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

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

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

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

Método HTTP e URL: 

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

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

Você receberá uma resposta JSON semelhante a esta:

Executar a DR invocando uma réplica de failover

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

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

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

Quando a instância principal antiga fica on-line novamente, o processo de failover da réplica usa um backup. Depois que esse backup é realizado, a instância principal antiga é recriada como uma réplica de leitura da nova instância principal. Nesse processo, a instância principal antiga perde todos os registros de transações PITR antigos que ainda não foram salvos no Cloud Storage. Portanto, o failover da réplica não garante que todos os registros de transações usados para a PITR na instância principal antiga sejam preservados.

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

Importante: depois de invocar a operação de failover da réplica, indique seus aplicativos para usar o endereço IP da nova instância principal.

Antes de começar

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

  • Se você ainda não tiver feito isso, designe uma réplica de DR. Só é possível executar um failover de réplica entre a instância principal e a réplica de DR designada.
  • Verifique se a réplica de DR está on-line e íntegra.

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

Console

Para executar a operação de failover da réplica, faça o seguinte:

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

    Acesse "Instâncias do Cloud SQL"

  2. Encontre a réplica de DR designada da instância principal.
  3. Clique na instância de réplica de DR. A página Visão geral da réplica de DR é exibida.
  4. Clique no botão Failover de réplica.
  5. Na página Fazer failover de réplica entre a réplica de leitura principal e da DR, insira o nome da instância principal no campo ID da instância para confirmar que você continuar com a operação.
  6. Para iniciar o failover da réplica, clique em Failover de réplica.

gcloud

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

gcloud beta sql instances promote-replica \
   REPLICA_NAME --failover

Substitua a seguinte variável:

  • REPLICA_NAME: o nome da réplica de DR

REST v1

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

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

Método HTTP e URL: 

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

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

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

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

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

Método HTTP e URL: 

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

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

Você receberá uma resposta JSON semelhante a esta:

Verificar o status de um failover de réplica

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

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

  1. Verificar o status da primeira fase.

    Console

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

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

      Acesse "Instâncias do Cloud SQL"

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

    gcloud

    Verifique o status executando o seguinte comando:

    gcloud sql instances describe DR_REPLICA_NAME

    Substitua a seguinte variável:

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

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

    instanceType: CLOUD_SQL_INSTANCE

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

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

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

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

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

  • A configuração de backup, incluindo qualquer programação de backup automatizada, é copiada da instância principal antiga para a nova.
  • Se desativada, a flag de configuração do log binário será ativada para ativar a PITR.
  • Um novo backup é usado para dar suporte à PITR na nova instância principal.
  • A política de retenção de registros de transações é copiada da instância principal antiga para a nova.

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

Início da cobertura da PITR

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

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

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

Quando uma instância participa de uma operação de alternância ou de failover de réplica, ela passa tempo como uma réplica de leitura. a recuperação pontual (PITR, na sigla em inglês) e a restauração de um backup com suporte durante o período que a instância passa como réplica de leitura. Se você quiser executar a PITR para um momento anterior ao evento de alternância (quando a instância era principal), emita o comando de clonagem para direcionar o momento em que a instância era principal. Não é possível solicitar PITR para um momento em que a instância era uma réplica de leitura.

Se não for possível fazer a PITR porque a instância principal era uma réplica de leitura no momento de interesse, tente fazer a solicitação na instância que estava como a instância principal no momento de interesse.

Da mesma forma, é possível restaurar um backup que foi feito em um momento em que a réplica era uma instância primária. Enquanto a instância for uma réplica, o comando de restauração precisa ter como destino uma instância autônoma diferente e não pode ser restaurado na própria réplica.

Para determinar qual instância usar na solicitação PITR, use a lista de operações. A lista de operações de uma instância pode ajudar a determinar quando uma instância passou por operações de alternância ou de failover de réplica.

Cérebro dividido durante failover da réplica

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

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

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

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

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

Limitações

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

Resolver problemas

Problema Solução de problemas
Falha na operação de alternância.
  • Verifique se a instância atende a todos os requisitos de réplica de DR declarados.
  • Verifique o volume de transações no banco de dados. O Switchover protege os registros binários da instância principal no Cloud Storage antes da alternância. Se o volume de transações for alto, a operação poderá atingir o tempo limite. Tente realizar a operação novamente quando a carga da transação for menor.
A operação de alternância falhou, e a instância principal está travada no modo somente leitura. Execute uma reinicialização do banco de dados para trazer a instância principal de volta ao modo de gravação.
A operação de alternância foi concluída, mas o console do Google Cloud não mostra os novos papéis invertidos para as instâncias. Atualize seu navegador para mostrar a topologia atualizada.
Falha na operação de failover da réplica.
  • Verifique se uma réplica de DR foi designada para a instância principal e está on-line.
  • Se o failover para a réplica de DR falhar, promova a uma réplica de leitura normal (não DR).
Não é possível determinar se a replicação não está acontecendo Conecte-se à réplica e digite: 
show slave status;
  • Se a replicação estiver acontecendo, a primeira coluna "Slave_IO_State" mostrará "Waiting for master to send event" e o campo "Last_IO_Error" estará vazio.
  • Se a replicação não estiver acontecendo, a primeira coluna "Slave_IO_State" mostrará "Connecting to master". E o campo "Last_IO_Error" mostrará um erro semelhante a "error connecting to master 'cloudsqlreplica@x.x.x.x:3306".

Também é possível visualizar o status da replicação das réplicas no painel de monitoramento do Cloud SQL. Saiba mais em Monitorar instâncias do Cloud SQL.

Você 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 é possível executar a PITR por um período em que uma instância foi alternada para uma réplica. Os registros PITR não estão disponíveis para o período em que a instância era uma réplica.

  • Revise a lista de operações da instância para determinar se ela era uma réplica naquele momento
  • Use a lista de operações para determinar qual instância era a principal naquele momento.
  • Clone essa instância para executar a PITR.

Você 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"

O local de armazenamento dos registros de transação da sua instância principal ainda não foi alterado para o Cloud Storage. Tente novamente após a alteração do local de armazenamento dos registros de transação ou tente designar uma réplica de DR para uma instância principal diferente.

Para mais informações sobre como mover o local de armazenamento dos registros de transação usados para PITR, consulte Como usar a recuperação pontual (PITR, na sigla em inglês).

Você 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 DR e a sintaxe de comando correta, consulte Designar a réplica de DR para a instância principal.

A seguir