POSTGRESQL WAL 机制理解

最近和POSTGRESQL 较劲的多，如果能更多的理解POSTGRESQL 的工作原理，并且深入分析，对日后的管理和适用会比较有帮助，多学点是没有坏处的，并且POSTGRESQL 未来的前景还是蛮看好的，废话不多讲。

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 文件翻译成人类可读的格式。

其实WAL 还有很多东西这里并没有提到，例如他的模式，及一些详细的配置，待续......