使用时间点恢复 (PITR)

本页面介绍了如何使用时间点恢复 (PITR) 来恢复 Cloud SQL 主实例。

如需详细了解 PITR, 请参阅时间点恢复 (PITR)。

默认情况下，在您创建 Cloud SQL 企业 Plus 版实例时，系统会启用 PITR，无论您使用 Google Cloud 控制台、gcloud CLI、Terraform 还是 Cloud SQL Admin API。

如果您在 Google Cloud 控制台中创建 Cloud SQL 企业版实例，则 PITR 在默认情况下处于启用状态。否则，如果您使用 gcloud CLI、Terraform 或 Cloud SQL Admin API 创建实例，则必须手动启用 PITR。

用于 PITR 的日志存储

Cloud SQL 对 PITR 使用二进制日志。

我们于 2023 年 8 月 11 日发布了在 Cloud Storage 中存储 PITR 事务日志的功能。自从此功能发布以来，以下条件适用：

  • 所有 Cloud SQL 企业 Plus 版实例都会将其用于 PITR 的二进制日志存储在 Cloud Storage 中。只有您在 2024 年 4 月 1 日之前从 Cloud SQL 企业版升级并在 2023 年 8 月 11 日之前启用 PITR 的 Cloud SQL 企业 Plus 版实例才会继续将 PITR 日志存储在磁盘上。

  • 您所创建并在 2023 年 8 月 11 日之前启用了 PITR 的 Cloud SQL 企业版实例会继续将其 PITR 日志存储在磁盘上。

  • 如果您在 2024 年 4 月 1 日之后将在磁盘上存储 PITR 事务日志的 Cloud SQL 企业版实例升级为 Cloud SQL 企业 Plus 版，则升级过程会将用于 PITR 的事务日志的存储位置切换为 Cloud Storage。如需了解详情，请参阅使用就地升级将实例升级到 Cloud SQL 企业 Plus 版。

  • 您所创建并在 2023 年 8 月 11 日之后启用了 PITR 的所有 Cloud SQL 企业版实例都会将用于 PITR 的日志存储在 Cloud Storage 中。

如需详细了解如何检查用于 PITR 的事务日志的存储位置，请参阅检查用于 PITR 的事务日志的存储位置。

对于仅在磁盘上存储二进制日志的实例，您可以使用 gcloud CLI 或 Cloud SQL Admin API 将用于 PITR 的事务日志的存储位置从磁盘切换到 Cloud Storage，而不会造成任何停机时间。如需了解详情，请参阅将交易日志存储切换到 Cloud Storage。

日志保留期限

Cloud SQL 在 Cloud Storage 中保留事务日志的时间会遵循 transactionLogRetentionDays PITR 配置设置中设置的值。此值对于 Cloud SQL 企业 Plus 版可以为 1 到 35 天，对于 Cloud SQL 企业版为 1 到 7 天。如果未设置此参数的值，则 Cloud SQL 企业 Plus 版实例的默认事务日志保留期限为 14 天，而 Cloud SQL 企业版实例的默认事务日志保留期限为 7 天。如需详细了解如何设置事务日志保留天数，请参阅设置事务日志保留。

虽然实例会将用于 PITR 的二进制日志存储在 Cloud Storage 中，但实例也会在磁盘上保留较少的重复二进制日志，以便可以将日志复制到 Cloud Storage。默认情况下，当您创建启用了 PITR 的实例时，该实例会将其 PITR 的二进制日志存储在 Cloud Storage 中。Cloud SQL 还会自动将 expire_logs_days 和 binlog_expire_logs_seconds 标志的值设置为一天。这相当于磁盘上一天的日志。

对于存储在磁盘上、正在切换到 Cloud Storage 或已切换到 Cloud Storage 的 PITR 二进制日志，Cloud SQL 会保留为以下配置之一设置的最小值的日志：

  • transactionLogRetentionDays 备份配置设置

  • expire_logs_days 或 binlog_expire_logs_seconds 标志

    如果二进制日志存储在磁盘上、正在切换到 Cloud Storage 或已切换到 Cloud Storage，Cloud SQL 不会为这些标志设置任何值。当日志存储在磁盘上时，修改这些标志的值可能会影响 PITR 恢复的行为以及在磁盘上存储多少天的日志。在日志存储位置切换为 Cloud Storage 期间，您无法修改这些值。我们不建议您将上述任一标志的值配置为 0。如需详细了解这些标志，请参阅配置数据库标志。

对于启用了客户管理的加密密钥 (CMEK) 的实例，系统会使用最新版本的 CMEK 加密二进制日志。如需执行恢复操作，必须提供所有在为 retained-transaction-log-days 参数配置的天数内保持最新的密钥。

日志和磁盘使用量

日志会定期生成，并且会占用一定的存储空间。二进制日志会连同其关联的自动备份自动删除，删除操作会在满足为 transactionLogRetentionDays 设置的值后进行。

如需了解二进制日志使用了多少磁盘，请检查实例的 bytes_used_by_data_type 指标。binlog 数据类型的值会返回磁盘上二进制日志的大小。对于在磁盘上存储用于 PITR 的事务日志的实例，Cloud SQL 每天都会从磁盘中完全清除数据，以满足 transactionLogRetentionDays PITR 设置，如自动备份和事务日志保留中所述。但是，如果您将 expire_logs_days 或 binlog_expire_logs_seconds 标志设置为低于事务日志保留天数的值，则 Cloud SQL 可以更快地完全清除二进制文件。

如果二进制日志的大小导致实例出现问题：

  • 检查实例是否将日志存储在磁盘上。您可以使用 gcloud CLI 或 Cloud SQL Admin API，将用于 PITR 的日志的存储位置从磁盘切换到 Cloud Storage，而不会造成停机。如果您使用的是 Cloud SQL 企业版，则还可以升级到 Cloud SQL 企业 Plus 版以切换 PITR 日志的存储位置。

  • 您可以增加实例存储空间大小，但磁盘用量中的二进制日志大小的增加可能是临时的。

  • 我们建议启用存储空间自动扩容功能，以避免意外的存储问题。

  • 如果要删除日志并恢复磁盘上的存储空间，您可以停用 PITR，而不重新启用它。但是，减小所占用的存储空间不会缩小为实例预配的磁盘大小。

  • 日志每天完全清除一次，不会持续清除。将日志保留设置为两天意味着系统会保留至少两天、最多三天的日志。我们建议将备份数量设置为日志保留天数加 1。

    例如，如果您为 transactionLogRetentionDays 参数的值指定 7，则对于 backupRetentionSettings 参数，请将 retainedBackups 的数量设置为 8。

如需详细了解 PITR，请参阅时间点恢复 (PITR)。

完成将事务日志的存储位置切换到 Cloud Storage 后，您可以通过缩减 expire_logs_days 或 binlog_expire_logs_seconds 标志的值来释放磁盘空间。如需检查切换状态，请参阅检查用于 PITR 的事务日志的存储位置。但是，如果您希望磁盘上提供更多日志（例如以便能够使用 mysqlbinlog 实用程序浏览二进制日志），请增加这些标志的值。Cloud SQL 会按照事务日志保留天数或为标志设置的值中的较小值来保留磁盘上的二进制日志。 如需详细了解 PITR 日志在切换后如何存储以及如何释放磁盘空间，请参阅切换到 Cloud Storage 后日志的存储方式。

启用 PITR

当您在 Google Cloud 控制台中创建新实例时，自动备份和启用时间点恢复都会自动启用。

以下过程会在现有主实例上启用 PITR。

控制台

  1. 在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 打开要启用 PITR 的实例对应的“更多操作”菜单 “更多操作”图标。，然后点击修改。
  3. 在自定义实例下，展开数据保护部分。
  4. 选中启用时间点恢复复选框。
  5. 在日志保留天数字段中，输入保留日志的天数（对于 Cloud SQL 企业 Plus 版为 1-35，对于 Cloud SQL 企业版为 1-7）。
  6. 点击保存。

gcloud

  1. 显示实例概览：
    gcloud sql instances describe INSTANCE_NAME
  2. 如果您在 backupConfiguration 部分中看到 enabled: false，请启用计划备份：
    gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM

    使用 UTC±00 时区的 24 小时制时间指定 backup-start-time 参数。

  3. 启用 PITR： 
    gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log

    如果您要在主实例上启用 PITR，还可以通过添加以下参数来配置要保留事务日志的天数：

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
  4. 确认更改： 
    gcloud sql instances describe INSTANCE_NAME

    在 backupConfiguration 部分，如果更改成功，您会看到 binaryLogEnabled: true。

Terraform

如需启用 PITR，请使用 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
}

应用更改

如需在 Google Cloud 项目中应用 Terraform 配置，请完成以下部分中的步骤。

准备 Cloud Shell

  1. 启动 Cloud Shell。

  2. 设置要在其中应用 Terraform 配置的默认 Google Cloud 项目。

    您只需为每个项目运行一次以下命令，即可在任何目录中运行它。

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    如果您在 Terraform 配置文件中设置显式值，则环境变量会被替换。

准备目录

每个 Terraform 配置文件都必须有自己的目录（也称为“根模块”）。

  1. 在 Cloud Shell 中，创建一个目录，并在该目录中创建一个新文件。文件名必须具有 .tf 扩展名，例如 main.tf。在本教程中，该文件称为 main.tf。
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. 如果您按照教程进行操作，可以在每个部分或步骤中复制示例代码。

    将示例代码复制到新创建的 main.tf 中。

    （可选）从 GitHub 中复制代码。如果端到端解决方案包含 Terraform 代码段，则建议这样做。

  3. 查看和修改要应用到您的环境的示例参数。
  4. 保存更改。
  5. 初始化 Terraform。您只需为每个目录执行一次此操作。 
    terraform init

    （可选）如需使用最新的 Google 提供程序版本，请添加 -upgrade 选项： 

    terraform init -upgrade

应用更改

  1. 查看配置并验证 Terraform 将创建或更新的资源是否符合您的预期：
    terraform plan

    根据需要更正配置。

  2. 通过运行以下命令并在提示符处输入 yes 来应用 Terraform 配置：
    terraform apply

    等待 Terraform 显示“应用完成！”消息。

  3. 打开您的 Google Cloud 项目以查看结果。在 Google Cloud 控制台的界面中找到资源，以确保 Terraform 已创建或更新它们。

删除更改

如需删除更改，请执行以下操作：

  1. 如需停用删除防护，请在 Terraform 配置文件中将 deletion_protection 参数设置为 false。
    deletion_protection =  "false"
  2. 运行以下命令并在提示符处输入 yes，以应用更新后的 Terraform 配置：
    terraform apply

  1. 运行以下命令并在提示符处输入 yes，以移除之前使用 Terraform 配置应用的资源：

    terraform destroy

REST v1

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：包含实例的 Google Cloud 项目的 ID 或项目编号
  • INSTANCE_NAME：您为实现高可用性而配置的主实例或读取副本实例的名称
  • START_TIME：时间（以小时和分钟为单位）

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

REST v1beta4

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：包含实例的 Google Cloud 项目的 ID 或项目编号
  • INSTANCE_NAME：您为实现高可用性而配置的主实例或读取副本实例的名称
  • START_TIME：时间（以小时和分钟为单位）

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

使用时间戳执行 PITR

使用时间戳是执行 PITR 的推荐方法。Cloud SQL 使用 mysqlbinlog 实用程序将实例恢复到特定时间。如需详细了解 mysqlbinlog 实用程序，请参阅 MySQL 参考文档。

如需完成后续任务，您必须拥有以下各项：

  • 为实例启用二进制日志记录和备份，其中包含自您要从其恢复的事件之前的最后一次备份以来的连续二进制日志。如需了解详情，请参阅启用二进制日志记录。
  • 用于定义恢复点的时间戳。在此时间戳所表示的时间发生的事件和之后发生的事件不会反映在新实例中。

控制台

  1. 在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 打开要恢复的实例对应的“更多操作”菜单 “更多操作”图标。，然后点击创建克隆。
  3. （可选）在创建克隆页面上，更新新克隆的 ID。
  4. 选择从较早的时间点克隆。
  5. 输入 PITR 时间。
  6. 点击创建克隆。

gcloud

使用 PITR 创建克隆。

替换以下内容：

  • SOURCE_INSTANCE_NAME - 您要从中恢复的实例的名称。
  • NEW_INSTANCE_NAME - 克隆的名称。
  • TIMESTAMP - 源实例的 UTC 时区（采用 RFC 3339 格式）。例如 2012-11-15T16:19:00.094Z。
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST v1

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • target-instance-id：目标实例 ID
  • source-instance-id：源实例 ID
  • restore-timestamp：在恢复之前所处的时间点

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

REST v1beta4

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • target-instance-id：目标实例 ID
  • source-instance-id：源实例 ID
  • restore-timestamp：在恢复之前所处的时间点

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

停用 PITR

控制台

  1. 在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 打开要停用的实例对应的“更多操作”菜单 “更多操作”图标。，然后选择修改。
  3. 在自定义实例下，展开数据保护部分。
  4. 清除启用时间点恢复。
  5. 点击保存。

gcloud

  1. 停用时间点恢复： 
    gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log
  2. 确认更改：
    gcloud sql instances describe INSTANCE_NAME

    在 backupConfiguration 部分，如果更改成功，您会看到 binaryLogEnabled: false。

REST v1

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • instance-id：实例 ID

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

REST v1beta4

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • instance-id：实例 ID

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

检查用于 PITR 的事务日志的存储位置

您可以检查 Cloud SQL 实例存储用于 PITR 的事务日志的位置。

gcloud

如需确定您的实例是将 PITR 的日志存储在磁盘还是 Cloud Storage 上，请使用以下命令：

   gcloud sql instances describe INSTANCE_NAME

将 INSTANCE_NAME 替换为实例名称。

您还可以查看同一项目中多个实例的交易日志的存储位置。 如需确定多个实例的位置，请使用以下命令：

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

示例响应：

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

在命令的输出中，transactionalLogStorageState 字段或 TRANSACTIONAL_LOG_STORAGE_STATE 列提供有关为实例存储 PITR 事务日志的位置的信息。 可能的事务日志存储状态如下：

  • DISK：实例将用于 PITR 的事务日志存储在磁盘上。 如果您将 Cloud SQL 企业版实例升级到 Cloud SQL 企业 Plus 版，则升级过程会自动将日志存储位置切换到 Cloud Storage。如需了解详情，请参阅使用就地升级将实例升级到 Cloud SQL 企业 Plus 版。 您还可以选择使用 gcloud CLI 或 Cloud SQL Admin API 切换存储位置，而无需升级实例的版本，也不会造成任何停机。如需了解详情，请参阅将交易日志存储切换到 Cloud Storage。
  • SWITCHING_TO_CLOUD_STORAGE：实例正在将 PITR 事务日志的存储位置切换到 Cloud Storage。
  • SWITCHED_TO_CLOUD_STORAGE：实例已完成将 PITR 事务日志的存储位置从磁盘切换到 Cloud Storage 的操作。
  • CLOUD_STORAGE：实例将用于 PITR 的事务日志存储在 Cloud Storage 中。

将事务日志存储空间切换到 Cloud Storage

如果您的实例将用于 PITR 的事务日志存储在磁盘上，则您可以将存储位置切换到 Cloud Storage，而不会造成任何停机时间。切换存储位置的整个过程大约需要事务日志保留期限（天）的时间才能完成。您开始切换后，事务日志就会开始在 Cloud Storage 中累积。在操作期间，您可以使用检查用于 PITR 的事务日志的存储位置中的命令检查整个过程的状态。

切换到 Cloud Storage 的整个过程完成后，Cloud SQL 会使用 Cloud Storage 中用于 PITR 的事务日志。

gcloud

如需将存储位置切换到 Cloud Storage，请使用以下命令：

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

将 INSTANCE_NAME 替换为实例名称。 该实例必须是主实例，而不是副本实例。 响应类似于以下示例：

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

如果该命令返回错误，请参阅排查改用 Cloud Storage 时出现的问题，了解可能的后续步骤。

REST v1

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：项目 ID。
  • INSTANCE_ID：实例 ID。 该实例必须是主实例，而不是副本实例。

HTTP 方法和网址：

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

请求 JSON 正文：

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

如果请求返回错误，请参阅排查向 Cloud Storage 切换的问题，了解可能的后续步骤。

REST v1beta4

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：项目 ID。
  • INSTANCE_ID：实例 ID。 该实例必须是主实例，而不是副本实例。

HTTP 方法和网址：

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

请求 JSON 正文：

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

如果请求返回错误，请参阅排查向 Cloud Storage 切换的问题，了解可能的后续步骤。

切换后的事务日志存储空间和配置

实例完成切换到 Cloud Storage 后，Cloud SQL 仍会在磁盘上保留二进制日志的副本，以便复制。如果要使用 mysqlbinlog 实用程序浏览二进制日志，将二进制日志存储在磁盘上会非常有用。

如果您在切换之前在实例上配置了 expire_logs_days 或 binlog_expire_logs_seconds 标志，则配置的值将保持不变。

切换后，由于用于执行 PITR 的二进制日志现在存储在 Cloud Storage 中，因此请确保标志的值反映了您预期的磁盘上事务日志的保留情况。Cloud SQL 仅按照以下最小值之一在磁盘上保留日志：

  • 切换前的 transactionLogRetentionDays PITR 配置设置。此设置的默认值为 7 天。
  • 您在实例上手动设置的 expire_logs_days 或 binlog_expire_logs_seconds 标志。

如果要节省磁盘可用空间，则在切换流程完成后，将 expire_logs_days 或 binlog_expire_logs_seconds 标志的值配置为 1 天，以减小分配的磁盘大小和磁盘存储费用。如需详细了解事务日志存储和 PITR，请参阅 PITR 的日志存储。

如需详细了解如何查看磁盘用量，请参阅日志和磁盘用量。

设置事务日志保留

如需设置保留二进制日志的天数：

控制台

  1. 在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 打开要为其设置事务日志的实例对应的“更多操作”菜单 “更多操作”图标。，然后选择修改。
  3. 在自定义实例下，展开数据保护部分。
  4. 在启用时间点恢复部分中，展开高级选项。
  5. 输入保留日志的天数（对于 Cloud SQL 企业 Plus 版为 1-35，对于 Cloud SQL 企业版为 1-7）。
  6. 点击保存。

gcloud

修改实例以设置二进制日志的保留天数。

替换以下内容：

  • INSTANCE_NAME：要为其设置事务日志的实例的名称。

  • DAYS_TO_RETAIN：要保留的事务日志的天数。对于 Cloud SQL 企业 Plus 版，有效范围介于 1 到 35 天之间，默认值为 14 天。对于 Cloud SQL 企业版，有效范围介于 1 到 7 天之间，默认值为 7 天。

    如果未指定任何值，则使用默认值。仅在启用 PITR 时有效。 保留更多天数的事务日志需要更大的存储空间。 

  gcloud sql instances patch INSTANCE_NAME \
    --retained-transaction-log-days=DAYS_TO_RETAIN

REST v1

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：项目 ID。
  • INSTANCE_ID：实例 ID。

  • DAYS_TO_RETAIN：要保留事务日志的天数。对于 Cloud SQL 企业 Plus 版，有效范围介于 1 到 35 天之间，默认值为 14 天。对于 Cloud SQL 企业版，有效范围介于 1 到 7 天之间，默认值为 7 天。

    如果未指定任何值，则使用默认值。仅在启用 PITR 时有效。保留更多天数的事务日志需要更大的存储空间。

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

REST v1beta4

在使用任何请求数据之前，请先进行以下替换：

  • PROJECT_ID：项目 ID。
  • INSTANCE_ID：实例 ID。

  • DAYS_TO_RETAIN：要保留事务日志的天数。对于 Cloud SQL 企业 Plus 版，有效范围介于 1 到 35 天之间，默认值为 14 天。对于 Cloud SQL 企业版，有效范围介于 1 到 7 天之间，默认值为 7 天。

    如果未指定任何值，则使用默认值。仅在启用 PITR 时有效。保留更多天数的事务日志需要更大的存储空间。

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

使用二进制日志时间点执行 PITR

虽然我们建议您按照使用时间戳执行 PITR 中的说明使用时间戳执行 PITR，但您也可以通过在二进制日志文件中提供特定的二进制日志时间点来执行 PITR。

如需详细了解如何使用二进制日志位置进行 PITR，请参阅 MySQL 参考文档中的使用二进制日志进行 PITR。

准备工作

完成此任务之前，必须获得以下信息：

  • 为实例启用二进制日志记录和备份，其中包含自您要从其恢复的事件之前的最后一次备份以来的连续二进制日志。 如需了解详情，请参阅启用二进制日志记录。

  • 磁盘上必须有二进制日志，您才能浏览其中的事件。如需检查磁盘上二进制日志的保留时长，请参阅日志保留期限。 您无法使用 mysqlbinlog 实用程序浏览存储在 Cloud Storage 中的二进制日志。

  • 二进制日志文件名和要恢复的事件时间点（该事件和它之后的所有事件都不会反映在新实例中）。如需了解详情，请参阅标识二进制日志时间点。

    标识二进制日志文件名和时间点后，使用二进制日志事件时间点执行 PITR。

标识恢复时间点

  1. 使用 MySQL 客户端连接到要恢复的实例。

    如需执行此操作，请使用 Cloud Shell 或本地客户端机器。 如需了解详情，请参阅外部应用连接方案。

  2. 显示实例的二进制日志文件：

    SHOW BINARY LOGS;

  3. 显示最近二进制日志文件中的前 100 个事件：

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

    您可以调整要显示的行数，但如果不清楚文件的大小，不要显示文件中的所有事件。显示大量事件会影响系统的性能。

  4. 如果您正在查找的事件没有显示，请使用显示的最后一个时间点作为起点来搜索下一组事件：

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

  5. 当您找到标记要恢复到的时间点的事件时，请记录该位置（显示为 Pos）和二进制日志文件的名称。

    二进制日志文件名和位置是您用于 PITR 的值。

以下是 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)

要恢复到上面用粗体显示的 DROP TABLE 语句，您可以将“mysql-bin.000011”中的“865”用作恢复时间点。DROP TABLE 语句及其后面的所有操作都不会反映在新实例中。

使用二进制日志事件位置执行 PITR

gcloud

使用带有 --bin-log-file-name 和 --bin-log-position 标志的 gcloud sql instances clone 命令。

  1. 使用二进制日志文件名和恢复时间点创建新实例。

    替换以下内容：

    • SOURCE_INSTANCE_NAME：您要从中恢复的实例的名称。
    • NEW_INSTANCE_NAME：克隆的名称。
    • BINLOG_FILE_NAME：二进制日志的名称，例如 mysql-bin.187288。
    • POSITION：二进制日志中要恢复的时间点，例如 50001356。
    gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION

    例如，gcloud sql instances clone 命令可能类似于以下形式：

    gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
  2. 使用从 clone 命令返回的操作 ID 来查看恢复操作的状态。
    gcloud sql operations describe OPERATION_ID

    当操作正在进行时，将返回 RUNNING 状态。当操作完成后，将返回 DONE 状态。

REST v1

使用您已标识的二进制日志文件名和恢复时间点创建新实例：

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • target-instance-id：目标实例 ID
  • source-instance-id：源实例 ID
  • binary-log-file-name：二进制日志文件的名称
  • binary-log-position：二进制日志文件中的时间点

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

REST v1beta4

使用您已标识的二进制日志文件名和恢复时间点创建新实例：

在使用任何请求数据之前，请先进行以下替换：

  • project-id：项目 ID
  • target-instance-id：目标实例 ID
  • source-instance-id：源实例 ID
  • binary-log-file-name：二进制日志文件的名称
  • binary-log-position：二进制日志文件中的时间点

HTTP 方法和网址：

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

请求 JSON 正文：

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

如需发送您的请求，请展开以下选项之一：

您应该收到类似以下内容的 JSON 响应：

问题排查

问题 问题排查

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

或

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

 您提供的时间戳无效。

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

或

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

 您提供的时间戳是找不到备份或二进制日志坐标的时间。

排查切换到 Cloud Storage 的问题

下表列出了在您将事务日志的存储位置从磁盘切换到 Cloud Storage 时，可能会随 INVALID REQUEST 代码一起返回的可能错误。

问题 问题排查
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. 确保您是在 Cloud SQL for MySQL 或 Cloud SQL for PostgreSQL 实例上运行 gcloud CLI 命令或发出 API 请求。 Cloud SQL for SQL Server 不支持使用 gcloud CLI 或 Cloud SQL Admin API 切换事务日志的存储位置。
MySQL transactional logging is not enabled on this instance. MySQL 使用二进制日志作为时间点恢复 (PITR) 的事务日志。为了支持 PITR，MySQL 要求您在实例上启用二进制日志记录功能。如需详细了解如何启用二进制日志记录，请参阅启用 PITR。
This command is not supported on replica instances. Run the command on the primary instance instead. 请务必在运行命令或发出 API 请求时指定主实例。
This instance is already storing transaction logs used for PITR in Cloud Storage 如需验证事务日志的存储位置，请运行检查用于 PITR 的事务日志的存储位置中的命令。
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

等待切换操作完成。

如需验证操作状态和事务日志的存储位置，请运行检查用于 PITR 的事务日志的存储位置中的命令。

后续步骤