标签：11 --- wal 备库 checkpoint sys 日志
数据库异常关闭时，数据库关闭时来不及或者没机会做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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。