Use a recuperação pontual (PITR)

Esta página descreve como usar a recuperação num determinado momento (PITR) para restaurar a instância principal do Cloud SQL.

Para saber mais acerca da PITR, consulte o artigo Recuperação pontual (PITR).

Se criar uma instância da edição Enterprise Plus do Cloud SQL, a PITR é ativada por predefinição, independentemente do método usado para a criação. Se quiser desativar a funcionalidade, tem de o fazer manualmente.

Se criar uma instância da edição Enterprise do Cloud SQL na Trusted Cloud consola, a PITR é ativada por predefinição. Caso contrário, se criar a instância através da CLI gcloud, do Terraform ou da API Cloud SQL Admin, a PITR está desativada por predefinição. Neste caso, se quiser ativar a funcionalidade, tem de o fazer manualmente.

Armazenamento de registos para PITR

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

A 11 de agosto de 2023, lançámos o armazenamento de registos de transações para PITR no Cloud Storage. Desde este lançamento, aplicam-se as seguintes condições:

  • Todas as instâncias da edição Cloud SQL Enterprise Plus armazenam os respetivos registos binários usados para PITR no Cloud Storage. Apenas as instâncias da edição Cloud SQL Enterprise Plus que atualizou a partir da edição Cloud SQL Enterprise antes de 1 de abril de 2024 e que tinham a PITR ativada antes de 11 de agosto de 2023 continuam a armazenar os respetivos registos para PITR no disco.
  • As instâncias da edição Enterprise do Cloud SQL criadas com a PITR ativada antes de 11 de agosto de 2023 continuam a armazenar os respetivos registos para PITR no disco.

  • Se atualizar uma instância da edição Cloud SQL Enterprise após 1 de abril de 2024 que armazena registos de transações para PITR no disco para a edição Cloud SQL Enterprise Plus, o processo de atualização muda a localização de armazenamento dos registos de transações usados para PITR para o Cloud Storage. Para mais informações, consulte o artigo Atualize uma instância para a edição Cloud SQL Enterprise Plus através da atualização no local.

  • Todas as instâncias da edição Enterprise do Cloud SQL que criar com a PITR ativada após 11 de agosto de 2023 armazenam registos usados para a PITR no Cloud Storage.

Para mais informações sobre como verificar a localização de armazenamento dos registos de transações usados para a PITR, consulte o artigo Verifique a localização de armazenamento dos registos de transações usados para a PITR.

Para instâncias que armazenam registos binários apenas no disco, pode mudar a localização de armazenamento dos registos de transações usados para PITR do disco para o Cloud Storage através da CLI gcloud ou da API Cloud SQL Admin sem incorrer em qualquer tempo de inatividade. Para mais informações, consulte o artigo Mude o armazenamento do registo de transações para o Cloud Storage.

Período de retenção de registos

O Cloud SQL retém os registos de transações no Cloud Storage até ao valor definido na definição de configuração de PITR transactionLogRetentionDays. Este valor pode variar entre 1 e 35 dias para a edição Cloud SQL Enterprise Plus e entre 1 e 7 dias para a edição Cloud SQL Enterprise. Se não for definido um valor para este parâmetro, o período de retenção predefinido dos registos de transações é de 14 dias para instâncias da edição Cloud SQL Enterprise Plus e de 7 dias para instâncias da edição Cloud SQL Enterprise. Para mais informações sobre como definir os dias de retenção do registo de transações, consulte o artigo Defina a retenção do registo de transações.

Embora uma instância armazene os registos binários usados para PITR no Cloud Storage, a instância também mantém um número menor de registos binários duplicados no disco para permitir a replicação dos registos no Cloud Storage. Por predefinição, quando cria uma instância com a PITR ativada, a instância armazena os respetivos registos binários para a PITR no Cloud Storage. O Cloud SQL também define o valor das flags expire_logs_days e binlog_expire_logs_seconds como o equivalente a um dia automaticamente. Isto traduz-se num dia de registos no disco.

Para registos binários de PITR armazenados no disco, que estão a ser comutados para o Cloud Storage ou que já foram comutados para o Cloud Storage, o Cloud SQL retém os registos pelo valor mínimo definido para uma das seguintes configurações:

  • A definição de configuração de cópia de segurança transactionLogRetentionDays
  • A bandeira expire_logs_days ou a bandeira binlog_expire_logs_seconds

O Cloud SQL não define valores para estas flags se os registos binários estiverem armazenados no disco, estiverem a ser comutados para o Cloud Storage ou já tiverem sido comutados para o Cloud Storage. Quando os registos são armazenados no disco, a modificação dos valores destas flags pode afetar o comportamento da recuperação PITR e o número de dias de registos armazenados no disco. Enquanto a localização de armazenamento de registos está a ser alterada para o Cloud Storage, não pode modificar os valores das flags. Também não recomendamos que configure nenhum valor de flag para 0. Para mais informações, consulte o artigo Configure as flags da base de dados.

Para instâncias com a chave de encriptação gerida pelo cliente (CMEK) ativada, os registos binários são encriptados com a versão mais recente da CMEK. Para fazer um restauro, todas as versões da chave que foram as versões mais recentes durante o número de dias que configurou para o parâmetro retained-transaction-log-days têm de estar disponíveis.

Registos e utilização do disco

Os registos são gerados regularmente e usam espaço de armazenamento. Os registos binários são eliminados automaticamente com a respetiva cópia de segurança automática, o que acontece após o valor definido para transactionLogRetentionDays ser atingido.

Para saber a quantidade de espaço em disco que está a ser usado pelos registos binários, verifique a métrica bytes_used_by_data_type para a instância. O valor do tipo de dados binlog devolve o tamanho dos registos binários no disco. Para instâncias que armazenam registos de transações usados para PITR no disco, o Cloud SQL limpa os dados do disco diariamente para cumprir a transactionLogRetentionDays definição de PITR, conforme descrito em Cópia de segurança automática e retenção de registos de transações. No entanto, se definir a flag expire_logs_days ou binlog_expire_logs_seconds para um valor inferior aos dias de retenção do registo de transações, o Cloud SQL pode limpar os registos binários mais cedo.

Se o tamanho dos registos binários estiver a causar um problema na sua instância:

  • Verifique se a sua instância está a armazenar registos no disco. Pode mudar a localização de armazenamento dos registos que o Cloud SQL usa para a PITR do disco para o Cloud Storage sem tempo de inatividade através da CLI gcloud ou da API Cloud SQL Admin. Se estiver a usar a edição Enterprise do Cloud SQL, também pode atualizar para a edição Enterprise Plus do Cloud SQL para alterar a localização de armazenamento dos seus registos de PITR.
  • Pode aumentar o tamanho do armazenamento da instância. No entanto, o aumento do tamanho do registo binário na utilização do disco pode ser temporário.

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

  • Se quiser eliminar registos e recuperar espaço de armazenamento no disco, pode desativar a PITR sem a reativar. No entanto, a diminuição do armazenamento usado não reduz o tamanho do disco aprovisionado para a instância.

  • Os registos são eliminados uma vez por dia e não de forma contínua. A definição da retenção de registos para dois dias significa que são retidos, pelo menos, dois dias de registos e, no máximo, três dias de registos. Recomendamos que defina o número de cópias de segurança como um valor superior ao número de dias de retenção de registos.

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

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

Depois de concluir a mudança da localização de armazenamento dos registos de transações para o Cloud Storage, pode libertar espaço em disco reduzindo os valores das flags expire_logs_days ou binlog_expire_logs_seconds. Para verificar o estado do comutador, consulte o artigo Verifique a localização de armazenamento dos registos de transações usados para PITR. Se quiser que estejam disponíveis registos adicionais no disco, por exemplo, para procurar os registos binários com a utilidade mysqlbinlog, aumente os valores destas flags. O Cloud SQL retém registos binários no disco durante o mínimo dos dias de retenção do registo de transações ou os valores definidos para as flags. Para mais informações sobre como os registos da PITR são armazenados após a mudança e como libertar espaço em disco, consulte o artigo Registos após a mudança para o Cloud Storage.

Ative a PITR

Quando cria uma nova instância na Trusted Cloud consola, as opções Cópias de segurança automáticas e Ativar recuperação num ponto específico no tempo são ativadas automaticamente.

O procedimento seguinte ativa a PITR numa instância principal existente.

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Abra o menu de mais ações Ícone Mais ações. para a instância na qual quer ativar a PITR e clique em Editar.
  3. Em Personalize a sua instância, expanda a secção Proteção de dados.
  4. Selecione a caixa de verificação Ativar recuperação num ponto específico no tempo.
  5. No campo Dias de registos, introduza o número de dias para reter registos, de 1 a 35 para a edição Cloud SQL Enterprise Plus ou de 1 a 7 para a edição Cloud SQL Enterprise.
  6. Clique em Guardar.

gcloud

  1. Apresente a vista geral da instância:
    gcloud sql instances describe INSTANCE_NAME
  2. Se vir enabled: false na secção backupConfiguration, ative as cópias de segurança agendadas:
    gcloud sql instances patch INSTANCE_NAME \
    --backup-start-time=HH:MM

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

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

    Se estiver a ativar a PITR numa instância principal, também pode configurar o número de dias durante os quais quer reter os registos de transações adicionando o seguinte parâmetro:

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

    Na secção backupConfiguration, vê binaryLogEnabled: true se a alteração foi bem-sucedida.

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

Aplique as alterações

Para aplicar a configuração do Terraform num Trusted Cloud projeto, conclua os passos nas secções seguintes.

Prepare o Cloud Shell

  1. Inicie o Cloud Shell.
  2. Defina o Trusted Cloud projeto predefinido onde quer aplicar as suas configurações do Terraform.

    Só tem de executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    As variáveis de ambiente são substituídas se definir valores explícitos no ficheiro de configuração do Terraform.

Prepare o diretório

Cada ficheiro de configuração do Terraform tem de ter o seu próprio diretório (também denominado módulo raiz).

  1. No Cloud Shell, crie um diretório e um novo ficheiro nesse diretório. O nome do ficheiro tem de ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o ficheiro é denominado main.tf.
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. Se estiver a seguir um tutorial, pode copiar o código de exemplo em cada secção ou passo.

    Copie o exemplo de código para o ficheiro main.tf criado recentemente.

    Opcionalmente, copie o código do GitHub. Isto é recomendado quando o fragmento do Terraform faz parte de uma solução completa.

  3. Reveja e modifique os parâmetros de exemplo para aplicar ao seu ambiente.
  4. Guarde as alterações.
  5. Inicialize o Terraform. Só tem de fazer isto uma vez por diretório.
    terraform init

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

    terraform init -upgrade

Aplique as alterações

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

    Faça correções à configuração conforme necessário.

  2. Aplique a configuração do Terraform executando o seguinte comando e introduzindo yes no comando:
    terraform apply

    Aguarde até que o Terraform apresente a mensagem "Apply complete!" (Aplicação concluída!).

  3. Abra o seu Trusted Cloud projeto para ver os resultados. Na Trusted Cloud consola, navegue para os seus recursos na IU para se certificar de que o Terraform os criou ou atualizou.

Eliminar as alterações

Para eliminar as alterações, faça o seguinte:

  1. Para desativar a proteção contra eliminação, no ficheiro de configuração do Terraform, defina o argumento deletion_protection como false.
    deletion_protection =  "false"
  2. Aplique a configuração do Terraform atualizada executando o seguinte comando e introduzindo yes no comando:
    terraform apply
  1. Remova os recursos aplicados anteriormente com a sua configuração do Terraform executando o seguinte comando e introduzindo yes no comando:

    terraform destroy

REST v1

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

  • PROJECT_ID: o ID ou o número do projeto do Trusted Cloud projeto que contém a instância
  • INSTANCE_NAME: o nome da instância principal ou de réplica de leitura que está a configurar 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 do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

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

  • PROJECT_ID: o ID ou o número do projeto do Trusted Cloud projeto que contém a instância
  • INSTANCE_NAME: o nome da instância principal ou de réplica de leitura que está a configurar 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 do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Efetue a PITR numa instância indisponível

Consola

Recomendamos que recupere uma instância que não está disponível para uma zona diferente pelos seguintes motivos:

  • A zona na qual a instância está configurada não está acessível. Esta instância tem um estado FAILED.
  • A instância está a ser alvo de manutenção. Esta instância tem um estado MAINTENANCE.

Para recuperar uma instância indisponível, conclua os seguintes passos:

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

    Aceda a Instâncias do Cloud SQL

  2. Encontre a linha da instância a clonar.
  3. Na coluna Ações, clique no menu Mais ações.
  4. Clique em Criar clone.
  5. Na página Criar um clone, conclua as seguintes ações:
    1. No campo ID da instância, atualize o ID da instância, se necessário.
    2. Clique em Clonar a partir de um ponto anterior no tempo.
    3. No campo Ponto no tempo, selecione uma data e uma hora a partir das quais quer clonar os dados. Esta ação recupera o estado da instância a partir desse momento.
    4. Clique em Criar clone.
  6. Enquanto o clone é inicializado, regressa à página de listagem de instâncias.

gcloud

Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.

gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \
--point-in-time DATE_AND_TIME_STAMP \
--preferred-zone ZONE_NAME \
--preferred-secondary-zone SECONDARY_ZONE_NAME

O utilizador ou a conta de serviço que está a executar o comando gcloud sql instances clone tem de ter a autorização cloudsql.instances.clone. Para mais informações sobre as autorizações necessárias para executar comandos da CLI gcloud, consulte o artigo Autorizações do Cloud SQL.

REST v1

Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.

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

  • PROJECT_ID: o ID do projeto
  • SOURCE_INSTANCE_ID: o ID da instância da origem
  • TARGET_INSTANCE_ID: o ID da instância de destino

Método HTTP e URL:

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

Corpo JSON do pedido:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

O utilizador ou a conta de serviço que está a usar o método da API instances.clone tem de ter a autorização cloudsql.instances.clone. Para mais informações sobre as autorizações necessárias para usar métodos da API, consulte o artigo Autorizações do Cloud SQL.

REST v1beta4

Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.

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

  • PROJECT_ID: o ID do projeto
  • SOURCE_INSTANCE_ID: o ID da instância da origem
  • TARGET_INSTANCE_ID: o ID da instância de destino

Método HTTP e URL:

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

Corpo JSON do pedido:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

O utilizador ou a conta de serviço que está a usar o método da API instances.clone tem de ter a autorização cloudsql.instances.clone. Para mais informações sobre as autorizações necessárias para usar métodos da API, consulte o artigo Autorizações do Cloud SQL.

Se tentar criar um clone de PITR num momento posterior à hora recuperável mais recente, é apresentada a seguinte mensagem de erro:

The timestamp for point-in-time recovery is after the latest recovery time of
Timestamp of latest recovery time. Clone the instance with a time
that's earlier than this recovery time.

Obtenha o tempo de recuperação mais cedo e mais tarde

Para uma instância disponível, pode executar a PITR para qualquer data/hora no período da PITR da instância. O período de PITR começa na hora de recuperação mais antiga e termina na hora de recuperação mais recente. Se a instância estiver indisponível e os registos da instância estiverem armazenados no Cloud Storage, ou se a instância tiver sido eliminada e tiver a retenção de PITR ativada, pode obter a hora de recuperação mais antiga e mais recente, e executar a PITR para qualquer data/hora nesse período. Em todos os casos, pode restaurar a instância para uma zona principal ou secundária diferente fornecendo valores para as zonas preferenciais.

gcloud

Instância indisponível

Para saber a hora mais antiga e mais recente até à qual pode recuperar uma instância do Cloud SQL que não esteja disponível, execute o seguinte comando:

gcloud sql instances get-latest-recovery-time INSTANCE_NAME

Substitua o seguinte:

  • INSTANCE_NAME: o nome da instância para a qual quer encontrar o tempo de recuperação mais recente.

Instância eliminada

Para saber a hora mais antiga e mais recente até à qual pode recuperar uma instância eliminada do Cloud SQL, execute o seguinte comando:

gcloud sql instances get-latest-recovery-time INSTANCE_NAME
--source-instance-deletion-time='SOURCE_INSTANCE_DELETION_TIMESTAMP'

Substitua o seguinte:

  • INSTANCE_NAME: o nome da instância para a qual quer encontrar o tempo de recuperação mais recente.
  • SOURCE_INSTANCE_DELETION_TIMESTAMP: a indicação de tempo UTC para a hora em que a instância de origem foi eliminada, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.

REST v1

Instância indisponível

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

  • PROJECT_ID: o ID do projeto
  • INSTANCE_NAME: o nome da instância para a qual está a consultar o tempo de recuperação mais recente

Método HTTP e URL:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

{
  "kind": "sql#getLatestRecoveryTime",
  "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

Instância eliminada

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

  • PROJECT_ID: o ID do projeto
  • INSTANCE_NAME: o nome da instância de origem para a qual está a consultar o tempo de recuperação mais recente
  • SOURCE_INSTANCE_DELETION_TIME: a hora em que a instância de origem foi eliminada

Método HTTP e URL:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

{
  "kind": "sql#getLatestRecoveryTime",
  "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

REST v1beta4

Instância indisponível

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

  • PROJECT_ID: o ID do projeto
  • INSTANCE_NAME: o nome da instância para a qual está a consultar o tempo de recuperação mais recente

Método HTTP e URL:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

{
  "kind": "sql#getLatestRecoveryTime",
  "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

Instância eliminada

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

  • PROJECT_ID: o ID do projeto
  • INSTANCE_NAME: o nome da instância de origem para a qual está a consultar o tempo de recuperação mais recente
  • SOURCE_INSTANCE_DELETION_TIME: a hora em que a instância de origem foi eliminada

Método HTTP e URL:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

{
  "kind": "sql#getLatestRecoveryTime",
  "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

Faça uma PITR usando uma indicação de tempo

A utilização de uma data/hora é a abordagem recomendada para realizar a PITR. O Cloud SQL usa o utilitário mysqlbinlog para restaurar instâncias até a uma hora específica. Para mais informações sobre a mysqlbinlogutilidade, consulte a documentação de referência do MySQL.

Para concluir a tarefa seguinte, tem de ter o seguinte:

  • Registo binário e cópias de segurança ativados para a instância, com registos binários contínuos desde a última cópia de segurança antes do evento a partir do qual quer recuperar. Para mais informações, consulte o artigo Ative o registo binário.
  • Uma data/hora para definir o ponto de recuperação. Os eventos que ocorrem a partir desta indicação de tempo não se refletem na nova instância.

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Abra o menu de mais ações Ícone Mais ações. para a instância que quer recuperar e clique em Criar clone.
  3. Opcionalmente, na página Criar um clone, atualize o ID do novo clone.
  4. Selecione Clonar a partir de um ponto anterior no tempo.
  5. Introduza uma hora de PITR.
  6. Clique em Criar clone.

gcloud

Crie um clone através da PITR.

Substitua o seguinte:

  • SOURCE_INSTANCE_NAME - Nome da instância a partir da qual está a fazer a restauração.
  • NEW_INSTANCE_NAME: nome do clone.
  • TIMESTAMP: fuso horário UTC da 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 qualquer um dos dados do pedido, 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 ponto no tempo até ao qual restaurar

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

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

  • project-id: o ID 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 ponto no tempo até ao qual restaurar

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Realize a PITR através do cofre de cópias de segurança

Se a sua instância do Cloud SQL estiver ativada para usar cópias de segurança melhoradas, pode fazer uma recuperação num ponto específico no tempo para a sua instância através do cofre de cópias de segurança.

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Abra o menu de mais ações Ícone Mais ações. para a instância que quer recuperar e clique em Criar clone.

  3. Selecione Clonar a partir de um ponto anterior no tempo.

  4. Introduza uma hora de PITR.

  5. Clique em Criar clone.

gcloud

Para fazer uma PITR numa instância a partir do cofre de cópias de segurança, tem de encontrar o data-source da cópia de segurança mais próxima da hora em que quer fazer a PITR. Para encontrar a cópia de segurança, consulte o artigo Liste todas as cópias de segurança no cofre de cópias de segurança de uma instância. Depois de identificar a cópia de segurança, execute o seguinte comando para realizar a PITR:

gcloud sql instances point-in-time-restore DATA_SOURCE
PITR_TIMESTAMP
--project=TARGET_PROJECT

Substitua o seguinte:

  • DATA_SOURCE: o caminho do data-source para a cópia de segurança mais próxima da data/hora da PITR para a qual quer fazer a recuperação.
  • PITR_TIMESTAMP: a data/hora UTC do registo PITR da instância de origem para o qual quer restaurar a instância, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
  • TARGET_PROJECT: o ID do projeto da sua instância do Cloud SQL.

REST v1

REST v1beta4

Execute a PITR numa instância eliminada

Para usar a PITR para restaurar uma instância eliminada, precisa do seguinte:

  • A data/hora da PITR (timestamp) para a qual quer restaurar a sua instância
  • O nome da instância de destino
  • A hora em que a instância da origem foi eliminada (source-instance-deletion-time)

Só pode usar a PITR numa instância eliminada através da CLI gcloud ou da API Cloud SQL. Para mais informações, consulte o artigo Restaure uma instância eliminada através da PITR.

gcloud

Encontre a sua janela PITR

Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.

Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos

O source-instance-deletion-time e o log-retention-days da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo Liste as cópias de segurança retidas.

Restaure com a PITR

Para restaurar a instância eliminada através da PITR, execute o seguinte comando:

gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time='PITR_TIMESTAMP' \
--source-instance-deletion-time=SOURCE_INSTANCE_DELETION_TIMESTAMP

Substitua o seguinte:

  • SOURCE_INSTANCE_NAME: o nome da instância de origem que quer restaurar.
  • NEW_INSTANCE_NAME: o nome da nova instância.
  • PITR_TIMESTAMP: a data/hora UTC do registo PITR da instância de origem para o qual quer restaurar a instância, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
  • SOURCE_INSTANCE_DELETION_TIMESTAMP: a indicação de tempo UTC para a hora em que a instância de origem foi eliminada, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.

REST v1

Encontre a sua janela PITR

Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.

Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos

O source-instance-deletion-time e o log-retention-days da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo Liste as cópias de segurança retidas.

Restaure com a PITR

Antes de usar qualquer um dos dados do pedido, 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 da origem
  • source-instance-deletion-time: a hora de eliminação da instância da origem
  • restore-timestamp o momento específico em que quer restaurar a instância

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

Encontre a sua janela PITR

Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.

Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos

O source-instance-deletion-time e o log-retention-days da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo Liste as cópias de segurança retidas.

Restaure com a PITR

Antes de usar qualquer um dos dados do pedido, 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 da origem
  • source-instance-deletion-time: a hora de eliminação da instância da origem
  • restore-timestamp o momento específico em que quer restaurar a instância

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Desative a PITR

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Abra o menu Mais ações Ícone Mais ações. para a instância que quer desativar e selecione Editar.
  3. Em Personalize a sua instância, expanda a secção Proteção de dados.
  4. Desmarque a opção Ativar recuperação pontual.
  5. Clique em Guardar.

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 secção backupConfiguration, vê binaryLogEnabled: false se a alteração foi bem-sucedida.

REST v1

Antes de usar qualquer um dos dados do pedido, 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 do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

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

  • project-id: o ID 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 do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Verifique a localização de armazenamento dos registos de transações usados para PITR

Pode verificar onde a sua instância do Cloud SQL está a armazenar os registos de transações usados para a PITR.

gcloud

Para determinar se a sua instância armazena registos para 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.

Para várias instâncias no mesmo projeto, também pode verificar a localização de armazenamento dos registos de transações. Para determinar a localização 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 registos de transações para PITR são armazenados para a instância. Os estados de armazenamento possíveis do registo de transações são os seguintes:

  • DISK: a instância armazena os registos de transações usados para PITR no disco. Se atualizar uma instância da edição Cloud SQL Enterprise para a edição Cloud SQL Enterprise Plus, o processo de atualização muda automaticamente a localização do armazenamento de registos para o Cloud Storage. Para mais informações, consulte o artigo Atualize uma instância para a edição Cloud SQL Enterprise Plus através da atualização no local. Também pode optar por mudar a localização do armazenamento através da CLI gcloud ou da API Cloud SQL Admin sem atualizar a edição da sua instância e sem incorrer em tempo de inatividade. Para mais informações, consulte o artigo Mude o armazenamento do registo de transações para o Cloud Storage.
  • SWITCHING_TO_CLOUD_STORAGE: a instância está a mudar a localização de armazenamento dos registos de transações PITR para o Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: a instância concluiu a mudança da localização de armazenamento dos registos de transações PITR do disco para o Cloud Storage.
  • CLOUD_STORAGE: a instância armazena os registos de transações usados para PITR no Cloud Storage.

Mude o armazenamento do registo de transações para o Cloud Storage

Se a sua instância armazenar os respetivos registos de transações usados para PITR no disco, pode mudar a localização de armazenamento para o Cloud Storage sem incorrer em qualquer período de inatividade. O processo geral de mudança da localização de armazenamento demora aproximadamente o período de retenção do registo de transações (dias) a ser concluído. Assim que iniciar a mudança, os registos de transações começam a acumular-se no Cloud Storage. Durante a operação, pode verificar o estado do processo geral através do comando em Verifique a localização de armazenamento dos registos de transações usados para PITR.

Após a conclusão do processo geral de mudança para o Cloud Storage, o Cloud SQL usa registos de transações do Cloud Storage para a PITR.

gcloud

Para mudar a localização do armazenamento para o Cloud Storage, use o seguinte comando:

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

Substitua INSTANCE_NAME pelo nome da instância. A instância tem de ser uma instância principal e não uma instância de réplica. A resposta é semelhante à seguinte:

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 devolver um erro, consulte o artigo Resolva problemas com a mudança para o armazenamento na nuvem para ver possíveis passos seguintes.

REST v1

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

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

Método HTTP e URL:

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

Corpo JSON do pedido:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Se o pedido devolver um erro, consulte o artigo Resolva problemas da mudança para o Google Cloud Storage para possíveis passos seguintes.

REST v1beta4

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

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

Método HTTP e URL:

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

Corpo JSON do pedido:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Se o pedido devolver um erro, consulte o artigo Resolva problemas da mudança para o Google Cloud Storage para possíveis passos seguintes.

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

Para fins de replicação, o Cloud SQL continua a reter cópias dos registos binários no disco.

Se quiser procurar registos binários com o utilitário mysqlbinlog, é útil armazenar registos binários no disco.

Se configurou as flags expire_logs_days ou binlog_expire_logs_seconds na sua instância antes da mudança, os valores configurados permanecem intactos.

Após a mudança, uma vez que os registos binários usados para executar a PITR são agora armazenados no Cloud Storage, certifique-se de que os valores das flags refletem a retenção dos registos de transações no disco que espera. O Cloud SQL só retém registos no disco durante o valor mínimo de um dos seguintes:

  • a definição de configuração da transactionLogRetentionDaysPITR antes da mudança. O valor predefinido para esta definição é de 7 dias.
  • As flags expire_logs_days ou binlog_expire_logs_seconds que definiu manualmente na sua instância.

Se quiser poupar espaço em disco, após a conclusão do processo de mudança, configure o valor das flags expire_logs_days ou binlog_expire_logs_seconds para 1 dia para reduzir o tamanho do disco alocado e os custos de armazenamento em disco. Para mais informações sobre o armazenamento de registos de transações e a PITR, consulte o artigo Armazenamento de registos para PITR.

Para mais informações sobre como verificar a utilização do disco, consulte o artigo Registos e utilização do disco.

Defina a retenção do registo de transações

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

Consola

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

    Aceda a Instâncias do Cloud SQL

  2. Abra o menu Mais ações Ícone Mais ações. para a instância na qual quer ativar o registo de transações e selecione Editar.
  3. Em Personalize a sua instância, expanda a secção Proteção de dados.
  4. Na secção Ativar recuperação num ponto específico no tempo, expanda as Opções avançadas.
  5. Introduza o número de dias para reter registos, de 1 a 35 para a edição Cloud SQL Enterprise Plus ou de 1 a 7 para a edição Cloud SQL Enterprise.
  6. Clique em Guardar.

gcloud

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

Substitua o seguinte:

  • INSTANCE_NAME: o nome da instância na qual quer definir o registo de transações.
  • DAYS_TO_RETAIN: o número de dias dos registos de transações a manter. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.

    Se não especificar um valor, o Cloud SQL usa o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos 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 qualquer um dos dados do pedido, faça as seguintes substituições:

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância.
  • DAYS_TO_RETAIN: o número de dias para reter os registos de transações. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.

    Se não for especificado nenhum valor, é usado o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos 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 do pedido:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "DAYS_TO_RETAIN"
    }
  }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

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

  • PROJECT_ID: o ID do projeto.
  • INSTANCE_ID: o ID da instância.
  • DAYS_TO_RETAIN: o número de dias para reter os registos de transações. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.

    Se não for especificado nenhum valor, é usado o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos 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 do pedido:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "DAYS_TO_RETAIN"
    }
  }
}

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

Deve receber uma resposta JSON semelhante à seguinte:

Execute a PITR através de posições de registo binário

Embora recomendemos que execute a PITR através de indicações de tempo, conforme descrito em Execute a PITR através de uma indicação de tempo, também pode executar a PITR fornecendo uma posição específica do registo binário ou uma posição do evento num ficheiro de registo binário.

Para mais informações sobre a PITR com posições do registo binário, consulte o artigo PITR com o registo binário.

Antes de começar

Antes de concluir esta tarefa, tem de ter:

  • O registo binário e as cópias de segurança estão ativados para a instância, com registos binários contínuos desde a última cópia de segurança antes do evento do qual quer recuperar. Para mais informações, consulte o artigo Ative o registo binário.

  • Os registos binários têm de estar disponíveis no disco para que possa procurar eventos nos mesmos. Para verificar o período de retenção dos registos binários no disco, consulte o artigo Período de retenção de registos. Não pode procurar registos binários armazenados no Cloud Storage com a utilidade mysqlbinlog.

  • Um nome de ficheiro de registo binário e a posição do evento a partir do qual quer recuperar (esse evento e todos os eventos que ocorreram depois não são refletidos na nova instância). Para mais informações, consulte o artigo Identifique a posição do registo binário.

    Depois de identificar o nome do ficheiro e a posição do registo binário, execute a PITR com posições de eventos de registo binário.

Identifique a posição de recuperação

  1. Use o cliente MySQL para estabelecer ligação à instância para a qual quer fazer o restauro.

    Para o fazer, use o Cloud Shell ou a sua máquina cliente local. Para mais informações, consulte o artigo Opções de ligação para aplicações externas.

  2. Mostrar os ficheiros de registo binários da instância:

    SHOW BINARY LOGS;
    
  3. Apresentar os primeiros 100 eventos no ficheiro de registo binário mais recente:

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

    Pode ajustar o número de linhas a apresentar, mas não apresentar todos os eventos no ficheiro até saber o tamanho do ficheiro. A apresentação de um grande número de eventos pode afetar o desempenho do sistema.

  4. Se o evento que procura não for apresentado, use a última posição apresentada como ponto de partida para pesquisar o conjunto seguinte de eventos:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
    
  5. Quando encontrar o evento que marca o ponto no tempo até ao qual quer restaurar, registe a posição (apresentada como Pos) e o nome do ficheiro de registo binário.

    O nome do ficheiro de registo binário e a posição são os valores que usa para o PITR.

Segue-se 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é à declaração DROP TABLE, apresentada a negrito no exemplo anterior, usaria 865 em mysql-bin.000011 como posição de recuperação. A declaração DROP TABLE e todas as operações posteriores não são refletidas na nova instância.

Realize a PITR com posições de eventos de registo binário

gcloud

Use o comando gcloud sql instances clone com as flags --bin-log-file-name e --bin-log-position.

  1. Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação.

    Substitua o seguinte:

    • SOURCE_INSTANCE_NAME: nome da instância a partir da qual está a fazer a restauração.
    • NEW_INSTANCE_NAME: nome do clone.
    • BINLOG_FILE_NAME: nome do registo binário, como mysql-bin.187288.
    • POSITION: a posição no registo binário a restaurar até, 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, um comando gcloud sql instances clone pode ter um aspeto semelhante ao seguinte:

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

    Quando a operação está em curso, é devolvido um estado de RUNNING. Quando a operação estiver concluída, é devolvido um estado de DONE.

REST v1

Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação que identificou:

Antes de usar qualquer um dos dados do pedido, 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 ficheiro de registo binário
  • binary-log-position A posição no ficheiro de registo binário

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação que identificou:

Antes de usar qualquer um dos dados do pedido, 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 ficheiro de registo binário
  • binary-log-position A posição no ficheiro de registo binário

Método HTTP e URL:

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

Corpo JSON do pedido:

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

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

Deve receber uma resposta JSON semelhante à seguinte:

Resolver problemas

Problema Resoluçã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,

A data/hora que indicou é inválida.

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.

A data/hora que indicou corresponde a um momento em que não foi possível encontrar cópias de segurança nem coordenadas binlog.

Resolva problemas na mudança para o Cloud Storage

A tabela seguinte apresenta os possíveis erros que podem ser devolvidos com o código INVALID REQUEST quando muda a localização de armazenamento dos registos de transações do disco para o armazenamento na nuvem.

Problema Resolução de problemas
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. Certifique-se de que está a executar o comando da CLI gcloud ou a fazer o pedido de API numa instância do Cloud SQL para MySQL ou Cloud SQL para PostgreSQL. A mudança da localização de armazenamento dos registos de transações através da CLI gcloud ou da API Cloud SQL Admin não é suportada para o Cloud SQL para SQL Server.
MySQL transactional logging is not enabled on this instance. O MySQL usa o registo binário como os registos de transações para a recuperação num determinado momento (PITR). Para suportar a PITR, o MySQL requer que ative o registo binário na instância. Para mais informações sobre como ativar o registo binário, consulte Ative a PITR.
This command is not supported on replica instances. Run the command on the primary instance instead. Certifique-se de que especifica uma instância principal quando executar o comando ou fizer o pedido da API.
This instance is already storing transaction logs used for PITR in Cloud Storage Para validar a localização de armazenamento dos registos de transações, execute o comando em Verifique a localização de armazenamento dos registos de transações usados para PITR.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Aguarde pela conclusão da operação de mudança.

Para verificar o estado da operação e a localização de armazenamento dos registos de transações, execute o comando em Verifique a localização de armazenamento dos registos de transações usados para PITR.

O que se segue?