时间点恢复
IBM Cloud® Databases for MySQL 提供过去 7 天内任何时间的时间点恢复 (PITR)。 部署会以增量方式持续备份,并且可以重放事务以将从备份复原的新部署带到您需要的 7 天窗口中的任何位置。
部署用户界面的“备份”选项卡会在_“时间点恢复_”下保存所有 PITR 信息。
包含的信息是 PITR 的最早时间。 要通过 CLI 发现最早的恢复点,请使用 cdb mysql earliest-pitr-timestamp 命令。
ibmcloud cdb mysql earliest-pitr-timestamp <deployment name or CRN>
要通过 API 发现最早的恢复点,请使用 /deployments/{id}/point_in_time_recovery_data 端点来查找最早的 PITR 时间。
{
"point_in_time_recovery_data": {
"earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
}
}
恢复
备份将复原到新的部署。 新部署完成供应后,备份文件中的数据将复原到新部署中。 也可以跨帐户复原备份,但仅通过使用 API,并且仅当运行复原的用户对源帐户和目标帐户都具有访问权时才可复原备份。
缺省情况下,新部署的大小将自动调整为与要从中进行复原的备份时的源部署相同的磁盘和内存分配。 尤其是在 PITR 的情况下,这可能不是部署的当前大小。 如果需要调整分配给新部署的资源,请使用 UI,CLI 或 API 中的可选字段来调整新部署的大小。 请确保为数据和工作负载分配足够的资源,如果没有为部署提供足够的资源,那么复原将失败。
当存储和内存恢复到与源部署相同的状态时,不会自动为新实例设置特定实例配置。 在这种情况下,可能需要在复原后重新运行配置。 请注意运行复原之前的任何实例修改 (诸如 shared_buffers,max_connections,deadlock_timeout,archive_timeout 等参数),以确保复原完成后实例的准确设置。
在复原备份时不删除源部署至关重要。 请等待直到供应新部署并复原备份,然后再删除旧部署。 删除部署还会删除其备份,因此不仅复原会失败,您也可能无法恢复备份。
在 UI 中
要启动 PITR,请以全球标准时间输入要恢复到的时间。 如果只想复原到最近的可用时间,请选择该选项。 单击 复原 将显示用于恢复的选项。 输入名称,选择新部署的版本,区域和分配的资源。 点击 “恢复”以开始该过程。
如果使用 Key Protect 并具有密钥,请使用 CLI 进行恢复。 为方便起见,提供了一个命令。
在 CLI 中
资源控制器支持供应数据库部署,供应和复原由资源控制器 CLI 负责。 使用 resource service-instance-create 命令。
对于 PITR,请使用 point_in_time_recovery_time 和 point_in_time_recovery_deployment_id 参数。 point_in_time_recovery_deployment_id 是源部署的标识,point_in_time_recovery_time 是要复原到的全球标准时间的时间戳记。 如果要复原到最新的可用时间点,请使用
"point_in_time_recovery_time":" "。
ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> <region> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP"}'
在备份的详细视图中提供了针对特定备份或 PITR 的预格式化命令。
通过 CLI 进行复原时,可选参数可用。 如果需要定制资源,请使用它们,或者在新部署上使用 Key Protect 密钥进行 BYOK 加密。
ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> standard <region> <--service-endpoints SERVICE_ENDPOINTS_TYPE> -p
'{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'
在 API 中
资源控制器 支持供应数据库部署,供应和复原由资源控制器 API 负责。 在使用资源控制器 API 从备份复原之前,请完成 必需的步骤 以使用该 API。
拥有所有信息后,创建请求将是对 /resource_instances 端点的 POST。
curl -X POST
https://resource-controller.cloud.ibm.com/v2/resource_instances
-H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{
"name": "<SERVICE_INSTANCE_NAME>",
"target": "<region>",
"resource_group": "<your-resource-group>",
"resource_plan_id": "<service-id>",
"parameters":{
"point_in_time_recovery_time":"<TIMESTAMP>",
"point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
}
}'
参数 name,target,resource_group 和 resource_plan_id 都是必需的。 target 是您希望新部署所在的区域,可以是与源部署不同的区域。 支持跨区域复原,但将 eu-de 备份复原到其他区域除外。
对于 PITR,请使用 point_in_time_recovery_time 和 point_in_time_recovery_deployment_id 参数。 point_in_time_recovery_deployment_id 是源部署的标识,point_in_time_recovery_time 是要复原到的 UTC 时间戳记。 如果要复原到最新的可用时间点,请使用
"point_in_time_recovery_time":" "。
如果需要调整资源或使用 Key Protect 密钥,请将可选参数 key_protect_key,members_disk_allocation_mb,members_memory_allocation_mb 和/或 members_cpu_allocation_count 及其值添加到请求主体。
验证 PITR
要验证正确的恢复时间,请检查数据库日志。 检查数据库日志需要在部署中设置 日志集成。
执行恢复时,将从最近的增量备份复原数据。 WAL 日志中的任何未完成事务都将用于捕获数据库,直到您恢复到该数据库为止。 完成恢复并运行事务后,日志将显示一条消息。 您可以检查日志是否有以下信息。
LOG: last completed transaction was at log time 2019-09-03 19:40:48.997696+00
在两种情况下,恢复不会显示在日志中。
- 您的部署具有最近的完全备份,并且在执行备份后没有需要重放的活动。
- 如果输入要恢复到的时间是 之后 当前时间或超过最新的可用时间点恢复点。
在这两种情况下,恢复通常仍然成功,但日志中不会有用于检查数据库复原到的准确时间的条目。