PostgreSQL故障恢复能力之检查点（Checkpoint）

复习下前面的知识点：

1、缓冲区高速缓存（Buffer Cache）位于服务器的共享内存中，并且所有进程均可访问。在读取或更新数据时，进程将页面读入缓存。当页面位于缓存中时，我们在RAM中使用它并保存数据到磁盘。

2、当遇到掉电等故障场景，所有 RAM 内容丢失时，要在故障后恢复数据，pg必须维护一份预写式日志（WAL），在故障恢复过程中通过重放WAL日志进行数据恢复。

checkpoint

本文需要讨论的是，我们不知道在恢复期间从哪里开始重放 WAL 记录。

方案一：

从头开始恢复，带来是问题是我们不一定保留了所有历史的WAL日志记录（保留所有历史WAL会占用大量磁盘空间），即使我们通过归档保留了所有的WAL记录，恢复的时长也会难以接受。

方案二：

我们需要一个逐渐向前推进的时间点，我们可以从该时间点开始恢复（并可以安全地删除时间点以前的WAL 记录），为此，pg引入了检查点（checkpoint）。

当执行checkpoint后，会确保检查点开始时所有脏的缓冲区都刷到磁盘上，此时checkpoint执行完成。后续我们可以使用checkpoint记录的开始时间作为开始恢复的点。

 checkpoint会执行多久

checkpoint执行后会带来大量的页面写入操作，为了避免大量的页面写入对I/O造成冲击，在检查点期间写入脏缓冲区的过程会分散为一段时间。该周期由checkpoint_completion_target控制，它是检查点间隔的一部分，默认为0.5，也就是说每个checkpoint需要在checkpoints间隔时间的50%内完成。

通常checkpoint_completion_target值会增加到 0.9 以获得更好的均匀性，PostgreSQL 14版本中会将默认值修改为0.9。

 checkpoint执行过程

1、首先会对缓冲区中的脏页进行标记

 2、然后检查指针遍历所有缓存并将标记的脏页刷新到磁盘（页面不会从缓存中逐出，而只会写入磁盘）。

3、新的脏缓冲区不会被标记，并且检查指针不会写入它们。

 4、创建检查点结束的 WAL 记录，该记录包含检查点开始时间的 LSN。

5、更新控制文件信息（$PGDATA/global/pg_control）。

 演示

1、创建一个表；它的页面将进入缓冲区缓存并变脏：

CREATE EXTENSION pg_buffercache;
CREATE TABLE chkpt AS SELECT * FROM generate_series(1,10000) AS g(n);
SELECT count(*) FROM pg_buffercache WHERE isdirty;

postgres=# SELECT count(*) FROM pg_buffercache WHERE isdirty;
 count
-------
    62
(1 row)

2、记住当前的 WAL 位置

SELECT pg_current_wal_insert_lsn();

 pg_current_wal_insert_lsn
---------------------------
 3/8A0B3810
(1 row)

3、手动执行检查点操作

CHECKPOINT;
SELECT count(*) FROM pg_buffercache WHERE isdirty;

 count
-------
     0
(1 row)

4、看看检查点是如何反映在 WAL 中的

SELECT pg_current_wal_insert_lsn();

 pg_current_wal_insert_lsn
---------------------------
 3/8A0B38F8
(1 row)

可以看到lsn有更新，接下来用pg_waldump查看wal日志记录了哪些内容

查看当前lsn对应的wal日志文件

 SELECT file_name, upper(to_hex(file_offset)) file_offset FROM pg_walfile_name_offset('3/8A0B38F8');

        file_name         | file_offset
--------------------------+-------------
 00000001000000030000008A | B38F8
(1 row)

/usr/local/pgsql/bin/pg_waldump -p /usr/local/pgsql/data/pg_wal/ -s 3/8A0B3810  -e 3/8A0B38F8  00000001000000030000008A

rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 3/8A0B3810, prev 3/8A0B37D8, desc: RUNNING_XACTS nextXid 58215 latestCompletedXid 58214 oldestRunningXid 58215
rmgr: XLOG        len (rec/tot):    114/   114, tx:          0, lsn: 3/8A0B3848, prev 3/8A0B3810, desc: CHECKPOINT_ONLINE redo 3/8A0B3810; tli 1; prev tli 1; fpw true; xid 0:58215; oid 34053; multi 1; offset 0; oldest xid 479 in DB 1; oldest multi 1 in DB 12723; oldest/newest commit timestamp xid: 0/0; oldest running xid 58215; online

可以看到日志记录了CHECKPOINT_ONLINE信息，checkpoint start的LSN在单词“redo”之后输出，这个位置对应checkpoint start时间最后一个WAL记录。

5、查看控制文件信息，可知控制文件记录了最近的checkpoint点对应的lsn信息

pg_controldata -D /usr/local/pgsql/data/ |egrep 'Latest.*location'

Latest checkpoint location:           3/8A0B3848
Latest checkpoint's REDO location:    3/8A0B3810

故障后恢复

如果服务器出现故障，则在后续启动时，会通过查看pg_control控制文件，查找与“关闭”不同的状态来检测此情况。在这种情况下进行自动恢复。

1、直接kill掉postgres主进程

2、查看控制文件Database cluster state状态，没有发生变化

pg_controldata -D /usr/local/pgsql/data/ |grep state
--------
Database cluster state:               in production

3、启动数据库，查看日志

pg_ctl -D /usr/local/pgsql/data/ start

 可知故障后，数据库从Latest checkpoint's REDO location开始恢复数据

正常关闭后恢复

1、记录当前的lsn

SELECT pg_current_wal_insert_lsn();

pg_current_wal_insert_lsn
---------------------------
3/8B0000A0
(1 row)

2、正常关闭数据库

 pg_ctl -D /usr/local/pgsql/data/ stop

3、查看控制文件Database cluster state状态，可知正确记录了关闭状态

pg_controldata -D /usr/local/pgsql/data/ |grep state

Database cluster state:               shut down

4、查看wal日志, 拥有最终检查点的唯一记录（CHECKPOINT_SHUTDOWN）

 /usr/local/pgsql/bin/pg_waldump -p /usr/local/pgsql/data/pg_wal/ -s 3/8B0000A0  00000001000000030000008B

rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 3/8B0000A0, prev 3/8B000028, desc: RUNNING_XACTS nextXid 58215 latestCompletedXid 58214 oldestRunningXid 58215
rmgr: XLOG        len (rec/tot):    114/   114, tx:          0, lsn: 3/8B0000D8, prev 3/8B0000A0, desc: CHECKPOINT_SHUTDOWN redo 3/8B0000D8; tli 1; prev tli 1; fpw true; xid 0:58215; oid 34053; multi 1; offset 0; oldest xid 479 in DB 1; oldest multi 1 in DB 12723; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown
pg_waldump: fatal: error in WAL record at 3/8B0000D8: invalid record length at 3/8B000150: wanted 24, got 0

5、再次启动数据库，可知数据库正常启动，无恢复操作