PostgreSQL之数据库恢复

前面我们了解到PostgreSQL的故障恢复与checkpoint、WAL密切有关。当数据库异常宕机，通过顺序的重放WAL段文件中从重做点（REDO point）开始的XLOG记录来进行数据库的恢复操作。

恢复流程

关于数据库的恢复过程，首先是在数据库启动的时候加载pg_control文件，通过pg_control文件中的State及Latest CheckPoint信息来决定是否需要重放以及从什么位置开始重放。

具体步骤描述如下：

1. PG数据库在启动的时候读取pg_control文件。如果State的值是’in production’，PG就会进入恢复模式，因为这个状态表示上一次是异常关闭；如果State的值是’shut down’，PG就会进行正常的启动模式。
2. PG读取pg_control文件中的Latest CheckPoint，Latest CheckPoint指定WAL段文件的地址，并以此获得重做点信息。如果Latest CheckPoint不可用，就会读Prior CheckPoint，如果两个重做点都不可用，就会放弃恢复过程。（在PG 11版本开始已经废弃Prior CheckPoint）
3. 相应的资源管理器从重做点开始有序读取并重放XLOG记录，一直到WAL日志中的最新日志点。如果XLOG记录重放且是一个备份块，不需要考虑当前LSN直接重写对应表的页面。相反，如果是一个非备份块的XLOG，只有当记录的LSN比对应表页面中的pg_lsn大，才会进行重放。

为什么需要对比LSN与页面中的pg_lsn

上述简单描述了数据库恢复的过程，那么对于非备份块，为什么需要对比LSN及对应页面的pd_lsn呢？
首先我们还是先看一下插入过程。

1. PG数据库往表TABLE_A中插入一条记录，并且在LSN_1位置写一条XLOG。
2. 后台写进程把TABLE_A的页面写到磁盘。这时，页面中的pd_lsn是LSN_1。
3. PG往TABLE_A中插入一条新的记录，并在LSN_2位置写一条XLOG。被修改的页面还没写到磁盘。

此时数据库异常关机重启，那么现在数据库就要进行恢复过程。

1. 恢复时，数据库根据Latest Checkpoint开始加载第一条XLOG，以及TABLE_A的页面，由于最早的XLOG记录LSN没有比TABLE_A的LSN大，因此不会进行重放。
2. 然后开始回放第二条XLOG，由于第二条XLOG对应的LSN比表中的LSN_1大，此时会进行回放操作。

因此，通过LSN的对比，可以保证数据的一致性。