我们已经熟悉了buffer cache的结构（共享内存的主要对象之一），并得出结论，要在所有RAM内容丢失后发生故障后恢复，必须保留预写日志（WAL）。
我们上次中断的地方尚未解决的问题是，我们不知道在恢复期间从哪里开始播放WAL记录。从头开始，这是不可行的：不可能从服务器启动时保留所有WAL记录-这可能既需要巨大的内存，又要很长的恢复时间。我们需要找到一个点，并且可以从该位置开始恢复（并相应地安全删除所有先前的WAL记录）。这就是我们要讲的检查点。
检查点
检查点必须具备哪些特点呢？ 我们必须确保所有从检查点开始的WAL记录都将应用于刷新到磁盘的页面。如果不是这种情况，则在恢复期间，我们可能从磁盘上读取一个过旧的页面版本，对其应用WAL记录，这样做会不可逆转地损害数据。
我们如何获得检查点？ 最简单的选择是不时暂停系统工作，并将缓冲区的所有脏页和其他高速缓存刷新到磁盘。（请注意，仅写入页面，而不从高速缓存中逐出页面）这些点将满足上述条件，但是时而连续"死亡"一段时间的系统，没有人会满意。
实际上这有点复杂：检查点从一个点变成一个间隔。首先，我们启动一个检查点。之后，我们悄悄地将脏缓冲区刷新到磁盘上，而不会中断工作或在任何可能的情况下导致峰值负载。
当所有在检查点开始时变脏的缓冲区都在磁盘上时，该检查点被视为已完成。现在（但不是更早），我们可以使用开始时间作为开始恢复的时间。而且我们不再需要到现在为止创建的WAL记录。
一个被称作检查点进程的后台进程执行检查点。
写入脏缓冲区的持续时间由checkpoint_completion_target参数定义。它显示了写入完成后两个相邻检查点之间的时间比例。默认值为0.5（如上图所示），即两次检查之间的写入时间占一半。通常，此值增加到1.0，以实现更高的均匀性。
让我们更详细地看看执行检查点时会发生什么。
首先，检查点将XACT缓冲区刷新到磁盘。由于它们很少（只有128个），因此它们会立即被写入。
然后，主要任务开始：从缓冲区高速缓存中刷新脏页。正如我们已经提到的，由于缓冲区高速缓存的大小可能很大，因此无法立即刷新所有页面。因此，buffer cache中所有当前脏的页面都用位于header中的特殊标志标记。
然后，检查点进程遍历所有缓冲区，并将标记的缓冲区刷新到磁盘。这里需要提醒你，页面不会从高速缓存中逐出，而只会写入磁盘。因此，你不必关注缓冲区的使用计数或是否被pin。
自然，在执行检查点时，buffer cache中的页面仍会继续被更新。但是不会标记新的脏缓冲区，并且检查点进程不会将它们写入磁盘。
在工作结束时，该过程将创建检查点末尾的WAL记录。该记录包含检查点开始时间的LSN。由于检查点启动时不会向WAL写入任何内容，因此任何日志记录都可以位于此LSN上。
此外，最后完成的检查点的指示在$PGDATA/global/pg_control文件中更新。在检查点完成之前，pg_control指向上一个检查点。
为了观看检查点的工作，让我们创建一个表。它的页面将进入buffer cache并称为脏页：
=> CREATE TABLE chkpt AS SELECT * FROM generate_series(1,10000) AS g(n);
=> CREATE EXTENSION pg_buffercache;
=> SELECT count(*) FROM pg_buffercache WHERE isdirty;
count
-------
78
(1 row)
让我们记住当前的WAL位置：
=> SELECT pg_current_wal_insert_lsn(); pg_current_wal_insert_lsn --------------------------- 0/3514A048 (1 row)
现在，让我们手动执行检查点，以确保高速缓存中不留任何脏页（正如我们已经提到的，可以出现新的脏页，但是在上述情况下，执行检查点时没有更改）：
=> CHECKPOINT;
=> SELECT count(*) FROM pg_buffercache WHERE isdirty;
count
-------
0
(1 row)
让我们看一下检查点在WAL中的体现：
=> SELECT pg_current_wal_insert_lsn(); pg_current_wal_insert_lsn --------------------------- 0/3514A0E4 (1 row)
postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/3514A048 -e 0/3514A0E4 rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/3514A048, prev 0/35149CEC, desc: RUNNING_XACTS nextXid 101105 latestCompletedXid 101104 oldestRunningXid 101105 rmgr: XLOG len (rec/tot): 102/ 102, tx: 0, lsn: 0/3514A07C, prev 0/3514A048, desc: CHECKPOINT_ONLINE redo 0/3514A048; tli 1; prev tli 1; fpw true; xid 0:101105; oid 74081; multi 1; offset 0; oldest xid 561 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 101105; online
在这里看到两个记录。最后一个是检查点完成的记录（CHECKPOINT_ONLINE）。在单词“ redo”之后输出检查点开始的LSN，此位置对应于在检查点开始时间的最后一个WAL记录。
我们将在控制文件中找到相同的信息：
postgres$ /usr/lib/postgresql/11/bin/pg_controldata -D /var/lib/postgresql/11/main | egrep 'Latest.*location' Latest checkpoint location: 0/3514A07C Latest checkpoint's REDO location: 0/3514A048
恢复
现在，我们准备更准确地陈述上一篇文章中提及的恢复算法。
如果postgresql server出现故障，则在随后的启动中，启动过程会通过查看pg_control文件来查找与“shutdown”状态不同的状态。在这种情况下，将执行自动恢复。
首先，恢复过程将从pg_control文件读取检查点开始位置。（要完成此操作，如果backup_label文件可用，那么将从那里读取检查点记录-从备份中还原这是必需的，但这是另一个系列的主题。）
然后，恢复过程将从找到的位置开始读取WAL，并将WAL记录逐一应用于页面（如果有需要，正如我们上次讨论的那样）。
最后，all unlogged tables are emptied by their initialization forks.。
这是启动过程完成的工作，检查点进程立即执行检查点以保护磁盘上已还原的状态。
我们可以通过强制在immediate模式下关闭来模拟故障。
student$ sudo pg_ctlcluster 11 main stop -m immediate --skip-systemctl-redirect
（这里需要--skip-systemctl-redirect选项，因为我们使用安装在Ubuntu上的PostgreSQL。它由pg_ctlcluster命令控制，该命令实际上调用systemctl，而后者又调用pg_ctl。但是--skip-systemctl-redirect选项使我们无需systemctl即可执行操作并保留重要信息。）
让我们检查集群的状态：
postgres$ /usr/lib/postgresql/11/bin/pg_controldata -D /var/lib/postgresql/11/main | grep state Database cluster state: in production
启动时，PostgreSQL知道发生了故障，需要恢复。
student$ sudo pg_ctlcluster 11 main start postgres$ tail -n 7 /var/log/postgresql/postgresql-11-main.log 2019-07-17 15:27:49.441 MSK [8865] LOG: database system was interrupted; last known up at 2019-07-17 15:27:48 MSK 2019-07-17 15:27:49.801 MSK [8865] LOG: database system was not properly shut down; automatic recovery in progress 2019-07-17 15:27:49.804 MSK [8865] LOG: redo starts at 0/3514A048 2019-07-17 15:27:49.804 MSK [8865] LOG: invalid record length at 0/3514A0E4: wanted 24, got 0 2019-07-17 15:27:49.804 MSK [8865] LOG: redo done at 0/3514A07C 2019-07-17 15:27:49.824 MSK [8864] LOG: database system is ready to accept connections 2019-07-17 15:27:50.409 MSK [8872] [unknown]@[unknown] LOG: incomplete startup packet
日志中报告了需要恢复：数据库系统未正确关闭； 自动恢复正在进行中 然后在«redo starts at»位置开始播放WAL记录，并在可能获取下一个WAL记录的同时继续播放。这样就可以在«redo done at»位置完成恢复，并且DBMS开始与客户端一起工作（数据库系统已准备好接受连接）。
在服务器正常关闭时会发生什么？ 要将脏页刷新到磁盘，PostgreSQL断开所有客户端的连接，然后执行最终检查点。
让我们记住当前的WAL位置：
=> SELECT pg_current_wal_insert_lsn(); pg_current_wal_insert_lsn --------------------------- 0/3514A14C (1 row)
现在，我们以常规方式关闭：
student$ sudo pg_ctlcluster 11 main stop
检查集群状态：
postgres$ /usr/lib/postgresql/11/bin/pg_controldata -D /var/lib/postgresql/11/main | grep state Database cluster state: shut down
而且WAL具有最终检查点（CHECKPOINT_SHUTDOWN）的唯一记录：
postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/3514A14C rmgr: XLOG len (rec/tot): 102/ 102, tx: 0, lsn: 0/3514A14C, prev 0/3514A0E4, desc: CHECKPOINT_SHUTDOWN redo 0/3514A14C; tli 1; prev tli 1; fpw true; xid 0:101105; oid 74081; multi 1; offset 0; oldest xid 561 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown pg_waldump: FATAL: error in WAL record at 0/3514A14C: invalid record length at 0/3514A1B4: wanted 24, got 0
重新启动实例：
student$ sudo pg_ctlcluster 11 main start
后台写
如我们所知，检查点是将脏页从buffer cache刷新到磁盘的过程之一。但这不是唯一的。
如果后端进程需要从缓冲区刷新页面，但是该页面含有脏数据，则该进程将不得不自行将页面写入磁盘。这种情况并不好，因为它需要等待-在后台异步完成写入会更好。
因此，除了检查点进程外，还存在后台写进程（也称为bgwriter或仅称为writer）。该进程使用与驱逐技术相同的算法来搜索缓冲区。他们有两个区别。
1.后台写进程使用自己的指针，而不是指向«next victim»的指针。自己的指正可以在«next victim»的指针之前，但是永远不能在它之后。 2.遍历缓冲区时，使用计数不会减少。
被写出的buffer要满足以下条件:
·包含脏的数据
·没有被pin住（pin计数为0）
·使用计数为0
因此，后台写过程先于eviction，找到很可能很快被逐出的缓冲区。理想的情况是，后台写必须能够检测到他们选择的缓冲区可以被使用，而不会浪费写入时间。
调优
通常根据以下推理来设置检查点。
首先，我们需要确定在两个检查点之间可以负担多少数量的WAL记录（以及我们可以接受的恢复时间）。越多越好，但是出于明显的原因，该值是有限的。
然后，我们可以计算出在正常负载下生成此数量的wal所需的时间。我们已经讨论了如何执行此操作（我们需要记住WAL中的位置，并从另一个位置中减去一个）。
接着是检查点之间的通常间隔。设置checkpoint_timeout参数。默认值为5分钟，显然太短；通常会增加到半个小时。
但是有可能（甚至可能）有时负载会比平时更高，并且在参数指定的时间内会生成过多的WAL记录。在这种情况下，希望更频繁地执行检查点。为此，我们在max_wal_size参数中指定允许的WAL文件大小。如果实际量更多，则服务器将启动计划外的检查点。
服务器需要保留从最后一个完成的检查点开始的WAL文件以及当前检查点期间累积的文件。因此，可以将总数量估算为一个检查点周期中的数量乘以（1 + checkpoint_completion_target）。在版本11之前，我们应该乘以（2 + checkpoint_completion_target），因为PostgreSQL还保留了最后一个检查点中的文件。
因此，大多数检查点都按计划执行：每个checkpoint_timeout时间单位一次。但是在负载增加时，达到max_wal_size的数量时，检查点执行的频率会更高。
重要的是要理解可以超过max_wal_size参数的值：
·max_wal_size参数的值仅是理想值，而不是严格的限制。实际可能超过该值。
·server不能擦除尚未通过复制槽传递、或尚未归档的的wal文件，
可以通过min_wal_size参数指定最小值。
仅在调整检查点时才调整后台写才有意义。
后台写一次最多写bgwriter_lru_maxpages个页，在下一次写之前会根据bgwriter_delay的值sleep一段时间。
默认值为：bgwriter_delay = 200毫秒，bgwriter_lru_maxpages = 100。
如果根本找不到脏缓冲区（也就是说，系统中什么也没有发生），则它“进入休眠状态”。
监控
你需要根据监控结果来调优检查点进程和后台写。
如果wal数量太多，参数checkpoint_warning会输出警告提醒，默认值是30秒，我们需要将其调整到checkpoint_timeout的值。
参数log_checkpoints可以将检查点信息写入log。默认是不开启
=> ALTER SYSTEM SET log_checkpoints = on; => SELECT pg_reload_conf();
现在，让我们更改数据中的某些内容并执行检查点。
=> UPDATE chkpt SET n = n + 1; => CHECKPOINT;
在看看log文件的内容：
postgres$ tail -n 2 /var/log/postgresql/postgresql-11-main.log 2019-07-17 15:27:55.248 MSK [8962] LOG: checkpoint starting: immediate force wait 2019-07-17 15:27:55.274 MSK [8962] LOG: checkpoint complete: wrote 79 buffers (0.5%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.013 s, total=0.025 s; sync files=2, longest=0.011 s, average=0.006 s; distance=1645 kB, estimate=1645 kB
我们可以在此处看到写入了多少缓冲区，在检查点之后更改了WAL文件集，执行检查点花费了多长时间以及相邻检查点之间的距离（以字节为单位）。
但是，最有用的信息可能是pg_stat_bgwriter视图中检查点和后台写进程的统计信息。
=> SELECT * FROM pg_stat_bgwriter \gx -[ RECORD 1 ]---------+------------------------------ checkpoints_timed | 0 checkpoints_req | 1 checkpoint_write_time | 1 checkpoint_sync_time | 13 buffers_checkpoint | 79 buffers_clean | 0 maxwritten_clean | 0 buffers_backend | 42 buffers_backend_fsync | 0 buffers_alloc | 363 stats_reset | 2019-07-17 15:27:49.826414+03
其中：
·checkpoints_timed--按计划（到达checkpoint_timeout时）。
·checkpoints_req--按需（包括在达到max_wal_size时执行的检查）。该值越大，表明检查点发生的越频繁。
以下是有关写入页数的重要信息：
·buffers_checkpoint--通过检查点。
·buffers_backend--通过后端进程。
·buffers_clean--通过后台写进程。
在一个经过良好调整的系统中，buffers_backend的值必须小于buffers_checkpoint和buffers_clean的总和。
参数maxwrite_clean的值也将有助于调整后台写。它显示由于超出bgwriter_lru_maxpages的值而使进程停止了多少次。
可以在重置收集的统计信息：
=> SELECT pg_stat_reset_shared('bgwriter');
原文地址：https://habr.com/en/company/postgrespro/blog/494464/