PostgreSQL checkpoint原理

今天来谈一下PostgreSQL 的checkpoint原理。检查点功能在现有流行的数据库中都具备。如Oracle,MySQL等,尤其是Oracle 对检查点功能的实现,非常完善。Oracle不仅有全局检查点,还有增量检查点,即非常著名的 “Incremental checkpoint”。虽然各大数据库实现的方式不同,但是主要目的都是一样的,都是为了缩短数据库恢复的时间。那么其实PG也有自己的检查点实现。

1.PG检查点的类型

Shutdown检查点:在PG实例shutdown时做的检查点

Recovery End检查点:在recovery 结束阶段做的检查点,类似于shutdown检查点,只不过在WAL恢复结束时发起。

Immediate检查点:不仅仅创建检查点,而且会马上做。这类请求一般在比较紧急的情况下,需要马上获取数据库一致状态的情况下。

Force检查点:即使没有xlog变更,也会做。请求这类检查点,往往只是想得到最近的checkpoint location而已。

上面几个检查点,会直接影响检查点的创建以及检查点的完成时机。

Wait检查点:检查点不会马上做,但会一直等待,直到检查点完成。

往往比较重要的一些操作,但不是非常紧急的,可以请求该类检查点。尤其是一些DDL操作,对数据一致性要求高于响应时间。

另外,还有一类检查点,这类检查只是作为logging的标识:

xlog检查点:由xlog的消耗引起,产生新xlog文件。

time检查点:由时间elapse引起。

flush检查点:当发起flush 所有pages时发起,包括那些不logging的表。

PG会根据目的以及不同时机,请求相应的检查点。

2.PG检查点的机理

checkpoint进程由postmaster负责创建。作为postmaster的子进程而存在,为几大重要的后台进程之一。

从下图中,可知postmaster进程号为2694。checkpoint的进程号为2696,其父进程号为2694,即为postmaster。

PostgreSQL checkpoint原理

checkpoint进程挂掉后,postmaster会杀掉所有backend进程,然后逐一恢复后台进程,有点类似于系统被初始化后。可见此进程对数据一致保护的重要性。

因为数据库系统要达到一个目的:即任何已经做过checkpoint的更改,不需要从WAL日志中恢复。这大大加快了数据库系统crash后的恢复速度。

在源码中,checkpoint相关的信息由一个结构体记录,放在共享内存段中:

PostgreSQL checkpoint原理

它保存了当前checkpoint 的pid,检查点起始位置,检查点完成位置以及检查点类型等信息。另外也维护了一个检查点队列。一般的检查点请求只是创建一个检查点位置,并放到队列中,并不会马上做,检查点调度由另外逻辑来控制。

checkpoint的位点是跟xlog的位置强相关的,其实就是WAL日志的位点。

每当检查完成之时,就必须要求此检查点前的数据更改或者脏页被写入物理磁盘,并持久化。

做检查点时大致可以分为两个过程:

1).遍历所有BUFFER,将当前时刻的所有DIRTY的块状态改为CHECKPOINT_NEEDED,来表示需要将这些脏块写出到磁盘。

注意这一步,还是在内存中完成的,并不涉及到磁盘操作。

2).刷物理文件,从缓存中将脏块fsync到磁盘。

这一步涉及到磁盘操作。将标记为CHECKPOINT_NEEDED的block写出到磁盘。

3).Checkpoint 本身也会被记录到XLOG中

上面讲到的检查点结构体内容以及长度等信息,会被刷出到xlog中。

4).更新控制文件

更新控制文件中的检查点信息到当前位置. 下面粗体部分就是检查点相关内容:

[postgres@db1 ~]$ pg_controldata  /opt/pgdata
 pg_control version number:            937   
 Catalog version number:              201306121
 Database system identifier:          6123041408807693241
 Database cluster state:              shut down         
 pg_control last modified:            Sun 17 May 2015 06:36:25 PM CST
Latest checkpoint location:          1F/9B9B2E20                   
 Prior checkpoint location:            1F/9B9B2DB8                   
 Latest checkpoint's REDO location:    1F/9B9B2E20                   
 Latest checkpoint's REDO WAL file:    000000010000001F0000009B     
 Latest checkpoint's TimeLineID:      1                             
 Latest checkpoint's PrevTimeLineID:  1                             
 Latest checkpoint's full_page_writes: on
 Latest checkpoint's NextXID:          0/15331854
 Latest checkpoint's NextOID:          91378
 Latest checkpoint's NextMultiXactId:  1
 Latest checkpoint's NextMultiOffset:  0
 Latest checkpoint's oldestXID:        1799
 Latest checkpoint's oldestXID's DB:  1
 Latest checkpoint's oldestActiveXID:  0
 Latest checkpoint's oldestMultiXid:  1
 Latest checkpoint's oldestMulti's DB: 1
 Time of latest checkpoint:            Sun 17 May 2015 06:36:25 PM CST
Fake LSN counter for unlogged rels:  0/1
 Minimum recovery ending location:    0/0
 Min recovery ending loc's timeline:  0
 Backup start location:                0/0
 Backup end location:                  0/0
 End-of-backup record required:        no
 Current wal_level setting:            minimal
 Current max_connections setting:      100
 Current max_prepared_xacts setting:  0
 Current max_locks_per_xact setting:  64
 Maximum data alignment:              8
 Database block size:                  8192
 Blocks per segment of large relation: 131072
 WAL block size:                      8192
 Bytes per WAL segment:                16777216
 Maximum length of identifiers:        64
 Maximum columns in an index:          32
 Maximum size of a TOAST chunk:        1996
 Date/time type storage:              64-bit integers
 Float4 argument passing:              by value
 Float8 argument passing:              by value
 Data page checksum version:          0

------------------------------------华丽丽的分割线------------------------------------

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/4b21c05def959575adafb6fabe6b32b3.html