本页面介绍了如何使用时间点恢复 (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 的事务日志的存储位置。
对于仅在磁盘上存储二进制日志的实例，您还可以先停用 PITR，然后再重新启用 PITR，从而将日志从磁盘移动到 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 SQL 可帮助您节省磁盘使用费。但是，如果您希望磁盘上提供更多日志（例如以便能够使用 mysqlbinlog 实用程序浏览二进制日志），请增加这些标志的值。Cloud SQL 会按照事务日志保留天数或为标志设置的值中的较小值来保留磁盘上的二进制日志。
对于存储在磁盘上上用于 PITR 的二进制日志，Cloud SQL 会保留为以下配置之一设置的最小值的日志：
transactionLogRetentionDays备份配置设置expire_logs_days或binlog_expire_logs_seconds标志修改这些标志的值可能会影响 PITR 恢复的行为以及在磁盘上存储多少天的日志。我们不建议您将上述任一标志的值配置为
0。如需详细了解这些标志，请参阅配置数据库标志。
对于启用了客户管理的加密密钥 (CMEK) 的实例，系统会使用最新版本的 CMEK 加密二进制日志。如需执行恢复操作，必须提供所有在为 retained-transaction-log-days 参数配置的天数内保持最新的密钥。
日志和磁盘使用量
日志会定期生成，并且会占用一定的存储空间。二进制日志会连同其关联的自动备份自动删除，删除操作会在满足为 transactionLogRetentionDays 设置的值后进行。
如需了解二进制日志使用了多少磁盘，请检查实例的 bytes_used_by_data_type 指标。binlog 数据类型的值会返回磁盘上二进制日志的大小。对于在磁盘上存储用于 PITR 的事务日志的实例，Cloud SQL 每天都会从磁盘中完全清除数据，以满足 transactionLogRetentionDays PITR 设置，如自动备份和事务日志保留中所述。但是，如果您将 expire_logs_days 标志设置为低于事务日志保留天数的值，则 Cloud SQL 可以更快地完全清除二进制文件。
如果二进制日志的大小导致实例出现问题：
- 检查实例是否将日志存储在磁盘上。您可以先停用 PITR，然后再重新启用 PITR，从而将 PITR 的日志从磁盘移动到 Cloud Storage。此操作会导致出现几分钟的停机时间，但会释放磁盘可用空间。 如果您使用的是 Cloud SQL 企业版，则还可以升级到 Cloud SQL 企业 Plus 版以切换 PITR 日志的存储位置。
您可以增加实例存储空间大小，但磁盘用量中的二进制日志大小的增加可能是临时的。
我们建议启用存储空间自动扩容功能，以避免意外的存储问题。
如果要删除日志并恢复存储空间，您可以停用 PITR，而不重新启用它。但是，减小所占用的存储空间不会缩小为实例预配的磁盘大小。
日志每天完全清除一次，不会持续清除。将日志保留设置为两天意味着系统会保留至少两天、最多三天的日志。我们建议将备份数量设置为日志保留天数加 1。
例如，如果您为
transactionLogRetentionDays参数的值指定7，则对于backupRetentionSettings参数，请将retainedBackups的数量设置为8。
如需详细了解 PITR，请参阅时间点恢复 (PITR)。
启用 PITR
当您在 Google Cloud 控制台中创建新实例时，自动备份和启用时间点恢复都会自动启用。以下过程会在现有主实例上启用 PITR。
控制台
-
在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。
- 打开要启用 PITR 的实例对应的“更多操作”菜单
，然后点击修改。 - 在自定义实例下，展开数据保护部分。
- 选中启用时间点恢复复选框。
- 在日志保留天数字段中，输入保留日志的天数（对于 Cloud SQL 企业 Plus 版为 1-35，对于 Cloud SQL 企业版为 1-7）。
- 点击保存。
gcloud
- 显示实例概览：
gcloud sql instances describe INSTANCE_NAME
- 如果您在
backupConfiguration部分中看到enabled: false，请启用计划备份：gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
使用 UTC±00 时区的 24 小时制时间指定
backup-start-time参数。 - 启用 PITR：
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
如果您要在主实例上启用 PITR，还可以通过添加以下参数来配置要保留事务日志的天数：
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- 确认更改：
gcloud sql instances describe INSTANCE_NAME
在
backupConfiguration部分，如果更改成功，您会看到binaryLogEnabled: true。
Terraform
如需启用 PITR，请使用 Terraform 资源。
应用更改
如需在 Google Cloud 项目中应用 Terraform 配置，请完成以下部分中的步骤。
准备 Cloud Shell
- 启动 Cloud Shell。
-
设置要在其中应用 Terraform 配置的默认 Google Cloud 项目。
您只需为每个项目运行一次以下命令，即可在任何目录中运行它。
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
如果您在 Terraform 配置文件中设置显式值，则环境变量会被替换。
准备目录
每个 Terraform 配置文件都必须有自己的目录（也称为“根模块”）。
-
在 Cloud Shell 中，创建一个目录，并在该目录中创建一个新文件。文件名必须具有
.tf扩展名，例如main.tf。在本教程中，该文件称为main.tf。mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
如果您按照教程进行操作，可以在每个部分或步骤中复制示例代码。
将示例代码复制到新创建的
main.tf中。（可选）从 GitHub 中复制代码。如果端到端解决方案包含 Terraform 代码段，则建议这样做。
- 查看和修改要应用到您的环境的示例参数。
- 保存更改。
-
初始化 Terraform。您只需为每个目录执行一次此操作。
terraform init
（可选）如需使用最新的 Google 提供程序版本，请添加
-upgrade选项：terraform init -upgrade
应用更改
-
查看配置并验证 Terraform 将创建或更新的资源是否符合您的预期：
terraform plan
根据需要更正配置。
-
通过运行以下命令并在提示符处输入
yes来应用 Terraform 配置：terraform apply
等待 Terraform 显示“应用完成！”消息。
- 打开您的 Google Cloud 项目以查看结果。在 Google Cloud 控制台的界面中找到资源，以确保 Terraform 已创建或更新它们。
删除更改
如需删除更改，请执行以下操作：
- 如需停用删除防护，请在 Terraform 配置文件中将
deletion_protection参数设置为false。deletion_protection = "false"
- 运行以下命令并在提示符处输入
yes，以应用更新后的 Terraform 配置：terraform apply
-
通过运行以下命令并在提示符处输入
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 参考文档。
如需完成后续任务，您必须拥有以下各项：
- 为实例启用二进制日志记录和备份，其中包含自您要从其恢复的事件之前的最后一次备份以来的连续二进制日志。如需了解详情，请参阅启用二进制日志记录。
- 用于定义恢复点的时间戳。在此时间戳所表示的时间发生的事件和之后发生的事件不会反映在新实例中。
控制台
-
在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。
- 打开要恢复的实例对应的“更多操作”菜单 ，然后点击创建克隆。
- （可选）在创建克隆页面上，更新新克隆的 ID。
- 选择从较早的时间点克隆。
- 输入 PITR 时间。
- 点击创建克隆。
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
控制台
-
在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。
- 打开要停用的实例对应的“更多操作”菜单 ，然后选择修改。
- 在自定义实例下，展开数据保护部分。
- 清除启用时间点恢复。
- 点击保存。
gcloud
- 停用时间点恢复：
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- 确认更改：
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 替换为实例名称。
在命令的输出中，transactionalLogStorageState 字段提供有关为实例存储 PITR 事务日志的位置的信息。可能的事务日志存储状态如下：
DISK：实例将用于 PITR 的事务日志存储在磁盘上。 如果您将 Cloud SQL 企业版实例升级到 Cloud SQL 企业 Plus 版，则升级过程还会将日志存储位置切换为 Cloud Storage。如需了解详情，请参阅使用就地升级将实例升级到 Cloud SQL 企业 Plus 版。SWITCHING_TO_CLOUD_STORAGE：实例正在将 PITR 事务日志的存储位置切换到 Cloud Storage。SWITCHED_TO_CLOUD_STORAGE：实例已完成将 PITR 事务日志的存储位置从磁盘切换到 Cloud Storage 的操作。CLOUD_STORAGE：实例将用于 PITR 的事务日志存储在 Cloud Storage 中。
设置事务日志保留
如需设置保留二进制日志的天数：
控制台
-
在 Google Cloud 控制台中，转到 Cloud SQL 实例页面。
- 打开要为其设置事务日志的实例对应的“更多操作”菜单 ，然后选择修改。
- 在自定义实例下，展开数据保护部分。
- 在启用时间点恢复部分中，展开高级选项。
- 输入保留日志的天数（对于 Cloud SQL 企业 Plus 版为 1-35，对于 Cloud SQL 企业版为 1-7）。
- 点击保存。
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
在使用任何请求数据之前，请先进行以下替换：
- days-to-retain：保留事务日志的天数（1 到 7 天）
- project-id：项目 ID
- instance-id：实例 ID
HTTP 方法和网址：
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
请求 JSON 正文：
{
"settings":
{
"backupConfiguration":
{
"transactionLogRetentionDays": "days-to-retain"
}
}
}
如需发送您的请求，请展开以下选项之一：
您应该收到类似以下内容的 JSON 响应：
REST v1beta4
在使用任何请求数据之前，请先进行以下替换：
- days-to-retain：保留事务日志的天数（1 到 7 天）
- project-id：项目 ID
- instance-id：实例 ID
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。
标识恢复时间点
使用 MySQL 客户端连接到要恢复的实例。
如需执行此操作，请使用 Cloud Shell 或本地客户端机器。 如需了解详情，请参阅外部应用连接方案。
显示实例的二进制日志文件：
SHOW BINARY LOGS;显示最近二进制日志文件中的前 100 个事件：
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;您可以调整要显示的行数，但如果不清楚文件的大小，不要显示文件中的所有事件。显示大量事件会影响系统的性能。
如果您正在查找的事件没有显示，请使用显示的最后一个时间点作为起点来搜索下一组事件：
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;当您找到标记要恢复到的时间点的事件时，请记录该位置（显示为
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 命令。
-
使用二进制日志文件名和恢复时间点创建新实例。
替换以下内容：
- 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 \
- 使用从
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 响应：
问题排查
| 问题 | 问题排查 |
|---|---|
|
或
|
您提供的时间戳无效。 |
|
或
|
您提供的时间戳是找不到备份或二进制日志坐标的时间。 |
后续步骤
- 在克隆上配置标志