pg_basebackup -X stream 场景里，“专门发 WAL 的那条 walsender 进程” 单独拎出来，按 角色 → 为什么需要它 → 它怎么启动 → 它持续在干什么 → 它和数据文件那条怎么配合 → 出现问题时怎么看 这条逻辑线，完整讲透。

---

1）先定性：这条进程到底是什么

这条 walsender 是 源库服务端侧 的一个复制发送进程。
它不是 pg_basebackup 客户端本身，也不是“负责数据文件的那条 walsender”；它是在 -X stream 模式下，由 pg_basebackup 额外建立的 第二条 replication 连接 对应出来的发送进程，职责非常单一：持续把本次基础备份所需的 WAL 流式发给客户端。官方文档明确写明：-X stream 会“open a second connection to the server and start streaming the write-ahead log in parallel while running the backup”，因此需要两个 replication 连接。(PostgreSQL)

一句话先记住：

数据文件那条 walsender 负责 BASE_BACKUP 主流程；WAL 流这条 walsender 负责并行把 WAL 不断送给客户端。 (PostgreSQL)

---

2）为什么必须有这条“WAL 流 walsender”

因为 只拿数据文件，不足以形成一份可恢复的在线物理备份。
PostgreSQL 的在线基础备份本质上是：先拿一份文件级基础备份，再拿到从备份起点到备份结束点之间的 WAL，恢复时通过重放这些 WAL，把基础备份推进到一致状态。官方 PITR/continuous archiving 文档明确说明，文件系统级备份需要和 WAL 结合，恢复时依赖 WAL replay 才能回到一致状态。(PostgreSQL)

所以逻辑链是：

1. 在线备份期间，数据库还在继续写入、修改数据页。
2. 数据文件那条 walsender 发出去的只是某个时段内读取到的物理文件内容。
3. 这些文件单独看，不足以表达“最后一致状态”。
4. 必须拿到对应 WAL，恢复时重放，才能把这份基础备份补完整。(PostgreSQL)

因此，-X stream 下专门拉一条 WAL 流，并不是“为了加速”，而是为了 并行保证可恢复性。(PostgreSQL)

---

3）为什么 -X stream 要“单独再开一条连接”

因为 BASE_BACKUP 本身已经占着一条 replication 会话。
复制协议文档说明，physical replication walsender mode 下处理的是复制协议命令；pg_basebackup 的 BASE_BACKUP 就是在这条会话中执行的。与此同时，如果还要持续发送 WAL，官方选择的机制不是“把两类流量混在同一个会话里随便发”，而是 再开第二条 replication connection 专门做 WAL streaming。官方 pg_basebackup 文档直接写明了这个行为。(PostgreSQL)

这背后的架构意义很明确：

• 主备份通道：负责 BASE_BACKUP 生命周期、发送数据文件
• WAL 通道：负责实时把 WAL 往客户端送

这样分离后，职责边界很清晰，协议状态也更清楚。(PostgreSQL)

---

4）它是怎么被启动出来的

按顺序推演：

第一步：pg_basebackup 先建立主备份连接

这条连接对应“数据文件那条 walsender”，执行 BASE_BACKUP。pg_basebackup 通过 replication protocol 发起基础备份，这是官方定义。(PostgreSQL)

第二步：因为指定了 -X stream

客户端额外再建立一条 replication 连接。官方文档明确写的是第二条连接。(PostgreSQL)

第三步：服务端为这第二条连接分配一个 walsender

这个后端进入 physical replication walsender mode。复制协议文档说明，physical replication 模式下用 simple query protocol 接受复制命令。(PostgreSQL)

第四步：这条 walsender 进入 WAL streaming 发送状态

它随后按物理流复制协议，不断向客户端发 WAL 数据。复制协议文档将这类流程定义在 physical streaming replication protocol 中。(PostgreSQL)

所以你可以把它理解成：

pg_basebackup -X stream = 一个 BASE_BACKUP 会话 + 一个 WAL 流复制会话。 (PostgreSQL)

---

5）这条 WAL 流 walsender 的核心职责是什么

它的职责可以压缩成四个字：持续补血。

更展开一点，它负责的是：

5.1 持续跟踪备份期间产生的 WAL

在线备份不是静态拍照。备份开始后，前台业务还在提交事务，checkpoint 还在推进，数据页还在变化，WAL 也在不断生成。WAL 的存在本来就服务于 crash recovery 和 PITR；在线基础备份必须把这段 WAL 一起拿走。(PostgreSQL)

5.2 把这段 WAL 及时发给客户端

-X stream 的意义就在这里：不是等主备份结束后再去“补捞” WAL，而是边做 base backup，边并行送 WAL。官方文档对 -X stream 的描述就是并行 streaming WAL。(PostgreSQL)

5.3 降低“事后取 WAL 失败”的风险

和 -X fetch 相比，-X stream 不依赖“备份结束后，源库上所需 WAL 还在不在”。pg_basebackup 文档明确提醒，fetch 方式要求源库保留足够多的 WAL；如果在取走前已被 recycle，备份就会失败。与之相对，stream 是实时拿。(PostgreSQL)

5.4 让整份基础备份尽快接近“恢复所需材料齐备”

它不是独立创造一致性，而是把恢复所需的 WAL 持续搬到客户端，让基础备份在完成时，恢复材料已经基本到位。(PostgreSQL)

---

6）它和“数据文件那条 walsender”到底怎么配合

这是最关键的逻辑点。

数据文件那条 walsender

负责：

• 接 BASE_BACKUP
• 建立备份起点
• 等 start checkpoint
• 枚举/发送数据库文件和表空间
• 在结束时走 pg_backup_stop 一类收尾语义
• 在进度视图里对应 pg_stat_progress_basebackup 的那一行。(PostgreSQL)

WAL 流这条 walsender

负责：

• 不参与发送数据库文件
• 不主导 BASE_BACKUP 生命周期
• 专门沿另一条连接持续发 WAL
• 在 -X stream 模式下并行工作。(PostgreSQL)

你可以把两者想成：

一条管“备份主体”
一条管“恢复所需日志”

再直白一点：

没有数据文件那条 → 没有 base backup 主体
没有 WAL 流那条（在 -X stream 下）→ 主体可能拿到了，但恢复所需 WAL 不能并行就位

两条进程不是主从关系，而是 分工协作。(PostgreSQL)

---

7）这条进程在运行时“持续在干什么”

从逻辑上，它一直在做这件事：

守着 WAL 生产端，把“本次备份需要的 WAL 范围”尽快、连续、稳定地输送给客户端。

这件事可以拆成三个运行特征。

7.1 它是“流式追赶”，不是一次性批量导出

物理 streaming replication protocol 本来就是按 WAL 流发送。也就是说，它不是等积累一大堆再整体打包，而是随着 WAL 产生不断往前推进。(PostgreSQL)

7.2 它的节奏受业务写入量影响

业务写入越多，WAL 生成越快，这条 walsender 要发的数据也越多。WAL 是数据库变更的日志载体，本身就和事务修改量直接相关。(PostgreSQL)

7.3 它本质上是一条“保底通道”

因为在线备份最怕的是：文件拿到了，但结束后发现需要的 WAL 已经丢了或回收了。-X stream 用第二条连接边备份边拿 WAL，本质上就是把这类风险前移并降低。官方文档对 fetch 的约束正好从反面证明了 stream 的优势。(PostgreSQL)

---

8）为什么说它“仅在 -X stream 下有这个专门角色”

因为 WAL 获取策略不同，服务端角色也不同。

• -X stream：第二条连接并行流式发 WAL，所以会出现这条“专门发 WAL 的 walsender”。(PostgreSQL)
• -X fetch：不并行开这条流，而是在主备份结束后再去取所需 WAL。(PostgreSQL)
• -X none：根本不由 pg_basebackup 帮你取 WAL。(PostgreSQL)

因此，这条进程不是“只要跑 pg_basebackup 就一定有”，而是 -X stream 策略特有的并行 WAL 发送角色。(PostgreSQL)

---

9）它对资源和配置意味着什么

这个进程很重要，因为它直接牵涉三类资源。

9.1 max_wal_senders

因为它本身就是一个 walsender。
官方文档明确要求：运行 base backup 需要至少一个 wal sender；若启用 WAL streaming，还要再多一个。所以 -X stream 通常意味着至少要为这次备份准备两个 sender 配额。(PostgreSQL)

9.2 网络带宽

它专门发 WAL。写入高峰期，这条流量可能并不小。WAL 是持续生成的变更日志，事务越密集，WAL 发送压力越大。(PostgreSQL)

9.3 复制权限与认证

因为它是一条 replication 连接，所以和普通业务连接不同，必须满足 replication 连接的认证与权限要求。官方文档在流复制配置中明确要求允许 replication connections，并使用具有相应权限的角色。(PostgreSQL)

---

10）它在监控里怎么看

这条进程不像数据文件那条一样直接出现在 pg_stat_progress_basebackup 里。
pg_stat_progress_basebackup 对应的是“执行 BASE_BACKUP 并发送备份”的 WAL sender，也就是主备份那条。(PostgreSQL)

而这条 WAL 流 walsender 更适合从这些地方看：

pg_stat_replication

官方统计文档说明，该视图是 每个 WAL sender 一行。所以在 -X stream 时，通常会看到与本次备份相关的两条 sender：一条偏 base backup 主流程，一条偏 WAL streaming。(PostgreSQL)

OS 层进程视角

你能看到有多个 walsender，但光靠进程名无法精确区分谁是“数据文件那条”、谁是“WAL 那条”；还是要结合 PostgreSQL 视图和当前备份行为来判断。监控章节也强调了应结合 PostgreSQL 统计视图与系统工具一起看。(PostgreSQL)

---

11）最容易误判的地方

误判一：以为这条 WAL 流 walsender 在“执行 BASE_BACKUP”

不是。
执行 BASE_BACKUP 主流程的是另一条 walsender。这条是 -X stream 下额外开的 WAL 流发送通道。(PostgreSQL)

误判二：以为它是普通流复制 standby 的那个 sender

协议层很像，都是 physical streaming replication；但这里它服务的对象不是一个长期 standby，而是 pg_basebackup 这个临时备份客户端。它是 为本次备份会话服务 的。复制协议文档说明 physical replication connection 就是这种模式的基础。(PostgreSQL)

误判三：以为有了它就不需要理解备份边界

也不对。
它只负责把 WAL 持续送过去；真正决定备份起点、备份终点、base backup 生命周期的，仍是主备份那条 walsender 和 BASE_BACKUP 流程本身。(PostgreSQL)

---

12）把整条逻辑串成一遍

你可以按下面这条因果链理解：

在线基础备份期间，数据库还在持续写入
→ 只拿数据文件不足以恢复到一致状态
→ 必须拿到备份期间对应的 WAL
→ 如果用 -X stream，pg_basebackup 会额外开第二条 replication 连接
→ 服务端为这条连接分配一条专门的 walsender
→ 这条 walsender 不负责 BASE_BACKUP 主流程
→ 它专门并行流式发送 WAL
→ 客户端边收数据文件，边收 WAL
→ 这样在备份结束时，恢复所需材料更完整，且不必冒“事后 fetch 时 WAL 已被回收”的风险

这就是这条进程的全部逻辑主线。(PostgreSQL)

---

13）最适合你记忆的标准表述

在 pg_basebackup -X stream 模式下，除了执行 BASE_BACKUP 的主备份 walsender 外，客户端还会额外建立第二条 replication 连接；源库侧对应生成一条专门发送 WAL 的 walsender。它的职责不是发送数据库文件，而是并行流式发送本次基础备份所需的 WAL，使客户端在接收基础备份主体的同时，持续获得恢复所需日志，从而降低事后获取 WAL 失败的风险，并确保备份可恢复性。(PostgreSQL)

---

---

WAL 流 walsender 的排障逻辑 也按“现象 → 判断点 → 根因方向”给你梳理出来。

有，但到你现在这个层次，能补的已经不多了，主要还剩这几类“收边界”的点。

1. 它的本质其实是“临时 WAL receiver 的对端”

从客户端视角看，pg_basebackup -X stream 会边备份边收 WAL；从服务端视角看，这条 walsender 就是在给这个“临时接收 WAL 的客户端会话”持续供流。
所以它和“给 standby 持续送 WAL 的 walsender”协议层很像，但目标不同：

• 给 standby 的：长期复制
• 给 pg_basebackup -X stream 的：服务本次基础备份会话

这个区分很重要。

---

2. 它解决的是“备份期间 WAL 连续性”问题，不是“备份主体生成”问题

这个逻辑最好再钉死一次：

• 数据文件那条 walsender 解决“基础备份主体怎么生成”
• WAL 流这条 walsender 解决“备份期间产生的 WAL 怎么不断档地拿到”

所以这条 WAL 流进程的意义，不在于“让备份更快”，而在于：

让备份所依赖的 WAL 获取方式从‘事后补拿’变成‘实时并行获取’。

这是它最核心的价值。

---

3. 它的风险点主要不在“逻辑错”，而在“流中断”

这条进程本身逻辑并不复杂，真正要注意的是它一旦中断，会直接影响备份完整性。
常见影响路径你可以这样理解：

• 第二条 replication 连接断掉
• WAL 无法持续送达客户端
• -X stream 这条链断掉
• 整个 base backup 的可恢复性就会出问题，通常备份失败或不可用

所以这条进程最关键的运维含义是：

它是备份可恢复性的实时保障链路。

---

4. 它和 slot 的关系值得知道，但不用讲太深

如果 pg_basebackup 配合 replication slot 使用，那么这条 WAL 流会话和 slot 就会产生直接关系。
运维上你只要记住这一层就够了：

• 有 slot：更容易避免所需 WAL 被过早清理
• 但会话异常、slot 不释放时，可能导致 WAL 堆积

这个点更偏生产实践，不是这条进程本身的主逻辑，但确实属于它的现实边界。

---

5. 它的监控重点不是“phase”，而是“是否还在稳定推 WAL”

和数据文件那条不一样，这条 WAL 流 walsender 没有 pg_stat_progress_basebackup 那种很直观的 phase 视角。
所以看它，更关注的是：

• 连接还在不在
• sender 还活不活
• WAL 有没有持续往前送
• 客户端有没有持续接收

也就是说：

• 数据文件那条 更适合看“处于哪一阶段”
• WAL 流这条 更适合看“流是否连续、有没有停滞”

---

6. 最后一个边界：它只在 -X stream 里是主角

这是收尾时最该补的一句。

如果不是 -X stream，那这条“专门发 WAL 的 walsender”就不是这个故事里的核心角色了：

• -X fetch：WAL 是事后取
• -X none：WAL 根本不由 pg_basebackup 取

所以它的重要性是 策略相关的，不是所有 base backup 场景都一样高。

---

现在可以怎么定稿

到这里，这个基础已经够扎实了。
你现在对这条进程，已经能从这几个层面讲清楚：

• 它是什么
• 为什么需要它
• 它怎么启动
• 它持续干什么
• 它和数据文件那条怎么分工
• 它的运维意义是什么
• 它的边界在哪里

最适合记住的一句压缩版是：

pg_basebackup -X stream 里的 WAL 流 walsender，本质上是服务端为本次基础备份额外拉起的第二条 WAL 发送通道；它不负责生成 base backup 主体，只负责把备份期间所需 WAL 实时并行送给客户端，保证这次物理备份具备可恢复性。