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 Recuperação pontual (PITR, na sigla em inglês):

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 mudar o local de armazenamento dos registros de transação usados para a PITR do disco para o Cloud Storage usando a gcloud CLI ou a API Cloud SQL Admin sem incorrer em inatividade. Para mais informações, consulte Mudar o armazenamento de registros de transações para o Cloud Storage.

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.

Para os registros binários da PITR armazenados no disco, que estão sendo ou que já foram transferidos para o Cloud Storage, o Cloud SQL mantém os registros pelo 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.

    O Cloud SQL não define valores para essas flags quando os registros binários estão armazenados no disco, estão sendo transferidos para o Cloud Storage ou já foram transferidos para o Cloud Storage. Quando os registros são armazenados no disco, 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 ficam armazenados no disco. Não é possível modificar esses valores enquanto o local de armazenamento de registros estiver sendo transferido para o Cloud Storage. Não recomendamos configurar o valor de qualquer uma dessas flags 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 flag expire_logs_days ou binlog_expire_logs_seconds como um valor menor que os dias de retenção dos 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. É possível mudar o local de armazenamento dos registros usados para PITR do disco para o Cloud Storage sem inatividade usando a gcloud CLI ou a API Cloud SQL Admin. 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 espaço de armazenamento no disco, desative a PITR e não reative-a. 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 definir o número de backups para um a mais do que os dias de retenção de registro.

    Por exemplo, se você especificar 7 para o valor do parâmetro transactionLogRetentionDays, defina o número de retainedBackups como 8 para o parâmetro backupRetentionSettings.

Para mais informações sobre a PITR, consulte Recuperação pontual (PITR).

Depois de concluir a mudança do local de armazenamento dos registros de transações para o Cloud Storage, é possível liberar espaço em disco reduzindo os valores das flags expire_logs_days ou binlog_expire_logs_seconds. Para verificar o status da mudança, consulte Verificar o local de armazenamento dos registros de transações usados para a PITR. 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 flags. 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. Para saber como os registros da PITR são armazenados após a troca e como liberar espaço no disco, consulte Registros após a mudança para o Cloud Storage.

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. No campo Dias de registros, 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 Salvar.

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

    Na seção backupConfiguration, binaryLogEnabled: true é exibido quando a mudança é realizada.

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, faça as seguintes substituições:

  • 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, faça as seguintes substituições:

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

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, faça as seguintes substituições:

  • 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, faça as seguintes substituições:

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

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

    Na seção backupConfiguration, binaryLogEnabled: false é exibido quando a mudança é realizada.

REST v1

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

  • 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, faça as seguintes substituições:

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

Também é possível verificar o local de armazenamento dos registros de transações de várias instâncias no mesmo projeto. Para determinar o local de várias instâncias, use o seguinte comando:

   gcloud sql instances list --show-transactional-log-storage-state

Exemplo de resposta:

NAME  DATABASE_VERSION LOCATION       TRANSACTIONAL_LOG_STORAGE_STATE
my_01 MYSQL_8_0        us-central-1     DISK
my_02 MYSQL_8_0        us-central-1     CLOUD_STORAGE
...

Na saída do comando, o campo transactionalLogStorageState ou a coluna TRANSACTIONAL_LOG_STORAGE_STATE fornece informações sobre onde os registros de transações da PITR são armazenados na 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 vai mudar o local de armazenamento dos registros automaticamente 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. Você também pode mudar o local de armazenamento usando a gcloud CLI ou a API Cloud SQL Admin sem fazer upgrade da edição da instância e sem gerar inatividade. Para mais informações, consulte Mudar o armazenamento dos registros de transações para o Cloud Storage.
  • 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.

Mudar o armazenamento dos registros de transações para o Cloud Storage

Se a instância armazenar os registros de transações usados para a PITR no disco, você poderá mudar o local de armazenamento para o Cloud Storage sem gerar inatividade. O processo geral de mudança do local de armazenamento leva aproximadamente o período de retenção do registro de transações (dias) para ser concluído. Assim que você iniciar a mudança, os registros de transações vão começar a ser acumulados no Cloud Storage. Durante a operação, é possível verificar o status do processo geral usando o comando em Verificar o local de armazenamento dos registros de transações usados para a PITR.

Depois que o processo geral de mudança para o Cloud Storage for concluído, o Cloud SQL vai usar registros de transação do Cloud Storage para a PITR.

gcloud

Para mudar o local de armazenamento para o Cloud Storage, use este comando:

   gcloud sql instances patch INSTANCE_NAME \
      --switch-transaction-logs-to-cloud-storage

Substitua INSTANCE_NAME pelo nome da instância. A instância precisa ser principal e não uma réplica. A resposta é semelhante a:

The following message is used for the patch API method.
{"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"}

Patching Cloud SQL instance...done.
Updated
[https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].

Se o comando retornar um erro, consulte Solução de problemas de mudança para o Cloud Storage para saber as próximas etapas.

REST v1

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

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância A instância precisa ser principal e não uma réplica.

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Você receberá uma resposta JSON semelhante a esta:

Se a solicitação retornar um erro, consulte Solução de problemas de mudança para o Cloud Storage para saber as próximas etapas.

REST v1beta4

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

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância A instância precisa ser principal e não uma réplica.

Método HTTP e URL: 

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

Corpo JSON da solicitação:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Você receberá uma resposta JSON semelhante a esta:

Se a solicitação retornar um erro, consulte Solução de problemas de mudança para o Cloud Storage para saber as próximas etapas.

Armazenamento e configuração do registro de transações após a mudança

Depois que o processo de mudança para o Cloud Storage for concluído em uma instância, o Cloud SQL ainda vai manter cópias de registros binários no disco para fins de replicação. Armazenar registros binários no disco pode ser útil quando você quer navegar por registros binários com o utilitário mysqlbinlog.

Se você tiver configurado as flags expire_logs_days ou binlog_expire_logs_seconds na instância antes da mudança, os valores configurados vão permanecer inalterados.

Como os registros binários usados para executar a PITR estão armazenados no Cloud Storage depois da mudança, verifique se os valores das flags refletem a retenção dos registros de transações no disco esperado. O Cloud SQL só mantém registros no disco pelo valor mínimo de um dos seguintes itens:

  • a configuração transactionLogRetentionDays da PITR antes da mudança. O valor padrão dessa configuração é de sete dias.
  • as flags expire_logs_days ou binlog_expire_logs_seconds definidas manualmente na instância.

Se você quiser economizar espaço em disco, depois do processo de mudança, configure o valor das flags expire_logs_days ou binlog_expire_logs_seconds como um dia para reduzir o tamanho do disco alocado e os custos de armazenamento em disco. Para mais informações sobre o armazenamento de registros de transações e a PITR, consulte Armazenamento de registros para a PITR.

Para saber como verificar o uso do disco, consulte Registros e uso do disco.

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

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. Isso é válido apenas 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:

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância

  • DAYS_TO_RETAIN: o número de dias de retenção dos registros de transação. Para o Cloud SQL Enterprise Plus, o intervalo válido é de 1 a 35 dias, com um padrão de 14 dias. Para o Cloud SQL 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. Isso é válido apenas quando a PITR está ativada. A especificação de uma retenção de mais dias dos registros de transações requer um tamanho de armazenamento maior.

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:

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância

  • DAYS_TO_RETAIN: o número de dias de retenção dos registros de transação. Para o Cloud SQL Enterprise Plus, o intervalo válido é de 1 a 35 dias, com um padrão de 14 dias. Para o Cloud SQL 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. Isso é válido apenas quando a PITR está ativada. A especificação de uma retenção de mais dias dos registros de transações requer um tamanho de armazenamento maior.

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, faça as seguintes substituições:

  • 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, faça as seguintes substituições:

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

Resolver problemas com a mudança para o Cloud Storage

A tabela a seguir lista os possíveis erros que podem ser retornados com o código INVALID REQUEST ao mudar o local de armazenamento dos registros de transações do disco para o Cloud Storage.

Problema Solução de problemas
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. Verifique se você está executando o comando da gcloud CLI ou fazendo a solicitação da API em uma instância do Cloud SQL para MySQL ou do Cloud SQL para PostgreSQL. Não é possível mudar o local de armazenamento dos registros de transações usando a gcloud CLI ou a API Cloud SQL Admin no Cloud SQL para SQL Server.
MySQL transactional logging is not enabled on this instance. O MySQL usa o registro binário como os registros de transações para a recuperação pontual (PITR). Para ser compatível com a PITR, o MySQL exige que você ative a geração de registros binários na instância. Para saber como ativar a geração de registros binários, consulte Ativar a PITR.
This command is not supported on replica instances. Run the command on the primary instance instead. Especifique uma instância principal ao executar o comando ou fazer a solicitação da API.
This instance is already storing transaction logs used for PITR in Cloud Storage Para verificar o local de armazenamento dos registros de transações, execute o comando contido em Verificar o local de armazenamento dos registros de transações usados para a PITR.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Aguarde a conclusão da outra operação.

Para verificar o status da operação e o local de armazenamento dos registros de transações, execute o comando contido em Verificar o local de armazenamento dos registros de transações usados para a PITR.

A seguir