KingbaseES集群管理维护案例之---备库checkpoint分析
作者：互联网
数据库异常关闭时，数据库关闭时来不及或者没机会做checkpoint，则需要从上一个一致性检查的开始恢复。KingbaseES备机checkpoint是不能产生checkpoint WAL日志条目的，因为如果写这样类型的checkpoint的话，就会将接收的WAL打乱，那么日志将混乱，回放会出问题。
那么问题来了，备机支持checkpoint吗？它的checkpoint怎么做的？
KingbaseES为了缩短恢复时间，备机上也支持checkpoint，即CreateRestartPoint。但是在sys_control文件的checkpoint记录的位点还是从主机传过来WAL里面的checkpoint记录位置。
如下所示：
当在备库执行后台执行checkpoint或手工执行checkpoint时，sys_log日志，会出现以下“recovery restart point”的日志信息。
我们通过测试来看看主备库checkpoint的不同点。
节点信息：
一、在主库执行checkpoint
1）主库checkpoint
test=# checkpoint;
CHECKPOINT
2、 主库控制文件被更新
[kingbase@node101 bin]$ ./sys_controldata -D ../data
sys_control version number: 1201
Catalog version number: 202112261
Database system identifier: 7080367334319169673
Database cluster state: in production
sys_control last modified: Wed 10 Aug 2022 11:52:41 AM CST
Latest checkpoint location: 1/D20002E0
Latest checkpoint's REDO location: 1/D20002B0
Latest checkpoint's REDO WAL file: 0000000700000001000000D2
3、 查看wal日志中checkpoint记录
[kingbase@node101 bin]$ ./sys_waldump ../data/sys_wal/0000000700000001000000D2
.......
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 1/D20002E0, prev 1/D20002B0, desc: CHECKPOINT_ONLINE redo 1/D20002B0; tli 7; prev tli 7; fpw true; xid 0:1950; oid 123514; multi 1; offset 0; oldest xid 867 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 1950; online
rmgr: Standby len (rec/tot): 42/ 42, tx: 0, lsn: 1/D2000358, prev 1/D20002E0, desc: RUNNING_XACTS nextXid 1950 latestCompletedXid 3523216096 oldestRunningXid 1950
sys_waldump: fatal: error in WAL record at 1/D2000358: invalid record length at 1/D2000388: wanted 24, got 0
=如下图所示，在wal日志文件中，增加了一条记录checkpoint的wal日志条目,并且和控制文件中的信息一致。=
二、备库手工执行checkpoint
1、查看checkpoint之前wal日志记录
2、执行checkpoint
test=# checkpoint;
CHECKPOINT
3、再次查看wal日志的变化
[kingbase@node102 bin]$ ./sys_waldump ../data/sys_wal/0000000700000001000000D2
.......
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 1/D20002E0, prev 1/D20002B0, desc: CHECKPOINT_ONLINE redo 1/D20002B0; tli 7; prev tli 7; fpw true; xid 0:1950; oid 123514; multi 1; offset 0; oldest xid 867 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 1950; online
rmgr: Standby len (rec/tot): 42/ 42, tx: 0, lsn: 1/D2000358, prev 1/D20002E0, desc: RUNNING_XACTS nextXid 1950 latestCompletedXid 3523216096 oldestRunningXid 1950
sys_waldump: fatal: error in WAL record at 1/D2000358: invalid record length at 1/D2000388: wanted 24, got 0
# 如上所示，在备库执行checkpoint后，并没有在备库的wal日志中增加相关的日志条目。
=经测试，在备库单独执行checkpoint，是不会生成检查点；备库产生的检查点，是当主库执行checkpoint（后台或手工）后，写入wal日志，当wal日志同步到备库后，备库执行checkpoint（手工或后台），读取wal日志，根据wal日志的记录，产生‘recovery restart point’，并更新备库的controlfile。=
三、备库数据库进程意外重启的恢复
1、重启之前备库控制文件信息
[kingbase@node102 bin]$ ./sys_controldata -D ../data
sys_control version number: 1201
Catalog version number: 202112261
Database system identifier: 7080367334319169673
Database cluster state: in archive recovery
sys_control last modified: Thu 11 Aug 2022 10:17:12 AM CST
Latest checkpoint location: 1/D973F910
Latest checkpoint's REDO location: 1/D973F8E0
Latest checkpoint's REDO WAL file: 0000000900000001000000D9
2、数据库故障重启
[kingbase@node102 sys_wal]$ kill -9 2546
[kingbase@node102 bin]$ ./sys_ctl start -D /home/kingbase/cluster/R6HA/kha/kingbase/data
3、数据库启动后sys_log日志
2022-08-11 11:52:34.532 CST,,,32224,,62f47d02.7de0,1,,2022-08-11 11:52:34 CST,,0,LOG,00000,"database system was interrupted while in recovery at log time 2022-08-11 10:16:34 CST",,"If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.",,,,,,,""
2022-08-11 11:52:35.631 CST,,,32224,,62f47d02.7de0,2,,2022-08-11 11:52:34 CST,,0,LOG,00000,"entering standby mode",,,,,,,,,""
2022-08-11 11:52:35.636 CST,,,32224,,62f47d02.7de0,3,,2022-08-11 11:52:34 CST,1/0,0,LOG,00000,"redo starts at 1/D973F8E0",,,,,,,,,""
2022-08-11 11:52:35.636 CST,,,32224,,62f47d02.7de0,4,,2022-08-11 11:52:34 CST,1/0,0,LOG,00000,"redo wal segment count 44",,,,,,,,,""
2022-08-11 11:52:35.743 CST,"system","esrep",32228,"192.168.1.102:38099",62f47d03.7de4,1,"",2022-08-11 11:52:35 CST,,0,FATAL,57P03,"the database system is starting up",,,,,,,,,""
=如下所示，备库意外重启，从最近的checkpoint开始recovery，最近的checkpoint和重启前控制文件记录的checkpoint一致。=
四、总结
对于KingbaseES集群中的主备库checkpoint机制不太一样，主库通过后台或手工checkpoint时，会在wal日志中记录日志条目；但是备库的checkpoint不会记录日志条目，备库在做checkpoint时，会显示“recovery restart point”，备库控制文件的checkpoint信息，其实是读取的主库传递的wal日志记录，当备库意外宕机重启，做recovery时，是从最近的checkpoint位置开时执行恢复。
标签：11,---,wal,备库,checkpoint,sys,日志 来源： https://www.cnblogs.com/kingbase/p/16582101.html