在知识库中专注阅读，并随时返回相关工具与课程
大家好，这里是公众号 DBA学习之路，分享一些学习国产数据库路上的知识和经验。 @TOC目录 最近，在学习 KingbaseES 数据库时，遇到两道 KCP 考题，分别为： 【单选题】当 KES 实例正在运行时，控制文件丢失，此时执行 checkpoint 操作，会有怎样的结果？ - checkpoint 执行正常 - x 实例崩溃 - checkpoint 执行失败，但是实例继续运
系统学习 Oracle DBA
开通会员 ¥128/月起
查看完整课程大家好，这里是公众号 DBA学习之路，分享一些学习国产数据库路上的知识和经验。
本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟
最近，在学习 KingbaseES 数据库时，遇到两道 KCP 考题，分别为：
【单选题】当 KES 实例正在运行时，控制文件丢失，此时执行 checkpoint 操作，会有怎样的结果？
【单选题】使用什么工具可以重建控制文件？
对于上面两道题的详细解析，大家感兴趣可以查看：
这两道题考验了对 KingbaseES 数据库控制文件维护和恢复的知识，经过研究和梳理之后，我写了一篇关于控制文件的维护和恢复文章，详细梳理了 KingbaseES 数据库控制文件的知识，这里分享给大家一起学习。
KingbaseES 数据库的控制文件是记录数据库内部信息的重要文件，一但控制文件损坏，数据库将会宕机，且无法启动。
控制文件默认存放在数据文件目录下的 global 目录下：
1[kingbase@kes:/home/kingbase]$ cd /data/global/2[kingbase@kes:/data/global]$ ll sys_control 3-rw------- 1 kingbase kingbase 8192 10月 8 16:00 sys_control通过 sys_controldata 命令可以查看控制文件的内容：
1[kingbase@kes:/home/kingbase]$ export KINGBASE_DATE=/data2[kingbase@kes:/home/kingbase]$ sys_controldata3sys_control 版本: 12014Catalog 版本: 2022111515数据库系统标识符: 74181971140184124886数据库簇状态: 在运行中7sys_control 最后修改: 2024年10月08日 星期二 16时00分11秒8最新检查点位置: 0/1CF23F09最新检查点的 REDO 位置: 0/1CF23C010最新检查点的重做日志文件: 00000001000000000000000111最新检查点的 TimeLineID: 112最新检查点的PrevTimeLineID: 113最新检查点的full_page_writes: 开启14最新检查点的NextXID: 0:106415最新检查点的 NextOID: 2457616最新检查点的NextMultiXactId: 117最新检查点的NextMultiOffsetD: 018最新检查点的oldestXID: 103219最新检查点的oldestXID所在的数据库：120最新检查点的oldestActiveXID: 106421最新检查点的oldestMultiXid: 122最新检查点的oldestMulti所在的数据库：123最新检查点的oldestCommitTsXid:024最新检查点的newestCommitTsXid:025最新检查点的时间: 2024年10月08日 星期二 16时00分07秒26不带日志的关系: 0/3E8使用虚假的LSN计数器27最小恢复结束位置: 0/028最小恢复结束位置时间表: 029开始进行备份的点位置: 0/030备份的最终位置: 0/031需要终止备份的记录: 否32wal_level设置： replica33wal_log_hints设置： 关闭34max_connections设置： 10035max_worker_processes设置： 836max_wal_senders设置: 1037max_prepared_xacts设置： 038max_locks_per_xact设置： 6439track_commit_timestamp设置: 关闭40最大数据校准: 841数据库块大小: 819242大关系的每段块数: 13107243WAL的块大小: 819244每一个 WAL 段字节数: 1677721645标识符的最大长度: 6446在索引中可允许使用最大的列数: 3247TOAST区块的最大长度: 198848大对象区块的大小: 204849日期/时间 类型存储: 64位整数50正在传递Flloat4类型的参数: 由值51正在传递Flloat8类型的参数: 由值52数据页校验和版本: 053当前身份验证: c4e1fd6b06f9a8aed87af6ecd6fe351980a0c2d5377215695d959f1af2a2b0a554数据库模式： 155身份验证方法模式： 0控制文件中记录内容如下：
注意：KES 中的控制文件路径不能改变。
控制文件无法手动修改，无法单独备份，只能在使用 sys_rman、sys_basebackup 备份数据库时一起备份控制文件。
启动、关闭和恢复数据库时需要读取控制文件中的相关信息。
通过参数 control_file_copy 可以实现控制文件冗余(多路复用)：
1-- 参数 control_file_copy 默认不启用2test=# show control_file_copy;3 control_file_copy 4-------------------5 6(1 行记录)启用 control_file_copy：
1## 使用 root 用户创建目录 /cf_copy 并设置目录权限2[root@kes ~]# mkdir -p /cf_copy3[root@kes ~]# chown kingbase:kingbase /cf_copy4[root@kes ~]# chmod 700 /cf_copy5[root@kes ~]# su - kingbase67## 查看配置参数示例8[kingbase@kes:/data]$ cat kingbase.conf | grep control_file_copy9# control_file_copy = '' #example: control_file_copy = 'filepath/filename'10 #control_file_copy = 'filepath1/filename1;filepath2/filename2'1112## 配置 kingbase.conf 文件，这里复制 2 份13[kingbase@kes:/data]$ cat<<-EOF>>/data/kingbase.conf14control_file_copy='/cf_copy/sys_control_1;/cf_copy/sys_control_2'15EOF1617## 查看配置后的参数值18[kingbase@kes:/data]$ grep -v "^\s*\(#\|$\)" /data/kingbase.conf | grep control_file_copy19control_file_copy='/cf_copy/sys_control_1;/cf_copy/sys_control_2'2021## 重启数据库22[kingbase@kes:/data]$ sys_ctl restart23等待服务器进程关闭 .... 完成24服务器进程已经关闭25等待服务器进程启动 ....2024-10-08 17:10:40.808 CST [9023] 日志: sepapower extension initialized262024-10-08 17:10:40.812 CST [9023] 日志: 正在启动 KingbaseES V008R006C007B0024 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit272024-10-08 17:10:40.812 CST [9023] 日志: 正在监听IPv4地址"0.0.0.0"，端口 54321282024-10-08 17:10:40.812 CST [9023] 日志: 正在监听IPv6地址"::"，端口 54321292024-10-08 17:10:40.813 CST [9023] 日志: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听302024-10-08 17:10:40.914 CST [9023] 日志: 日志输出重定向到日志收集进程312024-10-08 17:10:40.914 CST [9023] 提示: 后续的日志输出将出现在目录 "sys_log"中.32 完成33服务器进程已经启动验证参数生效：
1test=# show control_file_copy;2 control_file_copy 3-----------------------------------------------4 /cf_copy/sys_control_1;/cf_copy/sys_control_25(1 行记录)查看控制文件：
1[kingbase@kes:/home/kingbase]$ ll /cf_copy/*2-rw------- 1 kingbase kingbase 8192 10月 8 17:10 /cf_copy/sys_control_13-rw------- 1 kingbase kingbase 8192 10月 8 17:10 /cf_copy/sys_control_2可以看到数据库配置已经生效，现在有 3 份控制文件。
登录数据库，对一张测试表 test 插入数据：
1test=# \c test system 2您现在已经连接到数据库 "test",用户 "system".3test=# \d test 4 数据表 "public.test"5 栏位 | 类型 | 校对规则 | 可空的 | 预设 6------+---------+----------+--------+------7 id | integer | | | 8索引：9 "idx_test_id" btree (id)10-- 插入一条数据11test=# insert into test values (1); 12INSERT 0 113-- 人为删除控制文件 /data/global/sys_control14test=# \! rm /data/global/sys_control15-- 插入第二条数据，可以成功插入16test=# insert into test values (2); 17INSERT 0 118-- 可以成功查询，说明删除之后不影响正常的 DML 操作，必须要触发检查点才会报错19test=# select * from test;20 id 21----22 123 224(2 行记录)25-- 但是手动触发检查点之后，数据库宕机了26test=# checkpoint;27警告: 中断联接, 因为其它服务器进程崩溃28描述: The kingbase has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.29提示: 一会儿你将可以重联接数据库并且重复你的命令.30服务器意外地关闭了联接31 这种现象通常意味着服务器在处理请求之前32或者正在处理请求的时候意外中止此时尝试启动数据库，会提示无法找到控制文件，启动失败：
1[kingbase@kes:/home/kingbase]$ sys_ctl start2sys_ctl: 其他服务器进程可能正在运行; 尝试启动服务器进程3等待服务器进程启动 ....kingbase: 无法找到数据库系统4预期在目录 "/data" 找到,5但是无法打开文件 "/data/global/sys_control": 没有那个文件或目录6 已停止等待7sys_ctl: 无法启动服务器进程8检查日志输出.当控制文件被破坏后，手动触发检查点，实例会直接崩溃。
这时，如果我们配置了控制文件冗余，也就是 control_file_copy 参数，那就很简单了，直接拷贝 /cf_copy 目录下的控制文件到 /data/global 目录下，并且重命名为 sys_control 即可：
1[kingbase@kes:/home/kingbase]$ cp /cf_copy/sys_control_1 /data/global/sys_control再次启动数据库：
1[kingbase@kes:/home/kingbase]$ sys_ctl start2sys_ctl: 其他服务器进程可能正在运行; 尝试启动服务器进程3等待服务器进程启动 ....2024-10-08 17:21:02.689 CST [9321] 日志: sepapower extension initialized42024-10-08 17:21:02.693 CST [9321] 日志: 正在启动 KingbaseES V008R006C007B0024 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit52024-10-08 17:21:02.694 CST [9321] 日志: 正在监听IPv4地址"0.0.0.0"，端口 5432162024-10-08 17:21:02.694 CST [9321] 日志: 正在监听IPv6地址"::"，端口 5432172024-10-08 17:21:02.695 CST [9321] 日志: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听82024-10-08 17:21:02.797 CST [9321] 日志: 日志输出重定向到日志收集进程92024-10-08 17:21:02.797 CST [9321] 提示: 后续的日志输出将出现在目录 "sys_log"中.10 完成11服务器进程已经启动suprise，数据库成功启动，此时查看 test 表数据库：
1test=# \c test system2您现在已经连接到数据库 "test",用户 "system".3test=# select * from test;4 id 5----6 17 28(2 行记录)数据也没有丢失。
这种方式是基于没有使用控制文件冗余的情况，需要使用 sys_resetwal 来重建控制文件，相对比较复杂一些。
sys_resetwal 会重置一个 KingbaseES 数据库集簇的预写式日志和控制信息。出于安全原因，使用时必须在命令行中指定数据目录，sys_resetwal 不会使用环境变量 $KINGBASE_DATA。
查看 sys_resetwal 的帮助命令：
1[kingbase@kes:/home/kingbase]$ sys_resetwal --help2sys_resetwal 重置一个Kingbase数据库集簇的预写式日志.3用法:4 sys_resetwal [选项]... 数据目录5选项:6 -c, --commit-timestamp-ids=XID,XID7 设置提交时间可以检索到的最老的和最新的事务ID8 (0意味着没有变化)9 [-D, --kingbase-data=]DATADIR data directory10 -e, --epoch=XIDEPOCH 设置下一个事务ID的epoch11 -f, --force 强制更新完成12 -g, --dbmode 设置数据库模式13 -l, --next-wal-file=WALFILE 设置新的WAL最小起始位置14 -m, --multixact-ids=MXID,MXID 设置下一个和最旧的多事务ID15 -n, --dry-run 不更新，只显示将要执行的操作16 -o, --next-oid=OID 设置下一个OID17 -O, --multixact-offset=OFFSET 设置下一个多事务偏移量18 -V, --version 输出版本信息，然后退出19 -x, --next-transaction-id=XID 设置下一个事务ID20 --wal-segsize=SIZE WAL段的大小（兆字节）21 -?, --help 显示本帮助，然后退出2223Report bugs to <kingbase-bugs@kingbase.com.cn>.首先，我们需要取消 control_file_copy 参数的配置：
1## 从 kingbase.conf 文件中注释 control_file_copy 参数配置，vi 修改即可2[kingbase@kes:/data]$ cat kingbase.conf | grep control_file_copy3# control_file_copy = '' #example: control_file_copy = 'filepath/filename'4 #control_file_copy = 'filepath1/filename1;filepath2/filename2'5#control_file_copy='/cf_copy/sys_control_1;/cf_copy/sys_control_2'67## 重启数据库生效8[kingbase@kes:/data]$ sys_ctl restart9等待服务器进程关闭 .... 完成10服务器进程已经关闭11等待服务器进程启动 ....2024-10-08 17:25:49.495 CST [9475] 日志: sepapower extension initialized122024-10-08 17:25:49.499 CST [9475] 日志: 正在启动 KingbaseES V008R006C007B0024 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit132024-10-08 17:25:49.499 CST [9475] 日志: 正在监听IPv4地址"0.0.0.0"，端口 54321142024-10-08 17:25:49.499 CST [9475] 日志: 正在监听IPv6地址"::"，端口 54321152024-10-08 17:25:49.500 CST [9475] 日志: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听162024-10-08 17:25:49.596 CST [9475] 日志: 日志输出重定向到日志收集进程172024-10-08 17:25:49.596 CST [9475] 提示: 后续的日志输出将出现在目录 "sys_log"中.18 完成19服务器进程已经启动2021## 删除 /cf_copy 目录下的冗余文件22[kingbase@kes:/data]$ rm -rf /cf_copy/sys_control_*使用以上同样方式模拟控制文件损坏后，数据库无法成功启动：
1[kingbase@kes:/data]$ sys_ctl start2sys_ctl: 其他服务器进程可能正在运行; 尝试启动服务器进程3等待服务器进程启动 ....kingbase: 无法找到数据库系统4预期在目录 "/data" 找到,5但是无法打开文件 "/data/global/sys_control": 没有那个文件或目录6 已停止等待7sys_ctl: 无法启动服务器进程8检查日志输出.此时没有冗余控制文件，只能使用 sys_resetwal 来重建控制文件，这个过程比较复杂，下面进行详细演示。
一般恢复控制文件只需要以下几个参数即可：
下面节开始演示 sys_resetwal 如何重建控制文件。
首先需要讲解每一个参数的值是如何获取。
wal 命名格式文件名称为 16 进制的 24 个字符组成，每 8 个字符一组，每组的意义如下：
参数 -l 的值是设置新的 WAL 最小起始位置，需要查找 $KINGBASE_DATA/sys_wal 目录下最大的日志文件编号，然后加 1，就可以得到 -l 参数的值：
1## 最大文件编号为 0000000100000000000000022[kingbase@kes:/home/kingbase]$ ll /data/sys_wal/*3-rw------- 1 kingbase kingbase 16777216 10月 8 17:28 /data/sys_wal/0000000100000000000000014-rw------- 1 kingbase kingbase 16777216 9月 24 21:13 /data/sys_wal/0000000100000000000000025## 加 1 也就是 0000000100000000000000036000000010000000000000002 + 1 = 000000010000000000000003这个结果是如何计算的？通过获取的最大文件编号 wal 的十六进制数：000000010000000000000002，进行加 1 的计算过程如下：
因此，计算过程是：$000000010000000000000002_{16} + 1_{16} = 000000010000000000000003_{16}$，这是因为在十六进制中，每个位的值是 16 的幂，最右边的位是 $16^0$，即 1。当我们将 2 加 1 时，我们得到 3，这在十六进制中是有效的，不需要进位到下一个位。
这里也可以使用 python 计算，比较方便：
1import os2import glob3import re45# 获取 WAL 目录路径6wal_directory = os.path.join(os.getenv("KINGBASE_DATA"), "sys_wal")78# 正则表达式匹配十六进制字符串9hex_pattern = re.compile(r'^[0-9A-Fa-f]+$')1011# 查找所有符合十六进制格式的文件名并获取最大编号12max_number = max(13 (os.path.basename(f) for f in glob.glob(os.path.join(wal_directory, "*"))14 if hex_pattern.match(os.path.basename(f))), # 确保文件名是十六进制15 key=lambda x: int(x, 16)16)1718# 计算下一个编号19next_hex_number = f"{int(max_number, 16) + 1:024X}"2021# 打印结果22print(f"最大日志文件编号: {max_number.zfill(24)}") # 确保格式为 24 位23print(f"最大日志文件编号加 1 后的日志: {next_hex_number}")242526## 执行后的输出如下27最大日志文件编号: 00000001000000000000000228最大日志文件编号加 1 后的日志: 000000010000000000000003这里清晰的介绍了如何计算得出参数 -l 的值。
参数 -x 的值是设置下一个事务 ID，需要查找 $KINGBASE_DATA/sys_xact 目录下的最大编号，然后加 1，再在末尾补位 00000，就可以得到 -x 参数的值：
1## 最大编号为 00002[kingbase@kes:/home/kingbase]$ ll /data/sys_xact/*3-rw------- 1 kingbase kingbase 262144 10月 8 17:28 /data/sys_xact/000045## 加 1 后，末尾补位 0000060x000100000这同样也是一个 16 进制数，通过 python 计算可以得到值：
1import os2import glob3import re45# 获取 sys_xact 目录路径6xact_directory = os.path.join(os.getenv("KINGBASE_DATA"), "sys_xact")78# 正则表达式匹配十六进制字符串9hex_pattern = re.compile(r'^[0-9A-Fa-f]+$')1011# 查找所有符合十六进制格式的文件名并获取最大编号12max_number = max(13 (os.path.basename(f) for f in glob.glob(os.path.join(xact_directory, "*"))14 if hex_pattern.match(os.path.basename(f))), # 确保文件名是十六进制15 key=lambda x: int(x, 16)16)1718# 计算下一个编号并在末尾补位 0000019next_id = (int(max_number, 16) + 1) * 0x10000020next_hex_id = f"0x{next_id:09X}"2122# 打印结果23print(f"最大事务编号列: {max_number}")24print(f"最大事务编号加 1 末尾补 00000 后的事务 ID: {next_hex_id}")2526## 执行后的输出如下27最大事务编号列: 000028最大事务编号加 1 末尾补 00000 后的事务 ID: 0x000100000这里需要补位 00000，所以 print 打印出来需要 9 位。
参数 -x 的值有两个，需要查找 $KINGBASE_DATA/sys_multixact/offsets 目录下的最大编号和最小编号：
📢 注意：最旧的多事务 ID 不能为 0，如果为 0 也需要进行加 1 处理。
1## 最大和最小均为 00002[kingbase@kes:/home/kingbase]$ ll /data//sys_multixact/offsets3-rw------- 1 kingbase kingbase 8192 10月 8 17:28 000045## 最大编号 +1，末尾补位 000060x0001000078## 最小编号末尾补位 0000，因为是 0，所以 +190x00000001这同样也是 16 进制数，通过 python 计算可以得到值：
1import os2import glob3import re45# 获取 offsets 目录路径6offsets_directory = os.path.join(os.getenv("KINGBASE_DATA"), "sys_multixact", "offsets")78# 正则表达式匹配十六进制字符串9hex_pattern = re.compile(r'^[0-9A-Fa-f]+$')1011# 查找以数字开头的文件，并提取编号12log_files = [os.path.basename(f) for f in glob.glob(os.path.join(offsets_directory, "*"))13 if hex_pattern.match(os.path.basename(f))]1415# 设置最大和最小编号，处理没有文件的情况16max_number = max(log_files, key=lambda x: int(x, 16))17min_number = min(log_files, key=lambda x: int(x, 16))1819# 计算下一个多事务 ID 和最旧的多事务 ID20def calculate_ids(max_hex, min_hex):21 max_id = (int(max_hex, 16) + 1) * 0x1000022 min_id = (int(min_hex, 16) * 0x10000) + (1 if int(min_hex, 16) == 0 else 0)23 return f"0x{max_id:08X}", f"0x{min_id:08X}"2425# 计算 ID26max_hex_result, min_hex_result = calculate_ids(max_number, min_number)2728# 打印结果29print(f"最大多事务编号: {max_number}")30print(f"最小多事务编号: {min_number}")31print(f"下一个多事务 ID: {max_hex_result}")32print(f"下一个最旧的多事务 ID: {min_hex_result}")3334## 执行后的输出如下35最大多事务编号: 000036最小多事务编号: 000037下一个多事务 ID: 0x0001000038下一个最旧的多事务 ID: 0x00000001参数 -O 的值是设置下一个多事务偏移量，需要查找 $KINGBASE_DATA/sys_multixact/members 目录下的最大编号，加 1，然后乘以 0xCC80：
1## 最大编号为 00002[kingbase@kes:/home/kingbase]$ ll /data/sys_multixact/members3-rw------- 1 kingbase kingbase 8192 9月 24 21:13 000045## 加 1，乘以 0xCC8060xCC80这同样也是 16 进制数，通过 python 计算可以得到值：
1import os2import glob3import re45# 获取多事务成员目录路径6members_directory = os.path.join(os.getenv("KINGBASE_DATA"), "sys_multixact", "members")78# 正则表达式匹配十六进制字符串9hex_pattern = re.compile(r'^[0-9A-Fa-f]+$')1011# 查找所有符合十六进制格式的文件名并获取最大编号12max_number = max(13 (os.path.basename(f) for f in glob.glob(os.path.join(members_directory, "*"))14 if hex_pattern.match(os.path.basename(f))), # 确保文件名是十六进制15 key=lambda x: int(x, 16)16)1718# 计算下一个编号和下一个事务偏移量19next_number = int(max_number, 16) + 120next_hex_number = f"0x{next_number:08X}"21next_offset = next_number * 0xCC8022next_hex_offset = f"0x{next_offset:X}"2324# 打印结果25print(f"最大多事务成员编号: {max_number}")26print(f"最大编号加1的编号: {next_hex_number}")27print(f"下一个事务偏移量: {next_hex_offset}")2829## 执行后的输出如下30最大多事务成员编号: 000031最大编号加1的编号: 0x0000000132下一个事务偏移量: 0xCC80参数 -g 的值是数据库兼容模式：
获取完参数值后，也就获得了恢复控制文件的命令：
1sys_resetwal -f -l 000000010000000000000003 \2-x 0x000100000 \3-m 0x00010000,0x00000001 \4-O 0xCC80 \5-D /data \6-g 1但是，在执行以上命令之前，需要先手工创建一个空的控制文件和删除 kingbase.pid 文件：
1[kingbase@kes:/home/kingbase]$ touch /data/global/sys_control2[kingbase@kes:/home/kingbase]$ rm -rf /data/kingbase.pid执行 sys_resetwal 恢复控制文件：
1[kingbase@kes:/home/kingbase]$ sys_resetwal -f -l 000000010000000000000003 \2-x 0x000100000 \3-m 0x00010000,0x00000001 \4-O 0xCC80 \5-D /data \6-g 17sys_resetwal: 警告: sys_control存在，但已损坏或版本错误；忽略它8重置预写日志启动数据库：
1[kingbase@kes:/home/kingbase]$ sys_ctl start2等待服务器进程启动 ....2024-10-08 22:17:41.248 CST [16714] 日志: sepapower extension initialized32024-10-08 22:17:41.252 CST [16714] 日志: 正在启动 KingbaseES V008R006C007B0024 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit42024-10-08 22:17:41.253 CST [16714] 日志: 正在监听IPv4地址"0.0.0.0"，端口 5432152024-10-08 22:17:41.253 CST [16714] 日志: 正在监听IPv6地址"::"，端口 5432162024-10-08 22:17:41.254 CST [16714] 日志: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听72024-10-08 22:17:41.356 CST [16714] 日志: 日志输出重定向到日志收集进程82024-10-08 22:17:41.356 CST [16714] 提示: 后续的日志输出将出现在目录 "sys_log"中.9 完成10服务器进程已经启动数据库已经正常启动，访问数据是否正常：
1test=# \c test system2您现在已经连接到数据库 "test",用户 "system".3test=# table test;4 id5----6 17 28 39 410(4 行记录)访问正常，控制文件已恢复。
基于 sys_resetwal 命令，对于每个参数的值如何脚本话获取，上面我已经列出了，所以通过脚本的方式一键恢复控制文件也就不难了，我写了一个 python 脚本实现，脚本支持传入 2 个参数：
1[kingbase@kes:/home/kingbase]$ python3 recover_controlfile.py --help2usage: recover_controlfile.py [-h] [-cs {1,2}] [-kd KINGBASE_DATA]34KingbaseES 一键恢复控制文件56optional arguments:7 -h, --help show this help message and exit8 -cs {1,2}, --compatible_style {1,2}9 兼容样式: 1-Oracle, 2-PostgreSQL（可选，默认为 1）10 -kd KINGBASE_DATA, --kingbase_data KINGBASE_DATA11 KINGBASE_DATA 参数（可选）下面演示一下一键恢复脚本的使用过程，首先模拟控制文件丢失：
1test=# \! rm -rf /data/global/sys_control2test=# checkpoint ; 34警告: 中断联接, 因为其它服务器进程崩溃5描述: The kingbase has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.6提示: 一会儿你将可以重联接数据库并且重复你的命令.7服务器意外地关闭了联接8 这种现象通常意味着服务器在处理请求之前9或者正在处理请求的时候意外中止然后执行一键恢复控制文件脚本：
1[kingbase@kes:/home/kingbase]$ python3 recover_controlfile.py23==================================================4WAL 信息:5最大日志文件编号: 00000001000000000000000F6最大日志文件编号加 1 后的日志: 0000000100000000000000107==================================================8910==================================================11XACT 事务信息:12最大事务编号列: 000013最大事务编号加 1 末尾补 00000 后的事务 ID: 0x00010000014==================================================151617==================================================18multixact 多事务信息:19最大多事务编号: 000020最小多事务编号: 000021下一个多事务 ID: 0x0001000022下一个最旧的多事务 ID: 0x0000000123==================================================242526==================================================27多事务成员信息:28最大多事务成员编号: 000029最大编号加 1 的编号: 0x0000000130下一个事务偏移量: 0xCC8031==================================================323334==================================================35生成 sys_resetwal 恢复命令:36sys_resetwal -f -l 000000010000000000000010 \37 -x 0x000100000 \38 -m 0x00010000,0x00000001 \39 -O 0xCC80 \40 -D /data \41 -g 142==================================================434445==================================================46创建一个空控制文件:47b'-rw-r--r-- 1 kingbase kingbase 0 10\xe6\x9c\x88 9 17:03 /data/global/sys_control'48==================================================495051==================================================52正在删除 kingbase.pid 文件:53/data/kingbase.pid54==================================================555657==================================================58正在执行 sys_resetwal 恢复控制文件:59重置预写日志60sys_resetwal: 警告: sys_control存在，但已损坏或版本错误；忽略它61==================================================626364==================================================65恢复的控制文件所在路径及大小如下:66b'-rw-r--r-- 1 kingbase kingbase 8192 10\xe6\x9c\x88 9 17:03 /data/global/sys_control'67==================================================6869正在启动数据库：7071等待服务器进程启动 ....2024-10-09 17:03:00.573 CST [46332] 日志: sepapower extension initialized722024-10-09 17:03:00.577 CST [46332] 日志: 正在启动 KingbaseES V008R006C007B0024 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit732024-10-09 17:03:00.578 CST [46332] 日志: 正在监听IPv4地址"0.0.0.0"，端口 54321742024-10-09 17:03:00.578 CST [46332] 日志: 正在监听IPv6地址"::"，端口 54321752024-10-09 17:03:00.584 CST [46332] 日志: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听762024-10-09 17:03:00.702 CST [46332] 日志: 日志输出重定向到日志收集进程772024-10-09 17:03:00.702 CST [46332] 提示: 后续的日志输出将出现在目录 "sys_log"中.78 完成79服务器进程已经启动8081恭喜！控制文件还原成功！！！一键恢复完成，数据库成功开启：
1test=# \c test system 2您现在已经连接到数据库 "test",用户 "system".3test=# table test;4 id 5----6 17 28 39 410(4 行记录)数据库可以正常访问。
控制文件不仅记录着数据库的重要信息，还直接影响着数据库的运行状态，所以我们不仅要做好数据库的日常备份，还应该使用 control_file_copy 参数将控制文件的镜像存放在不同的存储设备上，避免发生单点故障。
最后，希望大家都永不宕机！！！