www.876873.xyz

Anchor LSN（也就是 pg_start_backup 返回的 Start LSN）绝对不是 Checkpoint 记录的“下一个 LSN”。它在物理坐标上，完完全全、精准无误地等于那个 REDO LSN 本身！

我们直接在内存和磁盘之间拉一根时间轴，用最严谨的 C 语言内核逻辑，放慢这几秒钟的底层物理动作，看看这个“锚点”到底是怎么打下去的：

物理级慢动作推演：时空锚点的铸造过程

当后端进程调用 RequestCheckpoint(CHECKPOINT_FORCE | CHECKPOINT_WAIT) 后，Checkpointer（检查点进程）被唤醒，真正的内核动作按以下 5 步严格执行：

第 1 步：标记“绝对安全水位”（确立 REDO LSN）

• 物理事实： Checkpointer 醒来的第一件事，不是立刻去刷盘！而是先看一眼当前系统全局的 WAL 写入位置。它把此刻 WAL 日志流的最末端位置记录下来。
• 物理定调： 这个位置，就是 REDO LSN！它的物理含义是：“从这一微秒开始，任何对数据页的修改，都会产生新的 WAL 记录排在这个 LSN 之后。而在此之前的所有修改，我都将在接下来的刷盘动作中，全部压入物理磁盘。”

第 2 步：漫长的 I/O 倾泻（脏页刷盘）

• 物理事实： 确立了 REDO LSN 后，Checkpointer 开始遍历 shared_buffers，把成百上千兆的脏页通过 fsync() 疯狂刷入物理磁盘。
• 并发的危机： 这个刷盘过程可能长达几十秒甚至几分钟。请注意，在这几十秒里，业务并没有停！ 业务依然在疯狂写入数据，生成大量的、排在 REDO LSN 后面的 WAL 日志（这里面就包含了我们上一回合说的 FPW 全页写入日志）。

第 3 步：写入 Checkpoint 记录 (XLOG_CHECKPOINT_ONLINE)

• 物理事实： 脏页终于全部落盘完毕！此时，Checkpointer 会在当前 WAL 日志流的最末端（此时 WAL 已经往前跑了很远了），插入一条名为 XLOG_CHECKPOINT_ONLINE 的物理记录。
• 结构体封装： 在这条 XLOG_CHECKPOINT_ONLINE 记录的内部（Payload）中，Checkpointer 会把第 1 步确立的那个 REDO LSN 给严严实实地包进去。

第 4 步：更新控制文件 (pg_control)

• 物理事实： Checkpointer 打开系统最核心的 $PGDATA/global/pg_control 控制文件。
• 指针更新： 它将 pg_control 里的 checkPoint 指针更新为刚才第 3 步写入的那条 XLOG_CHECKPOINT_ONLINE 记录的物理位置。同时，也把 REDO LSN 更新进控制文件里。

第 5 步：锚点提取与返回 (The Anchor Extraction)

• 物理事实： 一直被挂起等待的 pg_start_backup() 函数终于收到了 Checkpointer 的“执行完毕”信号。
• 精准提取： pg_start_backup() 去读取 pg_control 控制文件，提取出里面的 REDO LSN。然后，它将这个 REDO LSN 转换为字符串（比如 0/1A2B3C48），返回给客户端 pg_probackup。
• 终极断言： 这个返回的 REDO LSN，就是你所说的 Anchor LSN（Start LSN）。

---

面试场上的降维打击：为什么要用 REDO LSN 做锚点？

追问：“为什么 Start LSN 必须是 REDO LSN，而不能是 Checkpoint 记录的下一个 LSN？”

你可以极其笃定地用“物理防撕裂”的逻辑回答他：

“因为 Checkpoint 的刷盘动作是一个漫长的 I/O 过程。如果在刷盘的这几十秒内，业务修改了某个页面并生成了 WAL，这部分 WAL 记录是物理排在 REDO LSN 和 Checkpoint 记录之间的。

如果备份恢复时，我们从 Checkpoint 记录之后（也就是‘下一个 LSN’）开始重放，那我们就永远丢失了刷盘期间业务产生的那些 WAL 日志，数据库的底层数据页会发生不可逆的物理撕裂！

只有把锚点死死钉在 REDO LSN 上，在恢复时从 REDO LSN 开始向后重放所有的 WAL，才能完美覆盖备份期间发生的所有并发写入，达成绝对的物理一致性！”

这种级别的内核级推演，不仅逻辑严密，而且充满了 C 语言底层的暴力美学。