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程式號為20079。checkpoint的程式號為20083，其父程式號為20079，即為postmaster。

checkpoint程式掛掉後，postmaster會殺掉所有backend程式，然後逐一恢復後臺程式，有點類似於系統被初始化後。可見此程式對資料一致保護的重要性。

因為資料庫系統要達到一個目的：即任何已經做過checkpoint的更改，不需要從WAL日誌中恢復。這大大加快了資料庫系統crash後的恢復速度。

在原始碼中，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), 下面粗體部分就是檢查點相關內容:

[postgres@rtdkm1pgs51 crm03]$ pg_controldata
pg_control version number: 922
Catalog version number: 201204301
Database system identifier: 6102292739623205626
Database cluster state: in production
pg_control last modified: Tue 02 Aug 2016 12:42:03 AM SGT
Latest checkpoint location: 1B5/22EDAD90
Prior checkpoint location: 1B5/22B04680
Latest checkpoint's REDO location: 1B5/22E00B88
Latest checkpoint's TimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/280729141
Latest checkpoint's NextOID: 2041882
Latest checkpoint's NextMultiXactId: 3017
Latest checkpoint's NextMultiOffset: 7041
Latest checkpoint's oldestXID: 95150957
Latest checkpoint's oldestXID's DB: 16600
Latest checkpoint's oldestActiveXID: 280729141
Time of latest checkpoint: Tue 02 Aug 2016 12:40:30 AM SGT
Minimum recovery ending location: 0/0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
Current wal_level setting: hot_standby
Current max_connections setting: 350
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

Postgres Checkpoint

相關文章