PostgreSQL DBA(20) - WAL full-page-write淺析

發(fā)布時(shí)間：2020-08-07 12:19:28 來(lái)源：ITPUB博客 閱讀：160 作者：husthxd 欄目：關(guān)系型數(shù)據(jù)庫(kù)

full-page-write

在T1，數(shù)據(jù)庫(kù)成功執(zhí)行checkpoint；
在T2，執(zhí)行DML語(yǔ)句，這時(shí)候相關(guān)的數(shù)據(jù)會(huì)寫(xiě)入到WAL中（此處忽略了WAL buffer）；
在T3，提交該事務(wù)；
在T4，bgwriter把dirty pages寫(xiě)入到Data file中，但在寫(xiě)入過(guò)程中機(jī)器出現(xiàn)故障導(dǎo)致Crash（如掉電等），出現(xiàn)了部分寫(xiě)的情況。
為了應(yīng)對(duì)這種情況，PG在T2寫(xiě)入WAL的時(shí)候，會(huì)把出現(xiàn)變化的page整頁(yè)寫(xiě)入到WAL中，而不僅僅是tuple data。在數(shù)據(jù)庫(kù)重啟執(zhí)行恢復(fù)的時(shí)候，在Redo point開(kāi)始回放WAL時(shí)，如發(fā)現(xiàn)XLOG Record是FPI（full-page-image），則整頁(yè)替換，通過(guò)這種機(jī)制解決了部分寫(xiě)的問(wèn)題。

二、full-page-write的代價(jià)

當(dāng)然這種機(jī)制不是免費(fèi)的，其主要的負(fù)面影響是寫(xiě)放大。
由于整頁(yè)寫(xiě)，不可避免的出現(xiàn)冗余數(shù)據(jù)；考慮這么一種情況：如果數(shù)據(jù)庫(kù)很繁忙，而且數(shù)據(jù)的熱點(diǎn)分散在不同的table上，同時(shí)checkpoint執(zhí)行間隔較短，那非常多的page就會(huì)通過(guò)full-page-write寫(xiě)入的WAL中，導(dǎo)致日志空間快速膨脹。在極端情況下，page“滿載”（基本沒(méi)有空閑空間）的情況下更新其中一條記錄都會(huì)導(dǎo)致整頁(yè)寫(xiě)入WAL。
關(guān)于這部分的機(jī)制和解決方案，參考資料中的《如何遏制PostgreSQL WAL的瘋狂增長(zhǎng)》有詳細(xì)論述。

三、參考資料

Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的瘋狂增長(zhǎng)
PostgreSQL 可靠性分析 - 關(guān)于redo block原子寫(xiě)