数据库异常关闭时,数据库关闭时来不及或者没机会做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,日志 From: https://www.cnblogs.com/kingbase/p/16582101.html