KingbaseES物理备份恢复最佳实践.pdf

KingbaseES 物理备份恢复最佳实践 金仓数据库管理系统 KingbaseES 文档版本：V9（V009R001C001B0024） 发布日期：2023 年 10 月 12 日 北京人大金仓信息技术股份有限公司 目 目 录 录 第 1 章 前言 1 1.1 适用读者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 相关文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 手册约定 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 2 章 概述 5 什么是备份和恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 备份恢复速度的制约条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 备份恢复的重要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 什么是 TimeLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 查看当前 TimeLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 什么是 XID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 故障类别介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 2.1.1 2.3.1 第 3 章 数据恢复解决方案 10 3.1 sys_rman 备份方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 数据丢失恢复策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 恢复目标点的确定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 恢复后是否提升节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3 多时间线恢复点的确定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.4 目标明确的恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.5 目标不明确的恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 第 4 章 使用 sys_rman 的准备工作 19 4.1 收集并确定备份部署方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 确定备份策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 开启日志归档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4 初始化配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5 执行初始化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6 备份计划启停 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 I 目 第 5 章 执行备份 录 22 5.1 全量备份 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 差异备份 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3 增量备份（块粒度） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4 增量备份（文件粒度） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 第 6 章 物理备份相关的其他操作 27 6.1 查看已有备份集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2 清除过期的备份 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3 备份集检查 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4 性能优化-并行处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.5 性能优化-压缩优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 第 7 章 执行还原 30 7.1 停止数据库服务 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2 最新备份文件还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.3 指定备份集还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.4 指定事务 ID 还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5 指定时间点还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.6 表空间支持 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.7 备机还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.8 集群还原 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.9 还原后节点处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 第 8 章 特殊场景恢复实践案例 38 8.1 指定时间点恢复和指定备份集恢复的区别 8.2 无法恢复到最新增量数据 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.3 恢复后启动数据库报错 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.4 恢复后发现查询卡住 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.4.1 原因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.4.2 解决方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.4.3 复现和定位问题步骤 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.5 恢复后发现 database 被删除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.6 集群备库如何恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 第 9 章 附 A: 备份恢复常见异常处理 48 版权声明 49 服务周期承诺 50 II 第 1 章 前言 1 第 章 前言 本文描述了 KingbaseES 物理备份与恢复 (sys_rman 工具) 的最佳使用实践。 前言部分包含以下主题： • 适用读者 • 相关文档 • 术语 • 手册约定 1.1 适用读者 KingbaseES 物理备份恢复最佳实践适用于所有使用 KingbaseES 的数据库管理员 (DBAs)，应用程序开发者，安 全管理员，系统运维或管理人员。 1.2 相关文档 有关 KingbaseES 物理备份恢复工具最佳实践关联技术的更多信息，请参阅以下资源： • 《KingbaseES 物理备份恢复工具手册》 1.3 术语 1 第 1 章 前言 术语 定义 物理备份 即 physical backup，指对数据库文件的复制，从一个物理位置拷贝到另一个物理 位置。 逻辑备份 即 logical backup，指在联机状态下读取或导入数据库中用户创建的数据库对象 信息，包含表、视图、数据、存储过程等，基于 SQL 语句为基础进行。 备份集 即 backup set ，指一次备份的所有备份内容的集合。 全量备份 即 full backup. 针对所有需要的文件进行的一次备份。当还原时，不需要额外的 依赖，通过此全量备份即可恢复数据文件到备份时的状态。 差异备份 即 differential backup, 属于选择性备份，仅选择上一次全量备份后，发生了变化 的文件。优点是节省了一定的空间，相比于全量备份。缺点是还原时，需要本次 差异备份及其依赖的全量备份。 增量备份 即 file incremental backup，属于选择性备份，仅选择上一次全量或差异或增量备 份后，发生了变化的文件。优点是更加地节省空间。缺点是还原时，需要本次增 量备份以及前次备份、再前次备份、直到串行依赖到一次全量备份。 块增量备份 属 page incremental backup，属于选择性备份，在上一次全量或差异或增量备份 后时间线未发生改变的情况下，仅选择上一次全量或差异或增量备份后，发生了 变化的表文件的数据块和其他发生了变化的非表文件。优点是更加地节省空间。 缺点是还原时，需要本次块增量备份以及前次备份、再前次备份、直到串行依赖 到一次全量备份；并且需要依赖 ktrack 插件。 Stanza 是一个字符串标签，用来具名化若干备份还原信息；是一个定义备份还原所需信 息的包裹，是一个包含若干个配置参数的集合。一般来说，stanza 就可以表示一 个集群。 Tool 备份还原工具 sys_rman，在部署架构中表示本工具逻辑上的角色。 Repo 仓库，用来实际存储备份文件的介质，可以是指定本地文件夹，或是远程主机文 件夹。 Ktrack KingbaseES 数据库服务器的插件，用来持续追踪记录发生改变的表文件的数据 块。 仓库节点 主要包括以下用途： • 部署可执行程序 sys_rman+ 配置文件 +Repo 仓库 • 需要 KingbaseES 客户端环境，包含 bin lib share 目录 • 启动软件程序主入口，可称为前台 sys_rman 进程 见续表 2 第 1 章 前言 表 1.3.1 – 续表 术语 定义 非仓库数据库节点 主要包括以下用途： • 部署可执行程序 sys_rman+ 配置文件 • 需要 kingbase 环境且正常运行 • 不能直接执行，将由 SSH 远程带起后台 sys_rman 进程 PITR（Point-in-Time Recov- 时间点恢复：将一个文件系统级别的备份集和 WAL (预写式日志) 级别的增量 ery） 备份结合起来，当需要恢复时，先恢复文件系统级别的备份，然后重放备份的 WAL 文件，把系统恢复到之前的某个状态。 1.4 手册约定 本文档中可能出现“注意、提示、警告、另请参阅”等标志，它们所代表的含义如下： 注意: 用于突出重要/关键信息、最佳实践等。 提示: 用于突出小窍门、捷径等。 警告: 用于传递设备或环境安全警示信息，若不避免，可能会导致设备损坏、数据丢失、设备性能降低或其 它不可预知的结果。 另请参阅: 用于突出参考、参阅等。 以下程序代码书写约定适用于本文档： 符号 说明 [] 表示包含一个或多个可选项。不需要输入中括号本身。 {} 表示包含两个以上（含两个）的候选，必须在其中选取一个。不需要输入花括号本身。 | 分割中括号或者花括号中的两个或两个以上选项。不需要输入“|”本身。 见续表 3 第 1 章 前言 表 1.4.1 – 续表 符号 说明 ... 表示其之前的元素可以被重复。 斜体 表示占位符或者需要提供特定值的变量。 大写 表示系统提供的元素，以便与用户定义的元素相互区分。除出现在方括号中的元素外，应当按 照顺序逐字输入。当然，部分元素在系统中是大小写不敏感的，因此用户可以根据系统说明以 小写形式输入。 小写 表示由用户提供的元素。 4 第 2 章 概述 2 第 章 概述 计算机系统不可避免地会发生内部故障、系统故障、硬件故障等问题，这些问题会造成数据库中的事务非正常停 止，或部分数据丢失，因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状 态或完整状态）的功能，这就是数据库的备份与恢复。 KingbaseES 提供的备份恢复方式可以分为两种：一种是基于日志的物理备份恢复，另一种基于 SQL 语句的逻辑 备份还原。物理备份恢复和逻辑备份还原都是各自采用了不同的技术手段来达到保护数据的目的。基于日志的物理备 份恢复和基于 SQL 语句的逻辑备份还原各有特点，适用于不同的场合，没有直接的好坏之分。 本部分包含以下章节： • 什么是备份和恢复 • 备份恢复的重要性 • 什么是 TimeLine • 什么是 XID • 故障类别介绍 2.1 什么是备份和恢复 物理备份恢复指的是通过备份集和归档日志将数据库转化为一致状态的过程，操作数据库的存储，如数据文件、 日志文件等。KingbaseES 通过备份磁盘中数据目录下的物理文件（数据文件、控制文件和日志文件），依靠还原数 据文件和日志恢复技术来保护数据。目前只支持全系统备份，不支持单个数据库备份。 2.1.1 备份恢复速度的制约条件 备份时，需要执行 SQL 查询，归档日志，拷贝文件，因此影响备份速度的因素较多；恢复时，需要拷贝文件， 启动数据库后 PITR 需要归档日志重做到目标点，因此影响恢复速度的因素也较多。具体请查看下表： 5 第 2 章 概述 影响因素 影响类型 影响分析 建议方案 硬盘读写速率 备份、还原 备份或还原都需要拷贝文 件、读取文件，硬盘速率 可能会成为备份还原速度 的瓶颈。 1. 使用高速度的硬盘或存 储设备； 2. 在硬盘利用率较低时执 行备份还原。 网络速率 备份、还原 备份集可能存储在另一台 设备上，备份或还原时受 限于网络速率。 1. 升级网络，比如千兆变 万兆或者链路聚合； 2. 在网络空闲时执行备份 恢复。 数据库业务繁忙程度 备份 备份时需要执行 SQL， 在数据库业务相对空闲时 数据库业务繁忙时响应时 执行备份，参考用户使用 间会增加；备份时会等待 手册设置 --start-fast 归档当前 WAL 文件成 。 功，若业务繁忙积攒了很 多 WAL，归档进程也会阻 塞备份。 CPU、内存 备份、还原 备份还原依赖硬件资源， 在硬件资源相对空闲时执 若硬件资源竞争激烈，必 行备份或还原。 定会降低备份还原速度。 2.2 备份恢复的重要性 对于事务内部故障和系统故障，数据库将使用日志文件自动恢复，不需要人工进行干预。但对于硬件故障、操作 人员的失误以及恶意破坏事件，数据库无法进行自动恢复。因此，数据库管理员定期备份数据就很必要，当故障发生 时，可以使用备份数据来恢复数据库。 2.3 什么是 TimeLine 数据库恢复到过去时间点时，会导致类似科幻小说里的时间旅行和平行宇宙的复杂情况，因而需要标识这些“平 行宇宙”。每当数据库恢复完成时，都会创建一个新的时间线（类似于因时间旅行而产生的新的平行宇宙）来标识在 6 第 2 章 概述 该恢复后产生的 WAL 日志，为了区分因数据库恢复造成的不同时间段的 WAL 日志而产生的时间记录称为时间线 （TimeLine），WAL 日志文件名 000000010000000000000001 中前八位 00000001 表示的便是数据库的时间线。 数据库初始化后，默认时间线是 1，随着数据库系统的运行，新时间线会在以下两种情况下产生： • PITR 恢复后执行了 promote 操作（select sys_wal_replay_resume() ） • 备节点升为主节点 每次创建一个新的时间线，KingbaseES 都会创建一个“时间线历史”文件，文件名后缀为 .history ，它里面 的内容是由原时间线 history 文件的内容再追加一条当前时间线切换记录。假设数据库恢复启动后，切换到新的时间 线 ID 为 4，那么文件名就是 00000004.history ，该文件记录了当前时间线是在什么时间从哪个时间线由于什么原 因分出来的，该文件可能含有多行记录，比如： $ cat 00000004.history 1 0/140000C8 no recovery target specified 2 0/19000060 no recovery target specified 3 0/1F000090 no recovery target specified 下图是时间线切换的示例，数据库正常运行在时间线 1 上，做过基础的备份，并且 WAL 日志归档完整，周五时 发现关键数据丢失，经排查是 周四 13:00 时误操作导致的，周四 12:00 时到 周四 13:00 时期间无数据写入，因 此将数据库恢复至 周四 12:00 时的状态，恢复后确认数据符合预期，从此数据库运行在 时间线 2 上。 7 第 2 章 概述 2.3.1 查看当前 TimeLine 可使用 SQL 查询 select timeline_id from sys_control_checkpoint(); 或者 sys_controldata 命令查询 数据库系统当前时间线，可参见如下： test=# select timeline_id from sys_control_checkpoint(); timeline_id ------------1 (1 row) 或 $ /opt/Kingbase/ES/V9/Server/bin/sys_controldata -D data | grep "WalTimeLineID" Latest checkpoint's WalTimeLineID: 1 备份集的时间线信息可以通过 sys_rman info 命令查询（wal start/stop 值的左起 8 个数字），参见： $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase info stanza: kingbase status: ok cipher: none db (current) wal archive min/max (V008R006B0605): 000000010000000000000002/000000010000000000000006 full backup: 20230704-015253F timestamp start/stop: 2023-07-04 01:52:53 / 2023-07-04 01:53:47 wal start/stop: 000000010000000000000003 / 000000010000000000000004 database size: 102.9MB, database backup size: 102.9MB repo1: backup set size: 102.9MB, backup size: 102.9MB incr backup: 20230704-015253F_20230704-015419I timestamp start/stop: 2023-07-04 01:54:19 / 2023-07-04 01:54:20 wal start/stop: 000000010000000000000006 / 000000010000000000000006 database size: 86.9MB, database backup size: 16MB repo1: backup set size: 86.9MB, backup size: 16MB backup reference list: 20230704-015253F 2.4 什么是 XID 事务 ID 简称 XID（transaction ID），是用于标识事务的唯一 ID，在事务开启时分配，是代表事务的顺序编 号，在 KingbaseES 内部都是单调递增，不会重复的。KingbaseES 支持恢复到某个指定的事务 ID，常用于精准恢 8 第 2 章 概述 复。 例如，以下的场景可应用 XID 恢复： • 参考本文复现和定位问题步骤 中查找 XID 的方法，使用《KingbaseES 服务器应用参考手册》中的 sys_waldump 查询 WAL 段文件中的 XID 并恢复。 • 可在 SQL 中调用 txid_current() 获取当前事务的 XID，用于后续恢复 2.5 故障类别介绍 当遇到下述表格内的故障时，通过物理备份恢复就可以解决问题。 故障类别 举例说明 硬件故障 硬盘坏道导致表文件读取失败 数据库系统故障 突然断电导致的缓存（OS 或硬盘）中的数据没有真正写入到持久化存储内 物理内存芯片损坏，加载到数据库缓存中的数据异常，该数据刷回存储介质时写入了错误的数据 数据库内核某项功能出现严重 BUG，导致数据库 core 掉，无法再次拉起数据库服务 操作系统故障 操作系统突然死掉，导致正在运行的数据库服务没有及时将缓存中的脏数据写到存储介质中 误操作或恶意操作 恶意程序或病毒感染了操作系统，数据库关键表文件被加密，数据库服务异常报错 删除表数据时忘记添加限定条件，导致表被清空 物理文件删除或损坏，比如数据库 data 目录被删除，或某个文件被删除 出于报复等原因恶意删库 9 第 3 章 数据恢复解决方案 3 第 章 数据恢复解决方案 为了预防上述故障的发生，同时提升数据的高可用性，KingbaseES 提供了 sys_rman 物理备份恢复工具，该工 具集成了 WAL 文件归档、PITR 恢复等功能，实现了自动化定时备份以及灵活多样化的恢复，为用户提供了安全便 捷的数据备份恢复解决方案。 sys_rman 工具的介绍与部署请参考《KingbaseES 物理备份恢复工具手册》，这里不再赘述。 本部分包含以下章节： • sys_rman 备份方式 • 数据丢失恢复策略 3.1 sys_rman 备份方式 下表对 sys_rman 支持的备份类型做了一个简要说明。 10 第 3 章 数据恢复解决方案 备份类型 优点 缺点 全量备份 针对所有需要的文件进行 占用的存储空间大 的一次备份。当还原时， 适应场景 1. 首次备份 不需要额外的协助，通过 此全量备份即可恢复数据 2. 长周期的定时备份 库到备份时的状态。 3. 执行恢复操作后，恢复 后的数据符合预期时，建 议做一次全量备份 差异备份 选择性备份，仅选择上一 还原时，需要本次差异备 次全量备份后，发生了变 份及其依赖的全量备份 短周期的定时备份 化的文件，相比于全量备 份节省了一定的存储空 间。 增量备份 块增量备份 选择性备份，仅选择上一 还原时，需要本次增量备 短周期的定时备份 次全量或差异或增量备份 份以及前次备份、再前次 后，发生了变化的文件， 备份、直到串行依赖到一 更加地节省存储空间。 次全量备份 选择性备份，在上一次全 还原时，需要本次块增量 适用于一些大表文件仅更 量或差异或增量备份后时 备份以及前次备份、再前 新了几条记录的情况 间线未发生改变的情况 次备份、直到串行依赖到 下，仅选择上一次全量或 一次全量备份；并且需要 差异或增量备份后，发生 依赖 ktrack 插件。 了变化的表文件的数据块 和其他发生了变化的非表 文件，比其他备份类型更 加地节省存储空间。 3.2 数据丢失恢复策略 数据库恢复的原理简单来说，是首先通过拷贝物理备份集建立起一个基础的数据库 data 目录全貌，然后将要恢 复到的目标点写入配置文件，这两步使用 sys_rman restore 命令即可完成，最后启动数据库进入恢复模式，借助归 档的 WAL 文件恢复至目标点并暂停，需要人工确认恢复是否符合预期再执行后续操作。 若恢复符合预期，则执行 sys_wal_replay_resume() 将数据库由恢复模式转到正常运行模式，此时数据库运行 在新的时间线上；若不符合预期，则需要停止数据库删掉 data 目录，重新确定恢复目标点再次恢复。 11 第 3 章 数据恢复解决方案 3.2.1 恢复目标点的确定 sys_rman 恢复的第一个原则就是通过离目标点最近的备份集和 WAL 日志做恢复，这样可以减少 WAL 重做的 数量，在一定程度上避免因 WAL 文件缺失导致的恢复后数据库无法正常启动的问题。离目标点最近的备份集既可以 指定该备份集加时间做恢复，也可以只指定时间做恢复，需要注意的是该时间必须大于备份集的结束时刻，否则会使 用上一个备份集做恢复。 在下图中，由于缺少一个基础的备份集支撑，因而无法恢复到 位置 1 ；而 位置 2、位置 3、位置 4 都是可用的 恢复目的点。 以下图所示的情况，介绍指定时间点恢复与指定备份集恢复时，sys_rman restore 恢复命令的差异与注意事项： 12 第 3 章 数据恢复解决方案 恢 复 指定时间点恢复使用的 目标 备份集 位 置 全量备份 1 1 指定备份集恢复 特殊说明 全量备份 1 + 位置 1 的 若 只 指 定 备 份 集 恢 复， 未 提 供 恢 复 的 结 束 点， 时刻 sys_rman 会自动添加该备份集结束时刻作为恢复 的结束点 位 置 增量备份 1 2 虽然两种方式都可以完成恢复任务，但利用最新的 全量备份 1 + 位置 2 的 时刻 备份集做恢复是最优选择，这样可以减少 WAL 重 做的数量，在一定程度上避免因 WAL 文件缺失导 致的恢复后数据库无法正常启动的问题。 或者 增量备份 1 + 位置 2 的 时刻 位 置 增量备份 1 3 指定时间点恢复需要注意的是该时间必须大于备份 全量备份 1 + 位置 3 的 集的结束时刻，否则会使用上一个备份集做恢复。 时刻 或者 增量备份 1 + 位置 3 的 时刻 或者 全量备份 2 + 位置 3 的 时刻 位 置 4 差异备份 1 全量备份 1 + 位置 4 的 优先使用最近的差异备份 1 做恢复，若恢复失败， 时刻 可以尝试使用次最近的备份集（全量备份 2）做恢 或者 复。 增量备份 1 + 位置 4 的 时刻 指定时间点恢复只会选择差异备份 1 做恢复，若因 或者 差异备份 1 文件损坏导致的恢复失败，可以尝试指 全量备份 2 + 位置 4 的 定备份集恢复。 时刻 或者 差异备份 1 + 位置 4 的 时刻 13 第 3 章 数据恢复解决方案 3.2.2 恢复后是否提升节点 恢复结束后，如果只是用来测试是否恢复到当前数据，则无须执行 sys_wal_replay_resume() ，因为执 行后时间线会切换，多条时间线的出现会对后续的还原造成干扰；或者恢复后的数据不符合预期，也无须执行 sys_wal_replay_resume() 提升节点。 比如下图所示场景，第一次在 位置 1 处执行了恢复操作，启动数据库后发现数据不符合预期，因而未执行 sys_wal_replay_resume() , 时间线未切换，将该库关闭后删除 data 目录；重新到 位置 2 处执行恢复，恢复后发 现数据符合预期，执行 sys_wal_replay_resume() ，该库正式作为生产库启用，时间线切换到 2. 下面所示的场景，第一次在 位置 1 执行恢复，在拉起数据库后执行了 sys_wal_replay_resume() 操作，时间线 切换到了 2；之后若想恢复到时间线 1 上的增量备份 2 之后的 位置 2 ，需添加时间线参数 --target-timeline=1 ， 否则默认会恢复到最新的时间线 2 上的 位置 3 。 14 第 3 章 数据恢复解决方案 3.2.3 多时间线恢复点的确定 时间线发生过切换后，执行恢复时需要确定恢复目标点在哪条时间线上，默认是使用最新的时间线做恢复的，若 想恢复到旧时间线上的某个位置，需要添加时间线参数避免 PITR 恢复时发生歧义导致数据错乱。 15 第 3 章 数据恢复解决方案 3.2.4 目标明确的恢复 目标明确的恢复只需要考虑时间线因素即可，默认使用最新的时间线做恢复，若想恢复到旧时间线上的某个位置 请添加时间线参数限制。 下图所示情况，当需要恢复到 位置 1 时，可直接使用时间点恢复或指定备份集恢复： /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置 1 的时刻' /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore -set='增量备份 1' --type=time --target='位置 1 的时刻' 16 第 3 章 数据恢复解决方案 下图所示情况，数据库在 位置 1 时发生过恢复，当前数据库运行在时间线 2 上，此时需要恢复到时间线 1 上的 位置 2 ，需要在恢复时指定时间线： /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置 2 的时刻' --target-timeline=1 /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置 2 的时刻' --target-timeline=1 –set=’增量备份 2’ 3.2.5 目标不明确的恢复 目标不明确的恢复比较常见，适用于多次尝试寻找最终恢复点，需要操作的步骤较多，比如下面这个示例： 第一次在 位置 1 处 执 行 了 恢 复 操 作， 启 动 数 据 库 后 发 现 数 据 不 符 合 预 期， 因 而 未 执 行 sys_wal_replay_resume() 时间线未切换，将该库关闭后删除 data 目录；重新到 位置 2 处执行恢复，恢复后 发现数据符合预期，执行 sys_wal_replay_resume() ，该库正式作为生产库启用，时间线切换到 2. /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置 1 的时刻' /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置 2 的时刻' 17 第 3 章 数据恢复解决方案 18 第 4 章 使用 SYS_RMAN 的准备工作 4 第 章 使用 sys_rman 的准备工作 本部分包含以下章节： • 收集并确定备份部署方式 • 确定备份策略 • 开启日志归档 • 初始化配置 • 执行初始化 • 备份计划启停 4.1 收集并确定备份部署方式 在使用 sys_rman 之前，需要收集如下信息： • 物理机器属性，专用机、普通服务器 • 数据库部署方式，单机还是集群 • 备份存储目的地，数据库机器、另外一台独立机器 • 备份存储目录的属性，本地磁盘、网络挂载磁盘 然后，就可以据此确定 sys_rman 的部署方式了，是单机本地备份、单机异地备份、集群内部备份，还是集群外 部备份。具体 sys_rman 部署方式请参考《高可用最佳应用实践》中的 备份恢复，或者参考《KingbaseES 物理备份 恢复工具手册》。 4.2 确定备份策略 sys_rman 支持设置自动备份策略，具体配置项（sys_backup.conf 内）请见下图： 19 第 4 章 使用 SYS_RMAN 的准备工作 4.3 配置项 释义 _repo_retention_full_count 保存全量备份的数目，超过此数目的全量备份将被自动移除 _crond_full_days 自动执行全量备份的间隔天数 _crond_diff_days 自动执行差异备份的间隔天数 _crond_incr_days 自动执行增量备份的间隔天数 _crond_full_hour 自动执行全量备份的时间点 _crond_diff_hour 自动执行差异备份的时间点 _crond_incr_hour 自动执行增量备份的时间点 开启日志归档 通过 sys_backup.sh 执行初始化后，会自动启用 WAL 日志归档，sys_rman 会统一管理归档日志和备份集，无 需人工手动干预。 4.4 初始化配置 优先使用 bin/sys_backup.conf 配置文件，若 bin 目录下不存在则默认使用 share/sys_backup.conf 文件。按照 之前收集好的备份部署信息，配置 sys_backup.conf 文件。具体配置参数讲解请参见《KingbaseES 备份与恢复工具 手册》。 4.5 执行初始化 在配置好 sys_backup.conf 后，执行 sys_backup.sh init 即可完成初始化。 $ /opt/Kingbase/ES/V9/Server/bin/sys_backup.sh init # pre-condition: check the non-archived WAL files # generate single sys_rman.conf...DONE # update single archive_command with sys_rman.archive-push...DONE # create stanza and check...(maybe 60+ seconds) # create stanza and check...DONE # initial first full backup...(maybe several minutes) # initial first full backup...DONE 20 第 4 章 使用 SYS_RMAN 的准备工作 # Initial sys_rman OK. 'sys_backup.sh start' should be executed when need back-rest feature. 4.6 备份计划启停 执行 sys_backup.sh start 即可开启自动定时备份功能，执行 sys_backup.sh stop 即可关闭自动定时备份功能。 $ /opt/Kingbase/ES/V9/Server/bin/sys_backup.sh start # pre-condition: check the non-archived WAL files Enable some sys_rman in crontab-daemon Set full-backup in 7 days Set incr-backup in 1 days 0 2 */7 * * /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf -stanza=kingbase --archive-copy --type=full backup >> /opt/Kingbase/ES/V9/Server/log/sys_rman_backup_full.log 2>&1 0 4 */1 * * /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf -stanza=kingbase --archive-copy --type=incr backup >> /opt/Kingbase/ES/V9/Server/log/sys_rman_backup_incr.log 2>&1 $ /opt/Kingbase/ES/V9/Server/bin/sys_backup.sh stop # pre-condition: check the non-archived WAL files Disable all sys_rman in crontab-daemon 21 第5章 执行备份 5 第 章 执行备份 本小节主要介绍 sys_rman 支持的每一种备份实际操作，有助于对备份的实践作了解，帮助需要手动执行备份的 用户。 本部分包含以下章节： • 全量备份 • 差异备份 • 增量备份（块粒度） • 增量备份（文件粒度） 5.1 全量备份 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --log-level-console=info --archive-copy --type=full backup 2023-07-04 02:14:08.966 P00 INFO: backup command begin 2.27: --archive-copy --no-archive-statistics -- archive-timeout=600 --band-width=0 --compress-level=3 --compress-type=none --config=/home/kingbase/kbbr_ repo/sys_rman.conf --exec-id=2039-589e6e59 --kb1-path=/opt/Kingbase/ES/V9/Server/data --kb1-port=57321 -kb1-user=system --lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/ Kingbase/ES/V9/Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/ kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase --start-fast --type=full 2023-07-04 02:14:09.001 P00 INFO: Get pageCheckSum flag from ControlFile is 1 2023-07-04 02:14:09.002 P00 INFO: Check the non archvied WAL space under the setting 1024 MB 2023-07-04 02:14:09.002 P00 INFO: Non archived WAL files have 0 MB. 2023-07-04 02:14:09.002 P00 INFO: execute non-exclusive sys_start_backup(): backup begins after the requested immediate checkpoint completes 2023-07-04 02:14:09.151 P00 INFO: backup start archive = 00000001000000000000000F, lsn = 0/F000028 2023-07-04 02:14:09.151 P00 INFO: check archive for prior segment 00000001000000000000000E 2023-07-04 02:14:10.124 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12559/1249 (1.2MB, 1%) checksum a334f27168403767447f96ad08c6abe761cab7cc 22 第5章 2023-07-04 02:14:10.125 P02 执行备份 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12558/1249 (1.2MB, 3%) checksum d6b538bad3e564a45c01d32a6e4dddc84b052bd8 .......... .......... 2023-07-04 02:14:30.492 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/.wallet/userkey.kr (0B, 100 %) 2023-07-04 02:14:30.493 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/1/1177 (0B, 100%) 2023-07-04 02:14:30.493 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/.wallet/tbcolkey.kr (0B, 100 %) 2023-07-04 02:14:30.594 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/.wallet/tspkey.kr (0B, 100%) 2023-07-04 02:14:30.694 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/.wallet/method.md (0B, 100%) 2023-07-04 02:14:30.697 P00 INFO: execute non-exclusive sys_stop_backup() and wait for all WAL segments to archive 2023-07-04 02:14:31.320 P00 INFO: backup stop archive = 00000001000000000000000F, lsn = 0/F000128 2023-07-04 02:14:31.331 P00 INFO: check archive for segment(s) 00000001000000000000000F: 00000001000000000000000F 2023-07-04 02:14:32.328 P00 INFO: new backup label = 20230704-021409F 2023-07-04 02:14:32.372 P00 INFO: full backup size = 86.9MB, file total = 2317 2023-07-04 02:14:32.373 P00 INFO: backup command end: completed successfully (23413ms) 2023-07-04 02:14:32.373 P00 INFO: expire command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=2039-589e6e59 --lock-path=/tmp/sys_rman --log-levelconsole=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --process-max=2 --repo1-path=/ home/kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase 2023-07-04 02:14:32.376 P00 5.2 INFO: expire command end: completed successfully (3ms) 差异备份 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --log-level-console=info --archive-copy --type=diff backup 2023-07-04 02:17:28.791 P00 INFO: backup command begin 2.27: --archive-copy --no-archive-statistics -- archive-timeout=600 --band-width=0 --compress-level=3 --compress-type=none --config=/home/kingbase/kbbr_ repo/sys_rman.conf --exec-id=2468-a15d79a0 --kb1-path=/opt/Kingbase/ES/V9/Server/data --kb1-port=57321 -kb1-user=system --lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/ Kingbase/ES/V9/Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/ kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase --start-fast --type=diff 2023-07-04 02:17:28.907 P00 INFO: Get pageCheckSum flag from ControlFile is 1 2023-07-04 02:17:28.933 P00 INFO: last backup label = 20230704-021409F, version = 2.27 2023-07-04 02:17:28.933 P00 INFO: Check the non archvied WAL space under the setting 1024 MB 2023-07-04 02:17:28.933 P00 INFO: Non archived WAL files have 0 MB. 2023-07-04 02:17:28.933 P00 INFO: execute non-exclusive sys_start_backup(): backup begins after the requested immediate checkpoint completes 23 第5章 执行备份 2023-07-04 02:17:30.315 P00 INFO: backup start archive = 000000010000000000000016, lsn = 0/160243A0 2023-07-04 02:17:30.315 P00 INFO: check archive for prior segment 000000010000000000000015 2023-07-04 02:17:31.581 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/16386 (16MB, 31%) checksum de346b05fbac844177766d9c1c6c49ef105a2834 2023-07-04 02:17:31.595 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/16392 (24.9MB, 80 %) checksum 4e2da0b6248299bd0e44fe295e26bb33c6b74c64 .......... .......... 2023-07-04 02:17:32.421 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/1249_vm (8KB, 99 %) checksum 1077ba9449afe299f4285cf598bd6c1e152c067b 2023-07-04 02:17:32.421 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/1247_vm (8KB, 100 %) checksum 165dcb255430b91367e05ad41d7af6bd79476227 2023-07-04 02:17:32.522 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/sys_logical/replorigin_ checkpoint (8B, 100%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532 2023-07-04 02:17:32.526 P00 INFO: execute non-exclusive sys_stop_backup() and wait for all WAL segments to archive 2023-07-04 02:17:32.755 P00 INFO: backup stop archive = 000000010000000000000018, lsn = 0/1827EB30 2023-07-04 02:17:32.882 P00 INFO: check archive for segment(s) 000000010000000000000016: 000000010000000000000018 2023-07-04 02:17:33.866 P00 INFO: new backup label = 20230704-021409F_20230704-021728D 2023-07-04 02:17:33.996 P00 INFO: diff backup size = 98.7MB, file total = 2324 2023-07-04 02:17:33.996 P00 INFO: backup command end: completed successfully (5215ms) 2023-07-04 02:17:33.996 P00 INFO: expire command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=2468-a15d79a0 --lock-path=/tmp/sys_rman --log-levelconsole=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --process-max=2 --repo1-path=/ home/kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase 2023-07-04 02:17:34.004 P00 5.3 INFO: expire command end: completed successfully (8ms) 增量备份（块粒度） $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/opt/Kingbase/ES/V9/Server/kbbr_repo/sys_rman.conf -stanza=kingbase --log-level-console=info --archive-copy --type=page backup 2023-07-04 22:15:08.697 P00 INFO: backup command begin 2.27: --archive-copy --no-archive-statistics -- archive-timeout=600 --band-width=0 --compress-level=3 --compress-type=none --config=/home/kingbase/kbbr_ repo/sys_rman.conf --exec-id=2774-6bb3a624 --kb1-path=/opt/Kingbase/ES/V9/Server/data --kb1-port=57321 -kb1-user=system --lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/ Kingbase/ES/V9/Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/ kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase --start-fast --type=page 2023-07-04 22:15:08.737 P00 INFO: Get pageCheckSum flag from ControlFile is 1 2023-07-04 22:15:08.748 P00 INFO: try to get ktrack's basic info [select extnamespace::regnamespace::text, extversion from pg_catalog.pg_extension where extname='ktrack'] 2023-07-04 22:15:08.836 P00 INFO: try to get ktrack's init lsn [select ktrack_init_lsn::text from public. ktrack_init_lsn()] 24 第5章 2023-07-04 22:15:08.895 P00 执行备份 INFO: ktrack extension (version [2.2]) is in [public] schema, init from LSN [0/2D000028] 2023-07-04 22:15:08.922 P00 INFO: last backup label = 20230704-221236F, version = 2.27 2023-07-04 22:15:08.937 P00 INFO: Check the non archvied WAL space under the setting 1024 MB 2023-07-04 22:15:08.937 P00 INFO: Non archived WAL files have 0 MB. 2023-07-04 22:15:08.937 P00 INFO: execute non-exclusive sys_start_backup(): backup begins after the requested immediate checkpoint completes 2023-07-04 22:15:16.394 P00 INFO: backup start archive = 000000010000000000000047, lsn = 0/47000028 2023-07-04 22:15:16.394 P00 INFO: check archive for prior segment 000000010000000000000046 2023-07-04 22:15:17.000 P00 INFO: try to get pagemapset [select path, pagecount, pagemap from public. ktrack_get_pagemapset('0/43000028'::pg_lsn) order by 1] 2023-07-04 22:15:17.093 P00 INFO: ktrack reports [0] relation files have changed 2023-07-04 22:15:17.181 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/sys_xact/0000 (256KB, 0%) checksum 6460bafb0001d94ba1fd3b6fb073639bce1e551e .......... .......... 2023-07-04 22:15:17.312 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/sys_logical/replorigin_ checkpoint (8B, 0%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532 2023-07-04 22:15:26.871 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/global/ktrack.map (1024.0MB, 100%) checksum a97dc2863dd0065c408fcae0d86da98ae0db25d6 2023-07-04 22:15:28.341 P00 INFO: execute non-exclusive sys_stop_backup() and wait for all WAL segments to archive 2023-07-04 22:15:28.951 P00 INFO: backup stop archive = 000000010000000000000047, lsn = 0/47000128 2023-07-04 22:15:28.953 P00 INFO: check archive for segment(s) 000000010000000000000047: 000000010000000000000047 2023-07-04 22:15:29.575 P00 INFO: new backup label = 20230704-221236F_20230704-221508I 2023-07-04 22:15:29.904 P00 INFO: page backup size = 1GB, file total = 2367 2023-07-04 22:15:29.905 P00 INFO: backup command end: completed successfully (21214ms) 2023-07-04 22:15:29.905 P00 INFO: expire command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=2774-6bb3a624 --lock-path=/tmp/sys_rman --log-levelconsole=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --process-max=2 --repo1-path=/ home/kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase 2023-07-04 22:15:29.908 P00 5.4 INFO: expire command end: completed successfully (3ms) 增量备份（文件粒度） $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --log-level-console=info --archive-copy --type=incr backup 2023-07-04 02:24:59.158 P00 INFO: backup command begin 2.27: --archive-copy --no-archive-statistics -- archive-timeout=600 --band-width=0 --compress-level=3 --compress-type=none --config=/home/kingbase/kbbr_ repo/sys_rman.conf --exec-id=3410-58920339 --kb1-path=/opt/Kingbase/ES/V9/Server/data --kb1-port=57321 -kb1-user=system --lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/ Kingbase/ES/V9/Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/ kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase --start-fast --type=incr 25 第5章 执行备份 2023-07-04 02:24:59.192 P00 INFO: Get pageCheckSum flag from ControlFile is 1 2023-07-04 02:24:59.213 P00 INFO: last backup label = 20230704-022317F, version = 2.27 2023-07-04 02:24:59.213 P00 INFO: Check the non archvied WAL space under the setting 1024 MB 2023-07-04 02:24:59.214 P00 INFO: Non archived WAL files have 0 MB. 2023-07-04 02:24:59.214 P00 INFO: execute non-exclusive sys_start_backup(): backup begins after the requested immediate checkpoint completes 2023-07-04 02:25:12.668 P00 INFO: backup start archive = 000000010000000000000032, lsn = 0/32000028 2023-07-04 02:25:12.668 P00 INFO: check archive for prior segment 000000010000000000000031 2023-07-04 02:25:13.403 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/1249 (1.2MB, 0%) checksum d2e497e4506e3a91c2ef3d43ec09ce9e2618d7ac .......... .......... 2023-07-04 02:25:14.489 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/1255_vm (8KB, 0%) checksum 70c24a1244b776b36426d886c009dad3ae374316 2023-07-04 02:25:14.491 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/1247_vm (8KB, 0%) checksum 323c04573f9906eca4410b3bc194a611c634cf26 2023-07-04 02:25:14.492 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/sys_logical/replorigin_ checkpoint (8B, 0%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532 2023-07-04 02:25:14.493 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/16454 (0B, 0%) 2023-07-04 02:25:14.595 P02 INFO: backup file /opt/Kingbase/ES/V9/Server/data/base/12557/16450 (0B, 0%) 2023-07-04 02:25:22.254 P01 INFO: backup file /opt/Kingbase/ES/V9/Server/data/global/ktrack.map (1024.0MB, 100%) checksum ff7122ec05718b01fe6bb6f523706ace8dcf8ae6 2023-07-04 02:25:23.055 P00 INFO: execute non-exclusive sys_stop_backup() and wait for all WAL segments to archive 2023-07-04 02:25:23.248 P00 INFO: backup stop archive = 000000010000000000000032, lsn = 0/320011A0 2023-07-04 02:25:23.249 P00 INFO: check archive for segment(s) 000000010000000000000032: 000000010000000000000032 2023-07-04 02:25:23.642 P00 INFO: new backup label = 20230704-022317F_20230704-022459I 2023-07-04 02:25:23.776 P00 INFO: incr backup size = 1GB, file total = 2348 2023-07-04 02:25:23.777 P00 INFO: backup command end: completed successfully (24623ms) 2023-07-04 02:25:23.777 P00 INFO: expire command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=3410-58920339 --lock-path=/tmp/sys_rman --log-levelconsole=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --process-max=2 --repo1-path=/ home/kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase 2023-07-04 02:25:23.780 P00 INFO: expire command end: completed successfully (3ms) 26 第 6 章 物理备份相关的其他操作 6 第 章 物理备份相关的其他操作 本部分包含以下章节： • 查看已有备份集 • 清除过期的备份 • 备份集检查 • 性能优化-并行处理 • 性能优化-压缩优化 6.1 查看已有备份集 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase info stanza: kingbase status: ok cipher: none db (current) wal archive min/max (V008R006B0605): 000000010000000000000035/00000001000000000000003F full backup: 20230704-023130F timestamp start/stop: 2023-07-04 02:31:30 / 2023-07-04 02:32:15 wal start/stop: 000000010000000000000037 / 000000010000000000000038 database size: 1.3GB, database backup size: 1.3GB repo1: backup set size: 1.3GB, backup size: 1.3GB diff backup: 20230704-023130F_20230704-023220D timestamp start/stop: 2023-07-04 02:32:20 / 2023-07-04 02:32:37 wal start/stop: 00000001000000000000003A / 00000001000000000000003A database size: 1.3GB, database backup size: 1GB 27 第 6 章 物理备份相关的其他操作 repo1: backup set size: 1.3GB, backup size: 1GB backup reference list: 20230704-023130F incr backup: 20230704-023130F_20230704-023311I timestamp start/stop: 2023-07-04 02:33:11 / 2023-07-04 02:33:28 wal start/stop: 00000001000000000000003C / 00000001000000000000003C database size: 1.3GB, database backup size: 1GB repo1: backup set size: 1.3GB, backup size: 1GB backup reference list: 20230704-023130F page backup: 20230704-023130F_20230704-023432I timestamp start/stop: 2023-07-04 02:34:32 / 2023-07-04 02:34:47 wal start/stop: 00000001000000000000003F / 00000001000000000000003F database size: 1.3GB, database backup size: 1GB repo1: backup set size: 1.3GB, backup size: 1GB backup reference list: 20230704-023130F 6.2 清除过期的备份 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --log-level-console=info expire 2023-07-04 02:37:47.516 P00 INFO: expire command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=4615-2223862d --lock-path=/tmp/sys_rman --log-levelconsole=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --process-max=4 --repo1-path=/ home/kingbase/kbbr_repo --repo1-retention-full=5 --stanza=kingbase 2023-07-04 02:37:47.522 P00 6.3 INFO: expire command end: completed successfully (11ms) 备份集检查 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase verify 2023-07-04 02:38:22.791 P00 INFO: verify command begin 2.27: --no-archive-statistics --band-width=0 -- config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=4674-314b95f6 --log-level-console=info --log-levelfile=info --log-path=/opt/Kingbase/ES/V9/Server/log --log-subprocess --non-archived-space=1024 --processmax=4 --repo1-path=/home/kingbase/kbbr_repo --stanza=kingbase 2023-07-04 02:39:20.687 P00 INFO: Results: archive_id: 12-1, total WAL checked: 11, total valid WAL: 11 missing: 0, checksum invalid: 0, size invalid: 0, other: 0 backup: 20230704-023130F, status: valid, total files checked: 2364, total valid files: 2364 28 第 6 章 物理备份相关的其他操作 missing: 0, checksum invalid: 0, size invalid: 0, other: 0 backup: 20230704-023130F_20230704-023220D, status: valid, total files checked: 2363, total valid files: 2363 missing: 0, checksum invalid: 0, size invalid: 0, other: 0 backup: 20230704-023130F_20230704-023311I, status: valid, total files checked: 2363, total valid files: 2363 missing: 0, checksum invalid: 0, size invalid: 0, other: 0 backup: 20230704-023130F_20230704-023432I, status: valid, total files checked: 2364, total valid files: 2364 missing: 0, checksum invalid: 0, size invalid: 0, other: 0 2023-07-04 02:39:20.688 P00 6.4 INFO: verify command end: completed successfully (57902ms) 性能优化-并行处理 可设置备份、还原时并行处理的并发进程数量，如无特殊需求，保持默认即可，详细的配置方法详见《KingbaseES 物理备份恢复工具手册》。 6.5 性能优化-压缩优化 可设置备份文件实际存储时压缩算法和压缩级别，如无特殊需求，保持默认即可，详细的配置方法详见《KingbaseES 物理备份恢复工具手册》。 29 第7章 执行还原 7 第 章 执行还原 在执行还原之前，需要确定恢复目标点，尤其是要确定是否需要添加时间线参数限制，另外还原操作的其他说明 如下所示： 还原操作特点说明： • 还原时，只能在数据库节点上进行。 • 还原完成数据库进入正常状态后，请及时手动清空 kingbase.auto.conf 文件内容。 • 若是集群环境，做还原的数据库节点将作为集群的主节点，利用该节点重做备机（请参考《金仓数据守护集群 和读写分离集群使用手册》）。拉起集群后，可选择新的主节点。 • 还原时，需要确保 kingbase 进程已经停止。 • 还原时，KB_DATA 目录本身不存在将由本工具创建。 • 还原时，KB_DATA 目录下 如果还有文件存在，需要--delta 选项进行选择性还原。 • 还原时，KB_DATA 目录下如果没有文件存在，默认以下的还原模式均可使用。 • 还原成功之后，应该尽快进行一次全量备份。 • 还原所采用的数据库配置文件为指定（或默认最接近还原目标的）备份集中的配置文件，例如在备份集 1 生成 后将 kingbase.conf 中的 max_connections 由 100 改为 200，之后生成新备份集，还原时指定使用备份集 1 还原 到新备份集后的时刻（或 XID 等），还原后的 max_connections 为备份集 1 中的 100。 本部分包含以下章节： • 停止数据库服务 • 最新备份文件还原 • 指定备份集还原 • 指定事务 ID 还原 • 指定时间点还原 • 表空间支持 • 集群还原 30 第7章 执行还原 • 备机还原 • 还原后节点处理 7.1 停止数据库服务 停止单机服务的示例： $ /opt/Kingbase/ES/V9/Server/bin/sys_ctl -D /opt/Kingbase/ES/V9/Server/data stop waiting for server to shut down........... done server stopped 停止集群服务的示例： $ /home/kingbase/cluster/install/kingbase/bin/sys_monitor.sh stop 2023-07-04 15:59:16 Ready to stop all DB ... 2023-07-04 15:59:20 begin to stop repmgrd on "[192.168.45.152]". 2023-07-04 15:59:21 repmgrd on "[192.168.45.152]" already stopped. 2023-07-04 15:59:21 begin to stop repmgrd on "[192.168.45.197]". 2023-07-04 15:59:22 repmgrd on "[192.168.45.197]" already stopped. 2023-07-04 15:59:22 begin to stop DB on "[192.168.45.197]". waiting for server to shut down.... done server stopped 2023-07-04 15:59:23 DB on "[192.168.45.197]" stop success. 2023-07-04 15:59:23 begin to stop DB on "[192.168.45.152]". waiting for server to shut down.... done server stopped 2023-07-04 15:59:24 DB on "[192.168.45.152]" stop success. 2023-07-04 15:59:24 Done. 7.2 最新备份文件还原 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --delta restore 2023-07-04 10:29:35.010 P00 INFO: restore command begin 2.27: --band-width=0 --config=/home/kingbase/kbbr_ repo/sys_rman.conf --delta --exec-id=394476-4ab30268 --kb1-path=/opt/Kingbase/ES/V9/Server/data --link-all -lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/ Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --stanza=kingbase 2023-07-04 10:29:35.042 P00 INFO: repo1: restore backup set 20230628-171503F, recovery will start at 2023- 06-28 17:15:03 2023-07-04 10:29:35.045 P00 INFO: remove invalid files/links/paths from '/opt/Kingbase/ES/V9/Server/data' 31 第7章 2023-07-04 10:29:35.253 P00 执行还原 INFO: Restore Process: FILE: 1 / 2302 0% SZIE: 2195456 bytes / 161069195 INFO: Restore Process: FILE: 2 / 2302 0% SZIE: 4390912 bytes / 161069195 INFO: Restore Process: FILE: 3 / 2302 0% SZIE: 6586368 bytes / 161069195 bytes 2MB / 153.6MB 1% 2023-07-04 10:29:35.264 P00 bytes 4.2MB / 153.6MB 2% 2023-07-04 10:29:35.329 P00 bytes 6.3MB / 153.6MB 4% .......... .......... 2023-07-04 10:29:47.307 P00 INFO: Restore Process: FILE: 2300 / 2302 99% SZIE: 161069192 bytes / 161069195 bytes 153.6MB / 153.6MB 99% 2023-07-04 10:29:47.307 P00 INFO: Restore Process: FILE: 2301 / 2302 99% SZIE: 161069195 bytes / 161069195 bytes 153.6MB / 153.6MB 100% 2023-07-04 10:29:47.307 P00 INFO: Restore Process: FILE: 2302 / 2302 100% SZIE: 161069195 bytes / 161069195 bytes 153.6MB / 153.6MB 100% 2023-07-04 10:29:47.307 P00 INFO: write updated /opt/Kingbase/ES/V9/Server/data/kingbase.auto.conf 2023-07-04 10:29:47.341 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2023-07-04 10:29:47.341 P00 INFO: restore size = 153.6MB, file total = 2302 2023-07-04 10:29:47.342 P00 INFO: restore command end: completed successfully (12336ms) 7.3 指定备份集还原 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --set='20230704-104206F_20230704-104229D' --delta restore 2023-07-04 11:03:19.722 P00 INFO: restore command begin 2.27: --band-width=0 --config=/home/kingbase/kbbr_ repo/sys_rman.conf --delta --exec-id=426334-f60d8ec6 --kb1-path=/opt/Kingbase/ES/V9/Server/data --link-all -lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/ Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --set=20230704-104206F_20230704-104229D --stanza=kingbase WARN: sys_rman auto set target time to backupset stop time 2023-07-04 10:42:32 2023-07-04 11:03:19.741 P00 INFO: repo1: restore backup set 20230704-104206F_20230704-104229D, recovery will start at 2023-07-04 10:42:29 2023-07-04 11:03:19.748 P00 INFO: remove invalid files/links/paths from '/opt/Kingbase/ES/V9/Server/data' 2023-07-04 11:03:19.893 P00 INFO: Restore Process: FILE: 1 / 2296 0% SZIE: 2195456 bytes / 161042923 INFO: Restore Process: FILE: 2 / 2296 0% SZIE: 4390912 bytes / 161042923 bytes 2MB / 153.6MB 1% 2023-07-04 11:03:19.893 P00 bytes 4.2MB / 153.6MB 2% .......... .......... 2023-07-04 11:03:20.381 P00 INFO: Restore Process: FILE: 2294 / 2296 99% SZIE: 161042923 bytes / 161042923 bytes 153.6MB / 153.6MB 100% 2023-07-04 11:03:20.581 P00 INFO: Restore Process: FILE: 2295 / 2296 99% SZIE: 161042923 bytes / 161042923 bytes 153.6MB / 153.6MB 100% 32 第7章 2023-07-04 11:03:20.581 P00 INFO: Restore Process: FILE: 2296 / 2296 100% 执行还原 SZIE: 161042923 bytes / 161042923 bytes 153.6MB / 153.6MB 100% 2023-07-04 11:03:20.581 P00 INFO: write updated /opt/Kingbase/ES/V9/Server/data/kingbase.auto.conf 2023-07-04 11:03:20.605 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2023-07-04 11:03:20.605 P00 INFO: restore size = 153.6MB, file total = 2296 2023-07-04 11:03:20.606 P00 INFO: restore command end: completed successfully (886ms) 7.4 指定事务 ID 还原 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --type=xid --target='1060' --set='20230704-111905F_20230704-112235D' --delta restore 2023-07-04 11:26:51.376 P00 INFO: restore command begin 2.27: --band-width=0 --config=/home/kingbase/kbbr_ repo/sys_rman.conf --delta --exec-id=125177-193d984b --kb1-path=/opt/Kingbase/ES/V9/Server/data --link-all -lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/ Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --set=20230704-111905F_20230704-112235D --stanza=kingbase --target=1060 --type=xid 2023-07-04 11:26:51.395 P00 INFO: repo1: restore backup set 20230704-111905F_20230704-112235D, recovery will start at 2023-07-04 11:22:35 2023-07-04 11:26:51.436 P00 INFO: remove invalid files/links/paths from '/opt/Kingbase/ES/V9/Server/data' 2023-07-04 11:26:51.702 P00 INFO: Restore Process: FILE: 1 / 2301 0% SZIE: 5636096 bytes / 221700852 INFO: Restore Process: FILE: 2 / 2301 0% SZIE: 7831552 bytes / 221700852 INFO: Restore Process: FILE: 3 / 2301 0% SZIE: 10027008 bytes / bytes 5.4MB / 211.4MB 2% 2023-07-04 11:26:51.705 P00 bytes 7.5MB / 211.4MB 3% 2023-07-04 11:26:51.708 P00 221700852 bytes 9.6MB / 211.4MB 4% .......... .......... 2023-07-04 11:26:52.806 P00 INFO: Restore Process: FILE: 2299 / 2301 99% SZIE: 221700852 bytes / 221700852 bytes 211.4MB / 211.4MB 100% 2023-07-04 11:26:52.806 P00 INFO: Restore Process: FILE: 2300 / 2301 99% SZIE: 221700852 bytes / 221700852 bytes 211.4MB / 211.4MB 100% 2023-07-04 11:26:52.906 P00 INFO: Restore Process: FILE: 2301 / 2301 100% SZIE: 221700852 bytes / 221700852 bytes 211.4MB / 211.4MB 100% 2023-07-04 11:26:52.906 P00 INFO: write updated /opt/Kingbase/ES/V9/Server/data/kingbase.auto.conf 2023-07-04 11:26:53.756 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2023-07-04 11:26:53.759 P00 INFO: restore size = 211.4MB, file total = 2301 2023-07-04 11:26:53.760 P00 INFO: restore command end: completed successfully (2387ms) 33 第7章 7.5 执行还原 指定时间点还原 $ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config=/home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase --type=time --target='2023-07-04 10:42:29' --delta restore 2023-07-04 10:59:27.852 P00 INFO: restore command begin 2.27: --band-width=0 --config=/home/kingbase/kbbr_ repo/sys_rman.conf --delta --exec-id=349746-8b57b6a2 --kb1-path=/opt/Kingbase/ES/V9/Server/data --link-all -lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/ Server/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --stanza=kingbase --target="2023-07-04 10:42:29" --type=time 2023-07-04 10:59:27.868 P00 INFO: repo1: restore backup set 20230704-104206F, recovery will start at 2023- 07-04 10:42:06 2023-07-04 10:59:27.886 P00 INFO: remove invalid files/links/paths from '/opt/Kingbase/ES/V9/Server/data' 2023-07-04 10:59:28.031 P00 INFO: Restore Process: FILE: 1 / 2297 0% SZIE: 2195456 bytes / 177817466 INFO: Restore Process: FILE: 2 / 2297 0% SZIE: 4390912 bytes / 177817466 INFO: Restore Process: FILE: 3 / 2297 0% SZIE: 6586368 bytes / 177817466 INFO: Restore Process: FILE: 4 / 2297 0% SZIE: 8781824 bytes / 177817466 bytes 2MB / 169.6MB 1% 2023-07-04 10:59:28.031 P00 bytes 4.2MB / 169.6MB 2% 2023-07-04 10:59:28.034 P00 bytes 6.3MB / 169.6MB 3% 2023-07-04 10:59:28.034 P00 bytes 8.4MB / 169.6MB 4% .......... .......... 2023-07-04 10:59:28.672 P00 INFO: Restore Process: FILE: 2294 / 2297 99% SZIE: 177817466 bytes / 177817466 bytes 169.6MB / 169.6MB 100% 2023-07-04 10:59:28.973 P00 INFO: Restore Process: FILE: 2295 / 2297 99% SZIE: 177817466 bytes / 177817466 bytes 169.6MB / 169.6MB 100% 2023-07-04 10:59:28.973 P00 INFO: Restore Process: FILE: 2296 / 2297 99% SZIE: 177817466 bytes / 177817466 bytes 169.6MB / 169.6MB 100% 2023-07-04 10:59:28.973 P00 INFO: Restore Process: FILE: 2297 / 2297 100% SZIE: 177817466 bytes / 177817466 bytes 169.6MB / 169.6MB 100% 2023-07-04 10:59:28.974 P00 INFO: write updated /opt/Kingbase/ES/V9/Server/data/kingbase.auto.conf 2023-07-04 10:59:28.980 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2023-07-04 10:59:28.980 P00 INFO: restore size = 169.6MB, file total = 2297 2023-07-04 10:59:28.981 P00 INFO: restore command end: completed successfully (1132ms) 7.6 表空间支持 备份时，表空间是默认地、隐式地包含在备份文件集中。具体操作可参考《KingbaseES 备份与恢复工具手 册》。 34 第7章 7.7 执行还原 备机还原 若只是集群中的某个备机出现问题或者已经完成主节点的恢复，使用 repmgr standby clone 命令从主节点恢复备 机即可，具体请参考《金仓数据守护集群和读写分离集群使用手册》。 $ /home/kingbase/cluster/install/kingbase/bin/repmgr -h 192.168.45.152 -U esrep -d esrep -p 54321 standby clone -F --fast-checkpoint [NOTICE] destination directory "/home/kingbase/cluster/install/kingbase/data" provided [INFO] connecting to source node [DETAIL] connection string is: host=192.168.45.152 user=esrep port=54321 dbname=esrep [DETAIL] current installation size is 156 MB [NOTICE] checking for available walsenders on the source node (2 required) [NOTICE] checking replication connections can be made to the source server (2 required) [WARNING] directory "/home/kingbase/cluster/install/kingbase/data" exists but is not empty [NOTICE] -F/--isForce provided - deleting existing data directory "/home/kingbase/cluster/install/kingbase/ data" [INFO] creating replication slot as user "esrep" [NOTICE] starting backup (using sys_basebackup)... [INFO] executing: /home/kingbase/cluster/install/kingbase/bin/sys_basebackup -l "repmgr base backup" -D /home/kingbase/ cluster/install/kingbase/data -h 192.168.45.152 -p 54321 -U esrep -c fast -X stream -S repmgr_slot_2 [NOTICE] standby clone (using sys_basebackup) complete [NOTICE] you can now start your Kingbase server [HINT] for example: sys_ctl -D /home/kingbase/cluster/install/kingbase/data start [HINT] after starting the server, you need to re-register this standby with "repmgr standby register --force " to update the existing node record 7.8 集群还原 集群的恢复首先需要停止集群服务，然后参照下方例子利用 sys_rman 恢复主节点，再利用 repmgr 进行备机还 原，恢复备节点。 $ /home/kingbase/cluster/install/kingbase/bin/sys_rman --config=/home/kingbase/cluster/install/kingbase/ kbbr_repo/sys_rman.conf --stanza=kingbase --delta restore 2023-07-04 19:40:38.355 P00 INFO: restore command begin 2.27: --band-width=0 --config=/home/kingbase/ cluster/install/kingbase/kbbr_repo/sys_rman.conf --delta --exec-id=5251-096280d9 --kb2-host=192.168.45.197 -kb1-path=/home/kingbase/cluster/install/kingbase/data --kb2-path=/home/kingbase/cluster/install/kingbase/ data --link-all --lock-path=/tmp/sys_rman --log-level-console=info --log-level-file=info --log-path=/home/ kingbase/cluster/install/kingbase/log --log-subprocess --non-archived-space=1024 --process-max=4 --repo1path=/home/kingbase/cluster/install/kingbase/kbbr_repo --stanza=kingbase 2023-07-04 19:40:38.380 P00 INFO: repo1: restore backup set 20230704-193515F, recovery will start at 2023- 07-04 19:35:15 2023-07-04 19:40:38.380 P00 INFO: remove invalid files/links/paths from '/home/kingbase/cluster/install/ kingbase/data' 35 第7章 2023-07-04 19:40:38.644 P00 执行还原 INFO: Restore Process: FILE: 1 / 2769 0% SZIE: 1802240 bytes / 205336055 INFO: Restore Process: FILE: 3 / 2769 0% SZIE: 5406720 bytes / 205336055 bytes 1.7MB / 195.8MB 0% 2023-07-04 19:40:38.654 P00 bytes 5.2MB / 195.8MB 2% .......... .......... 2023-07-04 19:40:39.600 P00 INFO: Restore Process: FILE: 2768 / 2769 99% SZIE: 205336055 bytes / 205336055 bytes 195.8MB / 195.8MB 100% 2023-07-04 19:40:39.600 P00 INFO: Restore Process: FILE: 2769 / 2769 100% SZIE: 205336055 bytes / 205336055 bytes 195.8MB / 195.8MB 100% 2023-07-04 19:40:39.601 P00 INFO: write updated /home/kingbase/cluster/install/kingbase/data/kingbase. auto.conf 2023-07-04 19:40:39.604 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2023-07-04 19:40:39.605 P00 INFO: restore size = 195.8MB, file total = 2769 2023-07-04 19:40:39.606 P00 INFO: restore command end: completed successfully (1256ms) 集群还原后，确认数据是否符合预期，观察应用或手动的数据操作是否同步到备节点以验证集群还原是否成功。 7.9 还原后节点处理 可参考《KingbaseES 备份与恢复工具手册》，最后启动数据库服务： 单机启动示例： $ /opt/Kingbase/ES/V9/Server/bin/sys_ctl -D /opt/Kingbase/ES/V9/data start waiting for server to start....2023-07-04 17:14:13.066 CST [6091] LOG: 2023-07-04 17:14:13.070 CST [6091] LOG: sepapower extension initialized starting KingbaseES V008R006 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit 2023-07-04 17:14:13.072 CST [6091] LOG: listening on IPv4 address "0.0.0.0", port 54321 2023-07-04 17:14:13.072 CST [6091] LOG: listening on IPv6 address "::", port 54321 2023-07-04 17:14:13.079 CST [6091] LOG: listening on Unix socket "/tmp/.s.KINGBASE.54321" 2023-07-04 17:14:13.278 CST [6091] LOG: redirecting log output to logging collector process 2023-07-04 17:14:13.278 CST [6091] HINT: Future log output will appear in directory "sys_log". done server started 集群启动示例： $ /home/kingbase/cluster/install/kingbase/bin/sys_monitor.sh start 2023-07-04 19:55:12 Ready to start all DB ... 2023-07-04 19:55:12 begin to start DB on "[192.168.45.152]". waiting for server to start.... done server started 36 第7章 执行还原 2023-07-04 19:55:13 execute to start DB on "[192.168.45.152]" success, connect to check it. 2023-07-04 19:55:14 DB on "[192.168.45.152]" start success. 2023-07-04 19:55:14 Try to ping trusted_servers on host 192.168.45.152 ... 2023-07-04 19:55:16 Try to ping trusted_servers on host 192.168.45.197 ... 2023-07-04 19:55:19 begin to start DB on "[192.168.45.197]". waiting for server to start.... done server started 2023-07-04 19:55:20 execute to start DB on "[192.168.45.197]" success, connect to check it. 2023-07-04 19:55:22 DB on "[192.168.45.197]" start success. ID | Name | Role | Status | Upstream | Location | Priority | Timeline | LSN_Lag | Connection string ----+-------+---------+-----------+----------+----------+----------+----------+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------1 | node1 | primary | * running | | default | 100 | 1 | | host=192.168.45. 152 user=esrep dbname=esrep port=54321 connect_timeout=10 keepalives=1 keepalives_idle=2 keepalives_ interval=2 keepalives_count=3 tcp_user_timeout=9000 2 | node2 | standby | running | node1 | default | 1 | 100 | 0 bytes | host=192.168.45. 197 user=esrep dbname=esrep port=54321 connect_timeout=10 keepalives=1 keepalives_idle=2 keepalives_ interval=2 keepalives_count=3 tcp_user_timeout=9000 2023-07-04 19:55:22 The primary DB is started. 2023-07-04 19:55:22 begin to start repmgrd on "[192.168.45.152]". [2023-07-04 19:55:22] [NOTICE] using provided configuration file "/home/kingbase/cluster/install/kingbase/ bin/../etc/repmgr.conf" [2023-07-04 19:55:22] [NOTICE] redirecting logging output to "/home/kingbase/cluster/install/kingbase/log/ hamgr.log" 2023-07-04 19:55:24 repmgrd on "[192.168.45.152]" start success. 2023-07-04 19:55:24 begin to start repmgrd on "[192.168.45.197]". [2023-07-04 07:55:24] [NOTICE] using provided configuration file "/home/kingbase/cluster/install/kingbase/ bin/../etc/repmgr.conf" [2023-07-04 07:55:24] [NOTICE] redirecting logging output to "/home/kingbase/cluster/install/kingbase/log/ hamgr.log" 2023-07-04 19:55:27 repmgrd on "[192.168.45.197]" start success. ID | Name | Role | Status | Upstream | repmgrd | PID | Paused? | Upstream last seen ----+-------+---------+-----------+----------+---------+-------+---------+-------------------1 | node1 | primary | * running | | running | 10624 | no | n/a 2 | node2 | standby | | running | 19691 | no | 1 second(s) ago running | node1 [2023-07-04 19:55:28] [NOTICE] redirecting logging output to "/home/kingbase/cluster/install/kingbase/log/ kbha.log" [2023-07-04 07:55:32] [NOTICE] redirecting logging output to "/home/kingbase/cluster/install/kingbase/log/ kbha.log" 2023-07-04 19:55:34 Done. 37 第 8 章 特殊场景恢复实践案例 8 第 章 特殊场景恢复实践案例 上一章节介绍了通用的恢复场景，本章将举例说明恢复时可能遇到的问题，并解释特殊场景的恢复问题。 8.1 指定时间点恢复和指定备份集恢复的区别 指定时间点恢复和指定备份集恢复都可以将数据库恢复到同样的某个时刻，指定时间点恢复默认使用距离恢复点 最近的备份集，因此二者使用的备份集可能不同。不同的备份集内的非表文件（比如 kingbase.conf 或 sys_hba.conf 等配置文件、日志文件）就会有差异，尤其是配置文件内参数的差异就会决定数据库恢复结束后的一些行为，比如最 大连接数变了，某个 IP 段不允许访问数据库了。 8.2 无法恢复到最新增量数据 如下图所示，数据库在全量备份 1 之后创建了 T1 表，位置 1 为创建 T1 表之后的时刻，然后又创建了 T2 表， 位置 2 为创建 T2 表之后的时刻，最后开始模拟恢复场景： 1. 首先恢复到 位置 1 ，并且执行了提升节点操作 2. 然后又尝试恢复到 位置 2 ，发现看不见 T2 表 原因是在步骤二恢复时，没有添加 --target-timeline 参数指定要恢复到时间线 1 上，因此默认恢复到了最新 时间线 2 上，所以看不到 T2 表。 38 第 8 章 特殊场景恢复实践案例 8.3 恢复后启动数据库报错 如下图所示，数据库在全量备份 1 之后又做了一次备份为全量备份 2，然后开始模拟恢复场景： 1. 首先恢复到 位置 1 ，并且执行了提升节点操作 2. 然后，通过时间点恢复尝试恢复到时间线 1 上的全量备份 2 之后的 位置 2 ，启动数据库失败 原因是在步骤二的指定时间点恢复时没有指定时间线 1，恢复过程是这样的：首先找到离 位置 2 最近的备份集 为 全量备份 2 ，然后恢复备份集，启动数据库后开始从备份集开始的位置 0/4000028 重放 WAL 日志，默认又使用 最新时间线 2，发现时间线 2 在时间线 1 上的分歧点 0/310DE0 ，0/310DE0 到 0/4000028 这段的日志是不符合时间 线 2 的预期的，因此数据库报错退出。 解决方式就是在步骤二指定时间点恢复时添加时间线 1 的设置。 39 第 8 章 特殊场景恢复实践案例 8.4 恢复后发现查询卡住 如下图所示，指定了删除表 t1 之前的时间点做恢复，恢复后启动数据库查询 t1 表数据卡住，ksql 没有任何查询 输出，但执行 sys_wal_replay_resume() 函数之后，就可以正常查询 t1 表了，数据也是正常的。 40 第 8 章 特殊场景恢复实践案例 8.4.1 原因 受限于 KingbaseES PITR 的机制，PITR 选定的时间，一般都不是事务结束的时间，所以 redo 会继续往后走， 将下一个事务的结束时间和设定的时间进行对比，如果设定时间小于，就停止了，就是目前数据库的状态： 1. 这时候会有 1 个或多个事务处于未提交状态，这些未提交事务可能持有锁（例如 drop table 持有排他锁，本示 例中查询卡住就是因为拿不到 t1 的共享锁），此时执行 sys_wal_replay_resume() 函数将这些事务回滚就可 以了，对恢复无影响 2. 如果刚好卡在下一条事务是 drop database 这种无法回滚的 DDL 操作，就会出现 DDL 语句被直接执行（kingbase 不支持事务内执行 drop database 的操作，无法回滚，比如下一小节提到的问题） 41 第 8 章 特殊场景恢复实践案例 8.4.2 解决方法 1. 尝试更改指定时间点恢复的目标时刻，让恢复后的状态不卡在特殊 SQL 未提交前的状态。 2. 改为指定事务 ID 恢复，事务 ID 是唯一标志，不会往下继续查时间大小，比如本示例改为 xid=928。 8.4.3 复现和定位问题步骤 首先，创建测试表 t1 灌入一些数据，执行全量备份，随便更新一条 t1 表的数据，查询当前时间为 2022-05-20 17:47:06.674379+08 ，删掉 t1 表。 42 第 8 章 特殊场景恢复实践案例 然后，停止数据库，重命名 data 目录，使用上一步中获得的时间执行指定时间点恢复。 /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='2022-05-20 17:47:06.674379+08' [kingbase@localhost V9]$ /opt/Kingbase/ES/V9/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman. conf --stanza=kingbase restore --type=time --target='2022-05-20 17:47:06.674379+08' 2022-05-20 17:54:23.682 P00 INFO: restore command begin 2.27: --band-width=0 --cmd-ssh=/opt/Kingbase/ES/V9/ Server/bin/sys_securecmd --config=/home/kingbase/kbbr_repo/sys_rman.conf --exec-id=3378-40222f80 --link-all --log-level-console=info --log-level-file=info --log-path=/opt/Kingbase/ES/V9/Server/log --log-subprocess -non-archived-space=1024 --kb1-path=/opt/Kingbase/ES/V9/data --process-max=4 --repol-path=/home/kingbase/ kbbr_repo --stanza=kingbase --target="2022-05-20 17:47:06.674379+08" --type=time 2022-05-20 17:54:23.708 P00 INFO: repol: restore backup set 20220520-174531F, recovery will start at 202205-20 17:45:31 2022-05-20 17:54:23.814 P00 INFO: Restore Process: FILE: 1/1756 0% SIZE: 1073152 bytes / 69729678 bytes 1MB / 66.5MB 1% 2022-05-20 17:54:23.839 P00 INFO: Restore Process: FILE: 2/1756 0% SIZE: 2146304 bytes / 69729678 bytes 2MB / 66.5MB 3% 2022-05-20 17:54:23.964 P00 INFO: Restore Process: FILE: 3/1756 0% SIZE: 3219456 bytes / 69729678 bytes 3MB / 66.5MB 4% 2022-05-20 17:54:23.965 P00 INFO: Restore Process. FILE: 4/1756 0% SIZE. 1292608 bytes / 60779678 bytes 4MB / 66.5MB 5% 43 第 8 章 特殊场景恢复实践案例 2022-05-20 17:54:39.493 P00 INFO: Restore Process: FILE: 1754 / 1756 99% SIZE: 69729678 bytes / 69729678 bytes 66.5MB / 66.5M 100% 2022-05-20 17:54:39.694 P00 INFO: Restore Process: FILE: 1755 / 1756 99% SIZE: 69729678 bytes / 69729678 bytes 66.5MB / 66.5M 100% 2022-05-20 17:54:39.694 P00 INFO: Restore Process: FILE: 1756 / 1756 100% SZIE: 69729678 bytes / 69729678 bytes 66.5MB / 66.5M 100% 2022-05-20 17:54:39.695 P00 INF0: write updated /opt/Kingbase/ES/V9/data/kingbase.auto.conf 2022-05-20 17:54:39.713 P00 INFO: restore global/sys_control (performed last to ensure aborted restores cannot be started) 2022-05-20 17:54:39.714 P00 INFO: restore size = 66.5MB, file total = 1756 2022-05-20 17:54:39.714 P00 INFO: restore command end: completed successfully (16043ms) 再然后，启动数据库，查询 t1 表数据，发现卡住。 [kingbasedlocalhost V9]$ /opt/Kingbase/ES/V9/Server/bin/ksql -d test -Usystem ksqL (V9.0) Type "help" for help. WARNING:License file will expire in 29 days. test=# select * from t1 limit 10; 然后，获取查询语句对应的 KingbaseES 后台进程 ID 为 3809 ，使用 pstack 命令获取该进程的调用栈，发现是 在等待锁。 [kingbasealocalhost ~]$ ps -elf | grep "kingbase: system test" 1 S kingbase 3809 3789 0 80 157782 ep_pol 17:58 ? 00:00:00 kingbase: system test [Local] SELECT waiting [kingbasealocalhost ~]$ pstack 3809 #0 0x00007f182f773163 in epoll_wait_nocancel () from /lib64/libc.so.6 #1 0x00000000007cc983 in WaitEventSetWait () #2 0x00000000007cd264 in WaitLatchOrSocket () #3 0x00000000007da535 in ProcSleep () #4 0x00000000007d7d92 in WaitOnLock () #5 0x00000000007d952a in LockAcquireExtended () #6 0x00000000007d57d7 in LockRelation0id () #7 0x000000000055d81a in RangeVarGetRelidExtended () #8 0x00000000004b44a0 in relation_openrv_extended () #9 0x000000000051c499 in table_openrv_extended () #10 0x00000000005c44e4 in parserOpenTable () #11 0x00000000005c5fb4 in addRangeTableEntry () #12 0x00000000005a726c in transformTabLeEntry () #13 0x00000000005a9bac in transformFromClauseItem () #14 0x00000000005ab6c6 in transformFromClause () #15 0x000000000058658e in transformSelectStmt () #16 0x0000000000587b89 in transformStmt () 44 第 8 章 特殊场景恢复实践案例 #17 0x000000000058a7aa in transformTopLevelStmt () #18 0x000000000058a99a in parse_analyze () #19 0x00000000007ed2d7 in pg_analyze_and_rewrite () #20 0x00000000007edd99 in exec_simple_query () #21 0x00000000007f0c60 in PostgresMain () #22 0x000000000077805a in PostmasterMain () #23 0x00000000006c98af in main () 其次，查看数据库日志，发现恢复停在 929 事务（结束时间为 2022-05-20 17:47:14.538044+08 ）提交之前， 最后使用了 000000010000000000000004 做的恢复。 2022-05-20 17:58:07.710 CST [3792] LOG:database system was interrupted; last known up at 2022-05-20 17:45:32 CST 2022-05-20 17:58:07.767 P00 INFO: archive-get command begin 2.27: 0000002.history, sys_ wal/RECOVERYHISTORY] --archive-timeout=600 --cmd-ssh=/opt/Kingbase/ES/V9/Server/bin/sys_securecmd --config=/home/kingbase/kbbr_ repo/sys_rman.conf --exec-id=3793-cdbd404d --log-level-console=info --log-level-file=info --log-path=/opt/ Kingbase/ES/V9/Server/log --log-subprocess --kb1-path=/opt/Kingbase/ES/V9/data --process-max=4 --repo1path=/home/kingbase/kbbr_repo --stanza=kingbase 2022-05-20 17:58:07.770 P00 INFO: unable to find 00000002.history in the archive 2022-05-20 17:58:07.770 P00 INFO: archive-get command end: completed successfully (11ms) 2022-05-20 17:58:07.771 CST [3792] LOG: starting point-in-time recovery to 2022-05-20 17:47:06.674379+08 2022-05-20 17:58:07.780 P00 INFO: archive-get command begin 2.27: [00000000000000000000003, sys_wal/ RECOVERYXL0G] --archive-timeout=600 --cmd-ssh=/opt/Kingbase/ES/V9/Server/bin/sys_securecmd --config=/home/ kingbase/kbbr_repo/sys_rman.conf --exec-id=3796-347d02c1 --1og-level-console=info --log-Level-file=info -log-path=/opt/Kingbase/ES/V9/Server/log --log-subprocess --kb1-path=/opt/Kingbase/ES/V9/data --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --stanza=kingbase 2022-05-20 17:58:07.801 P00 INFO: found 000000000000000000003 in the repol: 12-1 archive 2022-05-20 17:58:07.801 P00 INFO: archive-get command end: completed successfully (26ms) 2022-05-20 17:58:07.803 CST [3792] LOG: restored log file "0000000000000000000003" from archive 2022-05-20 17:58:08.051 CST [3792] LOG: redo starts at 0/3000028 2022-05-20 17:58:08.051 CST [3792] LOG:redo wal segment count 1 2022-05-20 17:58:08.052 CST [3792] LOG:consistent recovery state reached at 0/3000128 2022-05-20 17:58:08.054 CST [3789] LOGdatabase system is ready to accept read only connections 2022-05-20 17:58:08.064 P00 INFO: archive-get command begin 2.27: [000000010000000000000004, sys_wal/ RECOVERYXL0G] --archive-timeout=600 --cmd-ssh=/opt/Kingbase/ES/V9/Server/bin/sys_securecmd --config=/home/ kingbase/kbbr_repo/sys_rman.conf --exec-id=3801-ebe65106 --log-level-console=info --log-level-file=info -log-path=/opt/Kingbase/ES/V9/Server/log --log-subprocess --kb1-path=/opt/Kingbase/ES/V9/data --process-max=4 --repo1-path=/home/kingbase/kbbr_repo --stanza=kingbase 2022-05-20 17:58:08.084 P00 INFO: found 0000000 0000000000000004 in the repol: 12-1 archive 2022-05-20 17:58:08.084 P00 INFO: archive-get command end: completed successfully (26ms) 2022-05-20 17:58:08.085 CST [3792] LOG: restored log file "0000000000000000000004" from archive 2022-05-20 17:58:08.247 CST [3792] LOG: process: 1/1 2022-05-20 17:58:08.249 CST [3792] LOG: recovery stopping before commit of transaction 929, time 2022-05-20 17:47:14.538044+08 2022-05-20 17:58:08.249 CST [3792] LOG: recovery has paused 45 第 8 章 特殊场景恢复实践案例 2022-05-20 17:58:08.249 CST [3792] HINT: Execute pg_wal_replay_resume() to continue. 2022-05-20 18:10:58.835 CST [3809] ERROR: canceling statement due to user request 2022-05-20 18:10:58.835 CST [3809] STATEMENT: select * from t1 limit 10; 然后从 sys_rman 归档目录中拿到数据库恢复的最后一个 wal 日志文件 000000010000000000000004 ，并使用 sys_waldump 输出该文件记录的 wal record，发现了事务 ID 为 929 的事务是 DROP 表操作（已经做了排他锁表操 作，因此查表时无法拿到该表的共享锁）。 [kingbasealocalhost ~]$ mkdir tmp [kingbase@localhost ~]$ cd tmp [kingbase@localhost tmp]$ [kingbase@localhost tmp]$ [kingbase@localhost tmp]$ cp ~/kbbr_repo/archive/kingbase/12-1/000000000000/000000010000000000000004a36704d0dfc04e0e84c9dbd863c97c2791e18285 . [kingbase@localhost tmp]$ mv 000000010000000000000004-a36704d0dfc04e0e84c9dbd863c97c2791e182850000000 000000010000000000000004 [kingbase@localhost tmp]$ /opt/Kingbase/ES/V9/Server/bin/sys_waldump 000000010000000000000004 rmgr: Standby len (rec/tot): 42/ 42, tx: 0, lsn: 0/04000028, prev 0/03000128, desc: RUNNING_ XACTS nextXid 929 latestCompletedXid 50331944 oldestRunningXid 929 rmgr: Standby len (rec/tot): 42/ 42, tx: 929, lsn: 0/04000058, prev 0/04000028, desc: LOCK xid 42/ 42, tx: 929, lsn: 0/04000088, prev 0/04000058, desc: LOCK xid 42/ 42, tx: 929, lsn: 0/040000B8, prev 0/04000088, desc: LOCK xid 929 db 16173 rel 16384 rmgr: Standby len (rec/tot): 929 db 16173 rel 16387 rmgr: Standby len (rec/tot): 929 db 16173 rel 16389 rmgr: Heap len (rec/tot): 59/ 5823, tx: 929, lsn: 0/040000E8, prev 0/040000B8, desc: DELETE off 15 flags 0x00 KEYS_UPDATED，blkref #0: rel 1663/16173/2610 blk 4 FPW rmgr: Heap len (rec/tot): 59/ 7035, tx: 929, lsn: 0/040017A8, prev 0/040000E8, desc: DELETE off 25 flags 0x00 KEYS_UPDATED , blkref #0: rel 1663/ 16173/ 1249 blk 119 FPW rmgr: Heap len (rec/tot): 54/ 54, tx: 929, lsn: 0/0400DEDO, prev 0/0400DE98, desc: DELETE off 14 flags 0x00 KEYS_UPDATED，blkref #0: rel 1663/16173/1249 blk 119 rmgr: Heap len (rec/tot): 54/ 54, tx: 929, lsn: 0/0400DF08, prev 0/0400DEDO, desc: DELETE off 15 flags 0x00 KEYS_UPDATED, blkref #0: rel 1663/16173/1249 blk 119 rmgr: Heap len (rec/tot): 54/ 54, tx: 929, lsn: 0/0400DF40, prev 0/0400DF08, desc: DELETE off 5 flags 0x00 KEYS_UPDATED , blkref #0: rel 1663/16173/1259 blk 0 rmgr: Heap len (rec/tot): 54/ 54, tx: 929, lsn: 0/0400DF78, prev 0/0400DF40, desc: DELETE off 95 flags 0x00 KEYS_UPDATED, blkref #0: rel 1663/16173/2608 blk 58 rmgr: Transaction len (rec/tot): 1133/ 1133, tx: 929, lsn: 0/0400DFB0, prev 0/0400DF78, desc: COMMIT 2022-05-20 17:47:14.53 8044 CST; rels: base/16173/16384 base/16173/16387 base/16173/ 16389; inval msgs: catcache 44 catcache 76 catcache 76 catcache 7 catcac he 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 62 catcache 61 catcache 105 catcache 104 catcache 105 catcache 104 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 62 catcache 61 catcache 105 catcache 104 catcache 39 catcache 7 catcache 6 catcache 7 catcache 6 catcache 62 catcache 61 catcache 44 relcache 16384 snapshot 2608 snapshot 2608 snapshot 2608 relcache 16387 snapshot 2608 snapshot 2608 elcache 16389 relcache 16387 snapshot 2608 46 第 8 章 特殊场景恢复实践案例 最后，执行 sys_wal_replay_resume() 函数，929 事务回滚，排他锁释放，查询 t1 表正常了。 [kingbase@localhost V9]$ /opt/Kingbase/ES/V9/Server/bin/ksql -d test -Usystem ksql (V9.0) Type "help" for help. WARNING:License file will expire in 29 days. test=# select pg_wal_replay_resume(); pg_wal_replay_resume (1 row) test=# select * from t1 limit 10; a | b 1 | 2022-05-19 23:26:14.340512+08 2 | 2022-05-19 23:26:14.340512+08 3 | 2022-05-19 23:26:14.340512+08 4 | 2022-05-19 23:26:14.340512+08 5 | 2022-05-19 23:26:14.340512+08 6 | 2022-05-19 23:26:14.340512+08 7 | 2022-05-19 23:26:14.340512+08 8 | 2022-05-19 23:26:14.340512+08 9 | 2022-05-19 23:26:14.340512+08 10 | 2022-05-19 23:26:14.340512+08 (10 rows) test=# 8.5 恢复后发现 database 被删除 将上一节中的 drop table 操作改为 drop database 后，指定 drop database 操作之前的时刻做恢复，会发现该 database 异常，无法正常切换到该 database 做任何操作。因为 drop database 这种操作无法回滚，所以该 database 异常，具体复现和分析步骤不再赘述，可参考上一小节自行做验证。 8.6 集群备库如何恢复 恢复好主库，主库启动后查询数据符合预期，执行 sys_wal_replay_resume() 提升节点，清空 kingbase.auto. conf 内的 PITR 参数设定，再通过 repmgr 重做备机，具体可参考《金仓数据守护集群和读写分离集群使用手册》。 47 第9章 9 第 章 附 A: 备份恢复常见异常处理 附 A: 备份恢复常见异常处理 请参考《KingbaseES 备份与恢复工具手册》。 48 版权声明 版权声明 北京人大金仓信息技术股份有限公司（简称：人大金仓）版权所有，并保留对本手册及本声明的一切权利。 未得到人大金仓的书面许可，任何人不得以任何方式或形式对本手册内的任何部分进行复制、摘录、备份、修 改、传播、翻译成其他语言、将其全部或部分用于商业用途。 免责声明 本手册内容依据现有信息制作，由于产品版本升级或其他原因，其内容有可能变更。人大金仓保留在没有任何通 知或者提示的情况下对手册内容进行修改的权利。 本手册仅作为使用指导，人大金仓在编写本手册时已尽力保证其内容准确可靠，但并不确保手册内容完全没有错 误或遗漏，本手册中的所有信息也不构成任何明示或暗示的担保。 技术支持 • 人大金仓官方网站：http://www.kingbase.com.cn/ • 人大金仓文档中心：http://help.kingbase.com.cn/ • 全国服务热线：400-601-1188 • 人大金仓技术支持与反馈信箱：support@kingbase.com.cn 49 服务周期承诺 服务周期承诺 由于市场需求在不断变化，技术创新和发展的进程不断加剧，产品的版本更迭不可避免。人大金仓对于产品版本 生命周期的有效管理，有助于您提前规划项目，更好地从产品服务终止上过渡。 表 1: KingbaseES 产品生命周期里程碑 关键里程碑点 定义 产品发布日期 产品正式发布版本，即 GA（general availability）版本的发布日期。 停止销售日期 正式停止销售的日期，版本停止接受订单日。该日之后，产品将不再销售。 停止功能升级日期 在该日期之后，不再提供新特性和新硬件支持。但依旧提供错误修复、安全修复、功 能维护等服务。 停止功能维护日期 在该日期之后，不再维护功能，修复问题。但依旧提供安全修复等服务 停止安全维护日期 在该日期之后，不再发布补丁版本修复中高风险漏洞，仅提供有限的支持。 产品服务终止日期 停止提供产品服务和支持的日期。包括软件维护版本，缺陷修复，以及针对该产品的 所有服务支持（包括服务热线和远程/现场支持）。 服务周期策略 金仓数据库管理系统 KingbaseES 产品确保以下的服务周期： 1）产品自发布之日起至产品停止功能升级（包含新特性、新硬件支持）之日不少于 5 年。 2）产品停止功能升级之日起至产品停止功能维护（主要包括问题修复）之日不少于 4 年。 3）产品功能维护停止之日起至产品停止安全维护（包括中高风险漏洞修复）之日不少于 2 年。 服务终止策略 金仓数据库管理系统 KingbaseES 产品确保在销售后，至少提供 6 年的服务支持。 注意: 人大金仓将会综合各方因素来确定产品服务终止日期。并将在实际产品服务终止日期之前至少 90 天，通过公 50 服务周期承诺 开方式宣布产品服务终止日期。 51