1.简介
去年我写了一篇关于 PostgreSQL 的时间线概念的博客，它对于执行时间点恢复 (PITR) 回到特定时间线和特定日志序列号 (LSN) 至关重要。但是我们还没有谈到其他一切都建立在 LSN 的基础上。今天在这篇博客中，我将描述LSN的意义
2.LSN和REDO
我们经常听到REDO这个词，它可能意味着一些事情，这取决于它所使用的上下文。如果用作REDO点，则表示自当前或上次检查点启动以来当前WAL记录的位置。此时数据库应开始恢复。
当REDO本身用作动词时，它指的是备用服务器的动作，它将读取通过流复制从主服务器发送的WAL内容，并实际回放这些动作。根据数据库操作，需要定义REDO的不同方式。这就是为什么在希帕姆。c源代码中，存在heap_redo和heap2_redo等函数。
LSN代表日志序列号，它基本上是指向WAL中某个位置的指针。它在PG内部表示为无符号64位值；在PG外部，它被表示为由斜线（/）分隔的2个十六进制数字，第一个数字是特定WAL文件的段ID，第二个数字是该段文件内的偏移量。
例如：
1/CF54A048也可以表示为单个值0x01CF54A048，其等于7773397064，这是PG内部用于计算或比较不同LSN值的整数。
根据该值，可以判断数据库的容量，LSN越大，数据库越大。
3.数据页头中的pd_lsn值
我一直在研究让多个 PostgreSQL 服务器共享一组数据存储的可行性。一台服务器可以读写，其余服务器只读。在只读服务器上，我在它们各自的集群文件夹中引入了一个临时存储空间，以临时保存它们想要从缓冲区管理器中弹出的任何数据块，以防主服务器尚未将数据刷新到共享存储空间。
在使用这种方法进行测试期间，我遇到了一个问题，即备用数据库可能面临共享存储和它们自己的临时空间中可能存在相同数据页但不同版本的情况。加载错误版本的页面可能会导致用户查询的输出不正确。
那么，我们如何解决这个问题呢？
每个缓冲区页标头中的 pd_lsn 参数指示“修改此页的最后一个 WAL LSN”。因此，通过简单地比较来自 2 个版本的数据页的 pd_lsn 值，我可以确保备用数据库始终读取正确的页面。
从某种意义上说，LSN 很重要，PG 的几乎每个 WAL 恢复功能都围绕 LSN 工作，在我自己的可行性研究中，LSN 在使共享备用更智能地从多个源加载数据块方面也发挥了重要作用。
