溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
在T1，數據庫成功執行checkpoint；
在T2，執行DML語句，這時候相關的數據會寫入到WAL中（此處忽略了WAL buffer）；
在T3，提交該事務；
在T4，bgwriter把dirty pages寫入到Data file中，但在寫入過程中機器出現故障導致Crash（如掉電等），出現了部分寫的情況。
為了應對這種情況，PG在T2寫入WAL的時候，會把出現變化的page整頁寫入到WAL中，而不僅僅是tuple data。在數據庫重啟執行恢復的時候，在Redo point開始回放WAL時，如發現XLOG Record是FPI（full-page-image），則整頁替換，通過這種機制解決了部分寫的問題。
當然這種機制不是免費的，其主要的負面影響是寫放大。
由于整頁寫，不可避免的出現冗余數據；考慮這么一種情況：如果數據庫很繁忙，而且數據的熱點分散在不同的table上，同時checkpoint執行間隔較短，那非常多的page就會通過full-page-write寫入的WAL中，導致日志空間快速膨脹。在極端情況下，page“滿載”（基本沒有空閑空間）的情況下更新其中一條記錄都會導致整頁寫入WAL。
關于這部分的機制和解決方案，參考資料中的《如何遏制PostgreSQL WAL的瘋狂增長》有詳細論述。
Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的瘋狂增長
PostgreSQL 可靠性分析 - 關于redo block原子寫
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
