POSTGRESQL中WAL機制的示例分析

這篇文章主要為大家展示了“POSTGRESQL中WAL機制的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“POSTGRESQL中WAL機制的示例分析”這篇文章吧。

POSTGRESQL 做作為類似MYSQL BINLOG + UNDO LOG ， ORACLE REDO LOG ，的存在，是POSTGRESQL 本身在防止數據丟失，備份數據，數據復制，數據庫CRASH 后的恢復數據等等功能于一身。

還是那句話，如果汽車的三大件，發動機，變速箱，底盤，那 POSTGRESQL WAL 想當于汽車的 底盤，它集合了數據庫的安全性，性能，穩定性等等重要特性于一身。

如果詳細的解釋WAL 到底具體的作用，它一個歷史日志，記錄數據庫系統中的所有更改和操作，以確保沒有任何數據由于故障而丟失，例如電源故障或其他導致服務器崩潰的服務器故障。由于日志包含了關于已經執行的每個事務的足夠信息，所以數據庫服務器應該能夠通過在事務日志中重播更改和操作來恢復數據庫中的數據。

我們來大致跟著WAL 的流程走一遍來（其實很多數據庫都是這樣，MYSQL ， SQL SERVER , ORACLE），只不過生成的形式，文件的格式，以及使用的方式，等等有所不同，但他們一直的目標就是數據不丟失。

首先在確認一點的是，任何的數據操作都是在內存中完成的，和磁盤上的文件沒有什么關系，要說關系就是數據的持久化，duration。

上圖粗糙的描述了，一個數據的寫入（寫入包含INSERT ,UPDATE，其實DELETE 從某種角度也是數據的寫入），那在數據寫入到內存中，和WAL LOG 是一項事務，（其實LOG 也是有buffer的，主要為性能）。這里我們忽略LOG BUFFER，直接認為，上面的操作是一個事務。 然后數據落到日志后，這個操作就會返回成功，后面的就是dirty page 刷入到磁盤的過程，這其實是不著急的，（這里不著急不是說等一個小時），在進行check point 后，數據就會落入到數據PAGE，數據就持久化了， 大致就是這樣一個流程。

那這里有一個問題，就是在數據dirty page 沒有刷新到DATA PAGE，而機器就OVER 了，或者OOM，那下次機器在啟動后，數據頁面沒有數據，那數據丟失了嗎？ 沒有，因為有WAL，為什么數據頁面沒有數據，因為dirty page 沒有check point ,而系統啟動后，通過檢查check point點，獲知check point 點的位置，而在此位置后的的 dirty page 的操作都在wal中存儲，所以直接執行 check point 點后的 wal 你的數據就回來了，crash data recovery.  You job is done.

這就是這個WAL 的最重要的功能，之一。

我們可以通過下面的命令來確認當前的wal 落到到那個wal 文件中

另外在PG 11 之前的版本會存儲兩個 checkpoint的位置，一個是最后一次的checkpoint的位置，另一個是再一次要進行的checkpiont的位置，而11,則只記錄最近一次的checkpoint的記錄號。

同時我們通過pg_controldata 命令可以獲得關于當前PG 在WAL 中的詳細信息，甚至利用的好，還可以來獲知一些關系性能方面的事情。（具體怎么干，找時間能寫一篇）

同時 DBA 也可以手動進行 WAL 的新日志的生成，切斷現在的WAL日志，進行需要的維護。

同時，PG 也和其他數據庫一樣，例如MYSQL mysqlbinlog 命令來解析BINLOG文件，PG 的 pg_waldump 也可以將wal 文件翻譯成人類可讀的格式。

以上是“POSTGRESQL中WAL機制的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！