执行时间点恢复 (PITR)

无论 Cloud SQL 主实例处于有效状态还是已删除,您都可以使用时间点恢复 (PITR) 来恢复该实例。借助 PITR,您可以将实例恢复到特定的时间点。对于已删除的实例,您可以将该实例恢复到特定时间点的新实例或现有实例。

Cloud SQL 提供以下选项来使用 PITR 恢复实例:

如需对不可用或已删除的实例执行 PITR,您需要找到最近和最早恢复时间

使用时间戳执行 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

如果您的 Cloud SQL 实例已启用增强型备份,则可以使用备份保险柜对该实例执行时间点恢复。

控制台

  1. 在 Google Cloud 控制台中,前往 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 打开要恢复的实例对应的“更多操作”菜单 “更多操作”图标。,然后点击创建克隆

  3. 选择从较早的时间点克隆

  4. 输入 PITR 时间。

  5. 点击创建克隆

gcloud

如需对备份保险柜中的实例执行 PITR,您需要找到最接近要执行 PITR 的时间的备份的 data-source。如需查找备份,请参阅列出备份保险柜中实例的所有备份。确定备份后,运行以下命令以执行 PITR:

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

替换以下内容:

  • DATA_SOURCE:最接近您要恢复到的 PITR 时间戳的备份的 data-source 路径。
  • PITR_TIMESTAMP:您要将实例恢复到的源实例 PITR 日志的 UTC 时间戳,采用 RFC 3339 格式。例如 2012-11-15T16:19:00.094Z。
  • TARGET_PROJECT:Cloud SQL 实例的项目 ID。

REST v1

REST v1beta4

对不可用实例执行 PITR

控制台

由于以下原因,您可能需要将不可用的实例恢复到其他可用区:

  • 配置了实例的可用区无法访问。此实例处于 FAILED 状态。
  • 实例正在进行维护。此实例处于 MAINTENANCE 状态。

如需恢复不可用的实例,请完成以下步骤:

  1. 在 Google Cloud 控制台中,前往 Cloud SQL 实例页面。

    转到“Cloud SQL 实例”

  2. 找到要克隆的实例的行。
  3. 操作列中,点击 更多操作菜单。
  4. 点击创建克隆
  5. 创建克隆页面上,完成以下操作:
    1. 实例 ID 字段中,根据需要更新实例 ID。
    2. 点击从较早的时间点克隆
    3. 时间点字段中,选择要克隆数据的日期和时间。这将恢复该时间点的实例状态。
    4. 点击创建克隆
  6. 克隆初始化时,您将返回到实例列表页面。

gcloud

由于配置了实例的可用区无法访问,您可能需要将不可用的实例恢复到其他可用区。

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

运行 gcloud sql instances clone 命令的用户或服务账号必须拥有 cloudsql.instances.clone 权限。如需详细了解运行 gcloud CLI 命令所需的权限,请参阅 Cloud SQL 权限

REST v1

由于配置了实例的可用区无法访问,您可能需要将不可用的实例恢复到其他可用区。

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

  • PROJECT_ID:项目 ID
  • SOURCE_INSTANCE_ID:源实例 ID
  • TARGET_INSTANCE_ID:目标实例 ID

HTTP 方法和网址:

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

请求 JSON 正文:

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

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

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

使用 instances.clone API 方法的用户或服务账号必须拥有 cloudsql.instances.clone 权限。如需详细了解使用 API 方法所需的权限,请参阅 Cloud SQL 权限

REST v1beta4

由于配置了实例的可用区无法访问,您可能需要将不可用的实例恢复到其他可用区。

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

  • PROJECT_ID:项目 ID
  • SOURCE_INSTANCE_ID:源实例 ID
  • TARGET_INSTANCE_ID:目标实例 ID

HTTP 方法和网址:

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

请求 JSON 正文:

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

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

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

使用 instances.clone API 方法的用户或服务账号必须拥有 cloudsql.instances.clone 权限。如需详细了解使用 API 方法所需的权限,请参阅 Cloud SQL 权限

如果您尝试在最新可恢复时间之后创建 PITR 克隆,系统会显示以下错误消息:

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.

对已删除的实例执行 PITR

如需使用 PITR 恢复已删除的实例,您需要:

  • 您要将实例恢复到的 PITR 时间戳 (timestamp)
  • 目标实例名称
  • 源实例的删除时间 (source-instance-deletion-time)

您只能使用 gcloud CLI 或 Cloud SQL API 对已删除的实例使用 PITR。如需了解详情,请参阅使用 PITR 恢复已删除的实例

gcloud

查找 PITR 窗口

如需查找已删除实例的 PITR 窗口,请获取该实例的最早和最近恢复时间。您可以在此窗口中选择任意时间戳来执行 PITR。

查找源实例删除时间和日志保留天数

实例删除后,系统会将已删除实例的 source-instance-deletion-timelog-retention-days 与为您的实例保留的备份一起存储。如需查找已删除实例的这些值,请参阅列出保留的备份

使用 PITR 进行恢复

如需使用 PITR 恢复已删除的实例,请运行以下命令:

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

替换以下内容:

  • SOURCE_INSTANCE_NAME:您要恢复的源实例的名称。
  • NEW_INSTANCE_NAME:新实例的名称。
  • PITR_TIMESTAMP:您要将实例恢复到的源实例 PITR 日志的 UTC 时间戳,采用 RFC 3339 格式。例如,2012-11-15T16:19:00.094Z。
  • SOURCE_INSTANCE_DELETION_TIMESTAMP:源实例的删除时间(采用 RFC 3339 格式)的 UTC 时间戳。 例如 2012-11-15T16:19:00.094Z。

REST v1

查找 PITR 窗口

如需查找已删除实例的 PITR 窗口,请获取该实例的最早和最近恢复时间。您可以在此窗口中选择任意时间戳来执行 PITR。

查找源实例删除时间和日志保留天数

实例删除后,系统会将已删除实例的 source-instance-deletion-timelog-retention-days 与为您的实例保留的备份一起存储。如需查找已删除实例的这些值,请参阅列出保留的备份

使用 PITR 进行恢复

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

  • project-id:项目 ID
  • target-instance-id:目标实例 ID
  • source-instance-id:源实例 ID
  • source-instance-deletion-time:源实例的删除时间
  • 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",
    "sourceInstanceDeletionTime: "source-instance-deletion-time",
    "pointInTime": "restore-timestamp"
  }
}

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

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

REST v1beta4

查找 PITR 窗口

如需查找已删除实例的 PITR 窗口,请获取该实例的最早和最近恢复时间。您可以在此窗口中选择任意时间戳来执行 PITR。

查找源实例删除时间和日志保留天数

实例删除后,系统会将已删除实例的 source-instance-deletion-timelog-retention-days 与为您的实例保留的备份一起存储。如需查找已删除实例的这些值,请参阅列出保留的备份

使用 PITR 进行恢复

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

  • project-id:项目 ID
  • target-instance-id:目标实例 ID
  • source-instance-id:源实例 ID
  • source-instance-deletion-time:源实例的删除时间
  • 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",
    "sourceInstanceDeletionTime: "source-instance-deletion-time",
    "pointInTime": "restore-timestamp"
  }
}

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

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

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

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

如需详细了解如何使用二进制日志时间点执行 PITR,请参阅使用二进制日志执行 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 响应:

获取最早和最晚的恢复时间

对于可用实例,您可以执行 PITR 以恢复到实例 PITR 窗口中的任何时间戳。PITR 窗口从最早恢复时间开始,到最近恢复时间结束。如果实例不可用,并且实例日志存储在 Cloud Storage 中,或者实例已删除且启用了 PITR 保留,您可以检索最早和最近恢复时间,并执行到该窗口内的任何时间戳的 PITR。 在所有情况下,您都可以通过为主可用区提供值来将实例恢复到其他主可用区或次要可用区

gcloud

不可用实例

如需获取不可用的 Cloud SQL 实例可以恢复到的最早和最近时间,请运行以下命令:

gcloud sql instances get-latest-recovery-time INSTANCE_NAME

替换以下内容:

  • INSTANCE_NAME:您要查找最近恢复时间的实例的名称。

实例已删除

如需获取 Cloud SQL 已删除实例可以恢复到的最早和最近时间,请运行以下命令:

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

替换以下内容:

  • INSTANCE_NAME:您要查找最近恢复时间的实例的名称。
  • SOURCE_INSTANCE_DELETION_TIMESTAMP:源实例的删除时间(采用 RFC 3339 格式)的 UTC 时间戳。 例如 2012-11-15T16:19:00.094Z。

REST v1

不可用实例

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

  • PROJECT_ID:项目 ID
  • INSTANCE_NAME:您要查询最近恢复时间的实例的名称

HTTP 方法和网址:

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

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

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

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

实例已删除

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

  • PROJECT_ID:项目 ID
  • INSTANCE_NAME:您要查询最近恢复时间的源实例的名称
  • SOURCE_INSTANCE_DELETION_TIME:源实例删除的时间

HTTP 方法和网址:

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

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

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

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

REST v1beta4

不可用实例

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

  • PROJECT_ID:项目 ID
  • INSTANCE_NAME:您要查询最近恢复时间的实例的名称

HTTP 方法和网址:

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

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

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

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

实例已删除

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

  • PROJECT_ID:项目 ID
  • INSTANCE_NAME:您要查询最近恢复时间的源实例的名称
  • SOURCE_INSTANCE_DELETION_TIME:源实例删除的时间

HTTP 方法和网址:

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

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

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

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

问题排查

问题 问题排查

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.

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

后续步骤