Usar recuperação pontual (PITR)

Nesta página, descrevemos como usar a recuperação pontual (PITR, na sigla em inglês) para restaurar a instância principal do Cloud SQL.

Para saber mais sobre a PITR, consulte este link.

Por padrão, a PITR é ativada quando você cria uma instância do Cloud SQL edição Enterprise Plus, independentemente se você criar a instância usando o console do Google Cloud, a gcloud CLI, o Terraform ou a API Cloud SQL Admin.

Se você criar uma instância do Cloud SQL edição Enterprise no console do Google Cloud, a PITR será ativada por padrão. Caso contrário, se você criar a instância usando a gcloud CLI, o Terraform ou a API Cloud SQL Admin, será necessário ativar a PITR manualmente.

Armazenamento de registros para PITR

O Cloud SQL usa registros binários para a PITR.

Em 11 de agosto de 2023, lançamos o armazenamento de registros de transações para a PITR no Cloud Storage. Desde esse lançamento, estas condições são aplicáveis:

  • Todas as instâncias da edição Cloud SQL Enterprise Plus armazenam os registros binários usados para PITR no Cloud Storage. Apenas as instâncias da edição Cloud SQL Enterprise Plus que você fez upgrade do Cloud SQL Enterprise antes de 1o de abril de 2024 e ativou a PITR antes de 11 de agosto de 2023 continuam armazenando os registros da PITR no disco.
  • As instâncias da edição Cloud SQL Enterprise criadas com a PITR ativada antes de 11 de agosto de 2023 continuam armazenando os registros no disco.
  • Se você fizer upgrade de uma instância do Cloud SQL Enterprise após 1o de abril de 2024 que armazena registros de transação para PITR em disco para a edição Cloud SQL Enterprise Plus, o processo de upgrade vai mudar o local de armazenamento dos registros de transações usados para a PITR. para o Cloud Storage. Para mais informações, consulte Fazer upgrade de uma instância para o Cloud SQL Enterprise Plus usando o upgrade no local.
  • Todas as instâncias da edição Cloud SQL Enterprise que você criar com a PITR ativada após 11 de agosto de 2023 armazenam os registros usados para a PITR no Cloud Storage.

Para mais informações sobre como verificar o local de armazenamento dos registros de transações usados para a PITR, consulte Verificar o local de armazenamento dos registros de transação usados para a PITR.

Para instâncias que armazenam registros binários apenas no disco, é possível mover os registros do disco para o Cloud Storage primeiro desativando e depois reativando a PITR.

Período de armazenamento de registros

O Cloud SQL mantém os registros de transação no Cloud Storage até o valor definido na configuração da PITR transactionLogRetentionDays. Essa valor pode variar de 1 a 35 dias para a edição Cloud SQL Enterprise Plus e de 1 a 7 dias para a edição Cloud SQL Enterprise. Se um valor não for definido, o período de armazenamento de registros de transações padrão será de 14 dias para as instâncias da edição Cloud SQL Enterprise Plus e de sete dias para as instâncias da edição Cloud SQL Enterprise. Para mais informações sobre como definir dias de retenção de registro de transações, consulte Definir retenção de registros de transações.

Uma instância armazena os registros binários usados para a PITR no Cloud Storage, mas também mantém um número menor de registros binários no disco para permitir a replicação dos registros no Cloud Storage. Por padrão, quando você cria uma instância com a PITR ativada, ela armazena os registros binários para a PITR no Cloud Storage. O Cloud SQL também define o valor das sinalizações expire_logs_days e binlog_expire_logs_seconds como o equivalente de um dia automaticamente. Isso significa um dia de registros no disco.

Ao reduzir os valores dessas configurações de sinalização, o Cloud SQL ajuda a economizar nos custos de uso do disco. No entanto, se você quiser que os registros adicionais estejam disponíveis no disco, por exemplo, para procurar os registros binários com o utilitário mysqlbinlog, aumente os valores dessas sinalizações. O Cloud SQL mantém os registros no disco durante o mínimo de dias de retenção de registros de transações ou durante o valor definido para as flags.

Em registros binários usados para a PITR armazenados no disco, o Cloud SQL mantém os registros para o valor mínimo definido para uma das seguintes configurações:

  • A configuração de backup de transactionLogRetentionDays.

  • A flag expire_logs_days ou binlog_expire_logs_seconds.

    A modificação dos valores dessas flags pode afetar o comportamento da recuperação PITR e o número de dias em que os registros ficarão armazenados no disco. Não recomendamos configurar o valor de qualquer uma dessas sinalizações como 0. Para mais informações sobre essas flags, consulte Configurar flags do banco de dados.

Para instâncias ativadas por chave de criptografia gerenciada pelo cliente (CMEK, na sigla em inglês), os registros binários são criptografados usando a versão mais recente da CMEK. Para realizar uma restauração, todas as versões da chave que foram as mais recentes para o número de dias que você configurou para o parâmetro retained-transaction-log-days estarão disponíveis.

Registros e uso do disco

Novos registros são gerados regularmente e usam espaço de armazenamento. Os registros binários são excluídos automaticamente com o backup automático associado, o que acontece depois que o valor definido para transactionLogRetentionDays é atingido.

Para descobrir a quantidade do disco que os registros binários estão usando, verifique a métrica bytes_used_by_data_type da instância. O valor do tipo de dados binlog retorna o tamanho dos binlogs no disco. Para instâncias que armazenam registros de transações usados para PITR no disco, o Cloud SQL limpa os dados do disco diariamente para atender à configuração de PITR transactionLogRetentionDays, conforme descrito em Backup automático e retenção de registros de transações. No entanto, se você definir a sinalização expire_logs_days como um valor menor que os dias de retenção de registros de transações, o Cloud SQL poderá limpar os registros binários mais cedo.

Se o tamanho dos registros binários estiver causando um problema para a instância:

  • Verifique se a instância está armazenando registros no disco. Desative e reative a PITR para mover os registros usados para a PITR do disco para o Cloud Storage. Essa operação resulta em alguns minutos de inatividade, mas libera espaço em disco. Se você estiver usando o Cloud SQL Enterprise, também poderá fazer upgrade para o Cloud SQL Enterprise Plus para mudar o local de armazenamento dos registros PITR.

  • É possível aumentar o tamanho do armazenamento da instância, mas o aumento do tamanho do registro binário no uso do disco pode ser temporário.

  • Recomendamos que você ative o aumento automático de armazenamento para evitar problemas de armazenamento inesperados.

  • Se você quiser excluir registros e recuperar o armazenamento, desative a PITR sem reativá-la. No entanto, diminuir o armazenamento usado não reduz o tamanho do disco provisionado para a instância.

  • Os registros são limpados uma vez por dia, e não continuamente. Configurar a retenção de registros para dois dias significa que no mínimo dois dias de registros, e no máximo três, serão mantidos. Recomendamos que você defina o número de backups como sendo maior do que o número de dias de retenção de registros. Dessa forma, é possível garantir um mínimo de dias especificados para a retenção.

Para mais informações sobre a PITR, consulte este link.

Ativar a PITR

Quando você cria uma instância no Console do Google Cloud, as opções Backups automatizados e Ativar a recuperação pontual são ativadas automaticamente.

O procedimento a seguir ativa a PITR em uma instância principal existente.

Console

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

    Acesse "Instâncias do Cloud SQL"

  2. Abra o menu de mais ações Ícone mais ações. da instância em que você quer ativar a PITR e clique em Editar.
  3. Em Personalizar sua instância, expanda a seção Proteção de dados.
  4. Marque a caixa de seleção Ativar recuperação pontual.
  5. Expanda Opções avançadas.
  6. Digite o número de dias em que os registros serão retidos, de 1 a 35 para a edição do Cloud SQL Enterprise Plus ou de 1 a 7 para a edição do Cloud SQL Enterprise.
  7. Clique em Save.

gcloud

  1. Exiba a visão geral da instância: 
    gcloud sql instances describe INSTANCE_NAME
  2. Se você vir enabled: false na seção backupConfiguration, ative os backups programados: 
    gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM

    Especifique o parâmetro backup-start-time usando o horário de 24 horas no fuso horário UTC±00.

  3. Ative a PITR: 
    gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log

    Se você estiver ativando a PITR em uma instância principal, também poderá configurar o número de dias para manter os registros de transações adicionando o seguinte parâmetro:

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
  4. Confirme a mudança: 
    gcloud sql instances describe INSTANCE_NAME

    Quando a operação é realizada, é exibido binaryLogEnabled: true na seção backupConfiguration.

Terraform

Para ativar a PITR, use um recurso do Terraform. 

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Aplique as alterações

Para aplicar a configuração do Terraform em um projeto do Google Cloud, conclua as etapas nas seções a seguir.

Preparar o Cloud Shell

  1. Inicie o Cloud Shell.

  2. Defina o projeto padrão do Google Cloud em que você quer aplicar as configurações do Terraform.

    Você só precisa executar esse comando uma vez por projeto, e ele pode ser executado em qualquer diretório.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    As variáveis de ambiente serão substituídas se você definir valores explícitos no arquivo de configuração do Terraform.

Preparar o diretório

Cada arquivo de configuração do Terraform precisa ter o próprio diretório, também chamado de módulo raiz.

  1. No Cloud Shell, crie um diretório e um novo arquivo dentro dele. O nome do arquivo precisa ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o arquivo é chamado de main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Se você estiver seguindo um tutorial, poderá copiar o exemplo de código em cada seção ou etapa.

    Copie o exemplo de código no main.tf recém-criado.

    Se preferir, copie o código do GitHub. Isso é recomendado quando o snippet do Terraform faz parte de uma solução de ponta a ponta.

  3. Revise e modifique os parâmetros de amostra para aplicar ao seu ambiente.
  4. Salve as alterações.
  5. Inicialize o Terraform. Você só precisa fazer isso uma vez por diretório. 
    terraform init

    Opcionalmente, para usar a versão mais recente do provedor do Google, inclua a opção -upgrade: 

    terraform init -upgrade

Aplique as alterações

  1. Revise a configuração e verifique se os recursos que o Terraform vai criar ou atualizar correspondem às suas expectativas: 
    terraform plan

    Faça as correções necessárias na configuração.

  2. Para aplicar a configuração do Terraform, execute o comando a seguir e digite yes no prompt: 
    terraform apply

    Aguarde até que o Terraform exiba a mensagem "Apply complete!".

  3. Abra seu projeto do Google Cloud para ver os resultados. No console do Google Cloud, navegue até seus recursos na IU para verificar se foram criados ou atualizados pelo Terraform.

Excluir as alterações

Para excluir as mudanças, faça o seguinte:

  1. Para desativar a proteção contra exclusão, no arquivo de configuração do Terraform, defina o argumento deletion_protection como false. 
    deletion_protection =  "false"
  2. Para aplicar a configuração atualizada do Terraform, execute o comando a seguir e digite yes no prompt: 
    terraform apply

  1. Remova os recursos aplicados anteriormente com a configuração do Terraform executando o seguinte comando e inserindo yes no prompt:

    terraform destroy

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
  • INSTANCE_NAME: o nome da instância primária ou de réplica de leitura que você está configurando para alta disponibilidade
  • START_TIME: a hora (em horas e minutos)

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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
  • INSTANCE_NAME: o nome da instância primária ou de réplica de leitura que você está configurando para alta disponibilidade
  • START_TIME: a hora (em horas e minutos)

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

Executar a PITR com um carimbo de data/hora

Usar o carimbo de data/hora é a abordagem recomendada para executar a PITR. O Cloud SQL usa o utilitário mysqlbinlog para restaurar instâncias até um momento específico. Para mais informações sobre o utilitário mysqlbinlog, consulte a documentação de referência do MySQL (em inglês).

Para concluir a tarefa a seguir, você precisa dos seguintes itens:

  • Geração de registros binários e backups ativados para a instância, com registros binários contínuos desde o último backup antes do evento do qual você quer recuperar. Para mais informações, veja o tópico Ativar a geração de registros binários.
  • Um carimbo de data/hora para definir o ponto de recuperação. Os eventos que ocorrem nesse carimbo de data/hora ou após ele não são refletidos na nova instância.

Console

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

    Acesse "Instâncias do Cloud SQL"

  2. Abra o menu "Mais ações" Ícone mais ações. para a instância a ser recuperada e clique em Criar clone.
  3. Na página Criar um clone, é possível atualizar o ID do novo clone.
  4. Selecione Clonar de um momento anterior.
  5. Insira um horário de PITR.
  6. Clique em Criar clone.

gcloud

Criar um clone usando a PITR.

Substitua:

  • SOURCE_INSTANCE_NAME: nome da instância de que você está restaurando;
  • NEW_INSTANCE_NAME: nome do clone;
  • TIMESTAMP: fuso horário UTC para a instância de origem no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST v1

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

  • project-id: o ID do projeto
  • target-instance-id: o ID da instância de destino
  • source-instance-id: o ID da instância de origem
  • restore-timestamp: o momento em que a restauração será interrompida.

Método HTTP e URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Corpo JSON da solicitação:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

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 do projeto
  • target-instance-id: o ID da instância de destino
  • source-instance-id: o ID da instância de origem
  • restore-timestamp: o momento em que a restauração será interrompida.

Método HTTP e URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Corpo JSON da solicitação:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

Desativar PITR

Console

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

    Acesse "Instâncias do Cloud SQL"

  2. Abra o menu "Mais ações" Ícone mais ações. para a instância a ser desativada e selecione Editar.
  3. Em Personalizar sua instância, expanda a seção Proteção de dados.
  4. Desmarque a opção Ativar recuperação pontual.
  5. Clique em Salvar.
  6. Na página Visão geral da instância, em Configuração, a configuração da PITR é listada como desativada.

gcloud

  1. Desative a recuperação pontual: 
    gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log
  2. Confirme a alteração:
    gcloud sql instances describe INSTANCE_NAME

    Quando a operação é realizada, é exibido binaryLogEnabled: false na seção backupConfiguration.

REST v1

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

  • project-id: o ID do projeto
  • instance-id: o ID da instância

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

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 do projeto
  • instance-id: o ID da instância

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

Verificar o local de armazenamento dos registros de transações usados para a PITR

É possível verificar onde sua instância do Cloud SQL está armazenando os registros de transações usados para a PITR.

gcloud

Para determinar se a instância armazena registros para a PITR no disco ou no Cloud Storage, use o seguinte comando:

   gcloud sql instances describe INSTANCE_NAME

Substitua INSTANCE_NAME pelo nome da instância.

Na saída do comando, o campo transactionalLogStorageState mostra informações sobre onde os registros de transações da PITR são armazenados para a instância. Os estados de armazenamento de registros de transações possíveis são estes:

  • DISK: a instância armazena os registros de transação usados para a PITR no disco. Se você fizer upgrade de uma instância do Cloud SQL Enterprise para o Cloud SQL Enterprise Plus, o processo de upgrade também vai mudar o local de armazenamento de registros para o Cloud Storage. Para mais informações, consulte Fazer upgrade de uma instância para o Cloud SQL Enterprise Plus usando o upgrade no local.
  • SWITCHING_TO_CLOUD_STORAGE: a instância está alternando o local de armazenamento dos registros de transação da PITR para o Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: a instância concluiu a mudança do local de armazenamento dos registros de transação PITR do disco para o Cloud Storage.
  • CLOUD_STORAGE: a instância armazena os registros de transações usados para a PITR no Cloud Storage.

Definir a retenção do registro de transações

Para definir o número de dias de retenção de registros binários:

Console

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

    Acesse "Instâncias do Cloud SQL"

  2. Abra o menu "Mais ações" Ícone mais ações. para a instância em que você quer definir o registro das transações e selecione Editar.
  3. Em Personalizar sua instância, expanda a seção Proteção de dados.
  4. Na seção Ativar recuperação pontual, expanda Opções avançadas.
  5. Digite o número de dias em que os registros serão retidos, de 1 a 35 para a edição do Cloud SQL Enterprise Plus ou de 1 a 7 para a edição do Cloud SQL Enterprise.
  6. Clique em Save.

gcloud

Edite a instância para definir o número de dias de retenção dos registros binários.

Substitua:

  • INSTANCE-NAME: o nome da instância em que você quer definir o registro de transações;
  • DAYS-TO-RETAIN: o número de dias de registros de transações a serem mantidos. Para o Cloud SQL edição Enterprise Plus, o intervalo válido é de 1 a 35 dias, com um padrão de 14 dias. Para o Cloud SQL edição Enterprise, o intervalo válido é de um a sete dias, com um padrão de sete dias. Se nenhum valor for especificado, o valor padrão será usado. Só é válido quando a PITR está ativada. A especificação de mais dias de registros de transações requer um tamanho de armazenamento maior. 

  gcloud sql instances patch INSTANCE-NAME \
    --retained-transaction-log-days=DAYS-TO-RETAIN

REST v1

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

  • days-to-retain: o número de dias para armazenar registros de transação, de 1 a 7
  • project-id: o ID do projeto
  • instance-id: o ID da instância

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

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:

  • days-to-retain: o número de dias para armazenar registros de transação, de 1 a 7
  • project-id: o ID do projeto
  • instance-id: o ID da instância

Método HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

Corpo JSON da solicitação:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

Executar a PITR usando posições de registro binárias

Recomendamos que você execute a PITR usando carimbos de data/hora, conforme descrito em Executar a PITR usando um carimbo de data/hora, mas também é possível executá-la fornecendo uma posição de registro binário específica em um arquivo de registro binário.

Para mais informações sobre a PITR usando posições de registros binários, consulte a Referência do MySQL, PITR usando o registro binário.

Antes de começar

Antes de concluir esta tarefa, você precisa ter:

  • Geração de registros binários e backups ativados para a instância, com registros binários contínuos desde o último backup antes do evento do qual você quer realizar a recuperação. Para mais informações, veja o tópico Ativar a geração de registros binários.

  • Os registros binários precisam estar disponíveis no disco para que você possa procurá-los em busca de eventos. Para verificar a duração da retenção dos registros binários no disco, consulte Período de armazenamento dos registros. Não é possível procurar registros binários armazenados no Cloud Storage com o utilitário mysqlbinlog.

  • Um nome de arquivo de registros binários e a posição do evento de que você quer realizar a recuperação. Esse evento e todos os que vieram depois dele não são refletidos na nova instância. Para mais informações, veja Identificar a posição do registro binário.

    Depois de identificar o nome do arquivo e a posição do registro binário, execute a PITR usando posições de eventos de registro binário.

Identificar a posição de recuperação

  1. Use o cliente MySQL para se conectar à instância para que você quer restaurar.

    Para fazer isso, use o Cloud Shell ou a máquina cliente local. Para mais informações, consulte Opções de conexão para aplicativos externos.

  2. Mostre os arquivos de registros binários para a instância:

    SHOW BINARY LOGS;

  3. Exibir os 100 primeiros eventos no arquivo de registros binários mais recente:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;

    É possível ajustar o número de linhas a serem exibidas, mas não mostrar todos os eventos no arquivo até saber o tamanho dele. A exibição de um grande número de eventos pode afetar o desempenho do sistema.

  4. Se o evento que você está procurando não for exibido, use a última posição exibida como ponto de partida para pesquisar o próximo conjunto de eventos:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;

  5. Ao encontrar o evento que marca o momento em que a restauração será interrompida, registre a posição (mostrada como Pos) e o nome do arquivo de registro binário.

    O nome de arquivo e a posição do registro binário são os valores usados para a PITR.

Veja abaixo um exemplo de saída do comando SHOW BINLOG EVENTS:

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

Para restaurar até a instrução DROP TABLE, em negrito acima, seria preciso usar "865" em "mysql-bin.000011" como a posição de recuperação. A instrução DROP TABLE e todas as operações depois dela não são refletidas na nova instância.

Executar a PITR usando posições de eventos de registros binários

gcloud

Use o comando gcloud sql instances clone com as sinalizações --bin-log-file-name e --bin-log-position.

  1. Crie a instância usando o nome de arquivo do registro binário e a posição de recuperação.

    Substitua:

    • SOURCE_INSTANCE_NAME: nome da instância da qual você está restaurando;
    • NEW_INSTANCE_NAME: nome do clone;
    • BINLOG_FILE_NAME: nome do registro binário, como mysql-bin.187288;
    • POSITION: a posição no registro binário em que a restauração será interrompida, como 50001356.
    gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION

    Por exemplo, é possível que um comando gcloud sql instances clone seja parecido com isto: 

    gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
  2. Use o ID de operação retornado pelo comando clone para verificar o status da operação de restauração. 
    gcloud sql operations describe OPERATION_ID

    Quando a operação está em andamento, um estado RUNNING é retornado. Quando a operação é concluída, um estado DONE é retornado.

REST v1

Crie a instância usando o nome do arquivo de registros binários e a posição de recuperação que você identificou:

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

  • project-id: o ID do projeto
  • target-instance-id: o ID da instância de destino
  • source-instance-id: o ID da instância de origem
  • binary-log-file-name: o nome do arquivo de registro binário
  • binary-log-position: a posição no arquivo de registros binários

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Corpo JSON da solicitação:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Crie a nova instância usando o nome do arquivo de registros binários e a posição da recuperação identificada:

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

  • project-id: o ID do projeto
  • target-instance-id: o ID da instância de destino
  • source-instance-id: o ID da instância de origem
  • binary-log-file-name: o nome do arquivo de registro binário
  • binary-log-position: a posição no arquivo de registros binários

Método HTTP e URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Corpo JSON da solicitação:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

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

Você receberá uma resposta JSON semelhante a esta:

Resolver problemas

Problema Solução de problemas

argument --point-in-time: Failed to parse date/time:
Unknown string format: 2021-0928T30:54:03.094;
received: 2021-0928T30:54:03.094Z

OU

Invalid value at 'body.clone_context.point_in_time'
(type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime',
Invalid time format: Failed to parse input,

 O carimbo de data/hora fornecido é inválido.

HTTP Error 400: Successful backup required for carrying out the operation was not found.

OU

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

 O carimbo de data/hora que você forneceu refere-se a um momento em que não foram encontrados backups ou coordenadas binlog.

A seguir