在學(xué)習(xí)PostgreSQL的過程中，很容易陷入一種情況，貌似都懂，一問就含糊，今天我就來捋一捋那團(tuán)亂麻。

postgresql 啟動(dòng)源于守護(hù)進(jìn)程，其功能強(qiáng)大，主管比如執(zhí)行恢復(fù)、初始化共享數(shù)據(jù)結(jié)構(gòu)/內(nèi)存空間，以及啟動(dòng)強(qiáng)制和可選的進(jìn)程。

PostgreSql 在啟動(dòng)后，就開始接受客戶的訪問，下圖演示了一個(gè)客戶如何申請(qǐng)連接，由守護(hù)進(jìn)程來分配一個(gè)子進(jìn)程，然后來服務(wù)于客戶的方式。

當(dāng)有成千上萬的用戶要讀取數(shù)據(jù)庫中的數(shù)據(jù)，并且想更高速度度的讀取，那就會(huì)牽扯到PG中的內(nèi)存系統(tǒng)，PG的內(nèi)存系統(tǒng)中，客戶與backend process來進(jìn)行交互，而backend process 會(huì)與PG的共享buffer中，而與其他數(shù)據(jù)庫不同的地方是，PG的內(nèi)存并不會(huì)和其他的三家的數(shù)據(jù)庫一樣，他要求的本身的buffer 的設(shè)置不會(huì)特別大(相對(duì)于其他三家的)，他的設(shè)計(jì)中還要利用LINUX 系統(tǒng)的緩沖系統(tǒng)，在數(shù)據(jù)的讀取上并不會(huì)引起任何問題，速度上也會(huì)有保障。

除了這兩種級(jí)別的緩存之外，我們還可以使用磁盤控制器緩存、磁盤驅(qū)動(dòng)器緩存等等。

上面基本上在關(guān)注與數(shù)據(jù)庫的讀操作，關(guān)于寫操作中的一個(gè)問題就是大量數(shù)據(jù)的更改插入，數(shù)據(jù)是否馬上會(huì)進(jìn)行刷盤用戶對(duì)表數(shù)據(jù)進(jìn)行大量更改并發(fā)提交的情況下，不會(huì)馬上對(duì)底層數(shù)據(jù)文件執(zhí)行寫操作。這可能只會(huì)導(dǎo)致確保提前寫日志(WAL)文件與WAL緩沖區(qū)保持同步。那怎么來保證事務(wù)的持久性的問題和事務(wù)的原子性的問題，WAL 日志的重要的作用就是，保證系統(tǒng)的高性能下的AD功能，并讓數(shù)據(jù)最終一致在數(shù)據(jù)文件中。

通過 buffercache 和 oid2name 兩個(gè)命令可以看到目前的數(shù)據(jù)庫的buffer到底有那些數(shù)據(jù)庫已經(jīng)在內(nèi)存中。

當(dāng)然如果想關(guān)心一下，用戶表的buffer讀取的數(shù)據(jù)塊的浮動(dòng)可以將上的查詢保存在一個(gè)表里面，并輔以時(shí)間，這樣你就可以繪制出一個(gè)用戶表的burfer的周期表。(能干什么自己想想，很有意思的)

SELECT  
c.relname,  
count(*) AS buffers  
FROM pg_class c  
JOIN pg_buffercache b  
ON b.relfilenode=c.relfilenode  
INNER JOIN pg_database d  
ON (b.reldatabase=d.oid AND d.datname=current_database())  
WHERE c.relname NOT LIKE 'pg%' GROUP BY c.relname ORDER BY 2 DES 

然后我們就到了內(nèi)存與磁盤的交換，checkpoint，如

數(shù)據(jù)在內(nèi)存中也不能一直寄存，需要落盤，這就牽扯到下一步checkpoint，檢查點(diǎn)，檢查點(diǎn)是一個(gè)強(qiáng)制的過程，在PG中數(shù)據(jù)總是以數(shù)據(jù)塊寫入和讀取的，無論這個(gè)塊的數(shù)據(jù)是否占滿8K，讀取的時(shí)候也是以塊為單位進(jìn)行讀取，

用戶在緩沖區(qū)中進(jìn)行了更改，緩沖區(qū)與物理磁盤的數(shù)據(jù)文件不一致，該緩沖區(qū)的數(shù)據(jù)就是臟的，checkpoint的作用就是要將這些已經(jīng)確認(rèn)改變的數(shù)據(jù)寫入到數(shù)據(jù)的文件的過程。相關(guān)的所有的數(shù)據(jù)頁和索引頁都會(huì)進(jìn)行更新，同時(shí)將這個(gè)頁面標(biāo)記OK。

這樣的方式可以讓HEAP PAGE 和 INDEX PAGE 在這個(gè)checkpoint之前的頁面都刷到磁盤的數(shù)據(jù)文件中。那么我可以理解的是，如果此時(shí)數(shù)據(jù)庫沒有任何的其他的手段，此時(shí)斷電，那CHECKPOINT 之后的數(shù)據(jù)就會(huì)丟失(實(shí)際情況當(dāng)然不會(huì))，這也就是redo，重做日志要檢查checkpoint點(diǎn)的問題，他要確定從哪里開始重做

checkpoint 有三個(gè)參數(shù)，checkpoint_segments, checkpoint_timeout, 和checkpoint_completion_target.(PG 9X)

三個(gè)參數(shù)前兩個(gè)屬于湊夠多少wal 才開始 checkpoint, 如果這個(gè)長時(shí)間沒有checkpoint 那就根據(jù)第二個(gè)參數(shù) checkpint_timeout 來根據(jù)時(shí)間來進(jìn)行checkpoint，當(dāng)然這樣做的后果是，如果某個(gè)階段數(shù)據(jù)量比較大，I/O就會(huì)出現(xiàn)消耗較高的情況，那第三個(gè)參數(shù)，checkpoint_completion_target就啟動(dòng)作用，讓這個(gè)突發(fā)的情況，稍微的緩解，拉長這個(gè)寫入的時(shí)間，讓I/O系統(tǒng)不會(huì)那么的忙。

而當(dāng)前PG11 中的與checkpoint的有關(guān)的參數(shù)不在有checkpoint_segments，換來的是max_wal_size ，要不超過設(shè)定時(shí)間去checkpoint 要不就是超過 max-wal-size 來進(jìn)行 checkpoint，感覺這樣設(shè)置比較合理，如果使用上面的方法，其實(shí)使用一個(gè)函數(shù)，就可以讓PG的checkpoint紊亂，甚至可能會(huì)宕機(jī)(使壞的方法是就算了)

最后要在wal log 里面結(jié)束此次的捋一捋的活動(dòng)。當(dāng)我們對(duì)數(shù)據(jù)進(jìn)行更改時(shí)，不會(huì)立即將更改寫入數(shù)據(jù)文件，對(duì)緩沖區(qū)中的塊進(jìn)行更改，并將這些更改的記錄寫入WAL緩沖區(qū)，所以wal 才是保證系統(tǒng)運(yùn)行效率與數(shù)據(jù)安全之間的一個(gè)妥協(xié)的產(chǎn)品。

select * from pg_walfile_name(pg_current_wal_lsn()); 

如何知道當(dāng)前你正在操作的那個(gè) wal 日志。(PG11)

SELECT pg_xlogfile_name(pg_current_xlog_location()); (PG 9X) 

使用過PG的人都知道PG 沒有 DOUBLE WRITE 這個(gè)功能其實(shí)(DW是那個(gè)數(shù)據(jù)庫的特征就不在說了)，F(xiàn)ULL PAGE 來支持的，到底FULL PAGE 是用了什么方法，躲避了 DW ，保證了數(shù)據(jù)的完全。當(dāng)然這也是要消耗系統(tǒng)的I/O性能的，同時(shí)也可以通過細(xì)調(diào)某些參數(shù)來緩解某些性能問題。

在這之前我們說說為什么會(huì)有這樣的情況，數(shù)據(jù)頁如果是8KB的情況下，那硬件和系統(tǒng)能一次將這些信息都寫到磁盤， 答案當(dāng)然是 不 不 不

LINUX 一次是 4KB ，那硬件系統(tǒng)就更不知道是 4KB 還是 8KB ，所以如果系統(tǒng)CRASH 了，怎么辦你明明寫了8KB 人家寫了 4KB 就斷了，剩下了4KB 找誰，丟了，那啟動(dòng)后，物理頁面損壞，誰給修，你給修。所以不同的數(shù)據(jù)庫就各顯神通，要把這塊給彌補(bǔ)了。

PG 這里就是 FULL PAGE 主要是操作的是將PostgreSQL服務(wù)器會(huì)在檢查點(diǎn)后第一次修改該頁時(shí)將每個(gè)磁盤頁的全部內(nèi)容寫入WAL。這樣的好處是如果在下一次checkpoint的之前幾期crash了，則我們?cè)赪AL 中有所有的數(shù)據(jù)頁面，通過這些數(shù)據(jù)頁面就可以將數(shù)據(jù)恢復(fù)。不好的地方就是將數(shù)據(jù)寫入到了WAL日志中，多寫數(shù)據(jù)是一定要影響性能的。

這里如果我們提高checkpoint的頻率，會(huì)從邏輯的角度來抵消FULL page的影響，而如果縮小checkpoint的頻率，那可能就會(huì)人為的創(chuàng)造出一個(gè)大的突發(fā)寫入，那上邊的一個(gè)參數(shù)就的調(diào)整了，那個(gè)參數(shù)呢，我想你已經(jīng)知道了。

但結(jié)果是我不會(huì)關(guān)閉FULL PAGE 因?yàn)樾阅芘c數(shù)據(jù)的安全性比較，那個(gè)應(yīng)該優(yōu)先，不言而喻。

以上內(nèi)容由東方瑞通資深講師 Austin供稿，13年專業(yè)DBA經(jīng)驗(yàn)，曾任互聯(lián)網(wǎng)金融公司Senior DBA、500強(qiáng)制藥企業(yè)Senior DBA，精通Mysql、PostgreSQL、Mongo DB、SQLServer。