pg_basebackup客户端进程pg_basebackup的“客户端进程”，本质上就是在备份机上启动的那个前台工具进程。它不是数据库实例内部的常驻后台进程，而是一个 PostgreSQL 客户端程序：负责连到源库，发起基础备份请求，接收服务器发来的数据流，并把备份文件落到本地目录、tar 包，或者按参数写到目标位置。官方文档明确说，它通过 使用 replication protocol 的常规 PostgreSQL 连接 来完成备份。(PostgreSQL)
可以把它理解成：备份任务的“控制端 + 接收端”。
它在备份过程中主要扮演这几个角色：
1. 发起者pg_basebackup先作为客户端连接到源库，连接用户需要具备REPLICATION权限或超级用户权限，并且pg_hba.conf要允许这种 replication 连接。它会向服务端发出BASE_BACKUP请求，告诉服务端“开始输出一个可恢复的一致性基础备份”。(PostgreSQL)
2. 备份会话的协调者
虽然真正读取数据文件的是服务端，但pg_basebackup负责把整个备份流程组织起来。官方文档说明，执行BASE_BACKUP时，系统会自动进入和退出 backup mode；而pg_basebackup会保证这个过程自动完成。也就是说，它不是简单地“拷文件”，而是在和服务端协同，拿到一个逻辑上一致、可用于恢复的基础备份。(PostgreSQL)
3. 数据接收者
服务端把数据目录/表空间内容通过复制协议流式发送出来，pg_basebackup客户端进程负责持续接收这些数据块，并按你指定的格式写出：plain：写成目录结构tar：写成base.tar等归档文件
也可以根据参数做压缩、表空间映射、指定输出路径等。(PostgreSQL)
4. WAL 获取者
基础备份只拿到数据文件还不够，要想恢复可用，还需要配套 WAL。pg_basebackup客户端会根据-X选项决定怎么处理 WAL：-X stream：边做基础备份，边再开第二条连接流式接收 WAL-X fetch：等基础备份结束后，再去取所需 WAL-X none：不取 WAL，由你自己另外保证 WAL 可获得。
其中-X stream是默认方式，官方文档明确说这会打开 第二个连接，并行流式接收 WAL，因此需要 两个 replication 连接。(PostgreSQL)
这一点很关键：
在-X stream模式下，pg_basebackup客户端不仅是“基础文件接收者”，还临时充当了 WAL receiver 的角色，只不过它接收 WAL 的目的不是持续复制，而是为了让这次备份在恢复时完整可用。(PostgreSQL)
5. 备份结果的整理者
客户端进程还会负责一些收尾工作，例如：
写备份文件到目标目录
可选生成/接收backup_manifest
可选写入standby.signal和postgresql.auto.conf（-R），方便把这份基础备份直接用来拉起一个 standby
默认情况下还会等待文件安全落盘；除非显式指定--no-sync。(PostgreSQL)
它和服务端进程的分工
可以这样区分：
服务端（primary / standby 上的 walsender 等）负责：
进入/退出 backup mode
枚举并读取数据库集群文件
按 replication protocol 把基础备份数据流发给客户端
按需发送 WAL。(PostgreSQL)
客户端pg_basebackup进程负责：
建立 replication 连接
发起BASE_BACKUP
接收基础备份数据
接收或拉取 WAL
写到本地/目标位置
按参数做压缩、限速、进度显示、slot 使用等。(PostgreSQL)
用一句话概括它的作用pg_basebackup客户端进程的作用就是：
作为备份任务的执行端，向 PostgreSQL 服务端发起基础备份请求，并把服务端输出的基础数据文件和所需 WAL 接收下来，组织成一份可恢复、可用于搭建 standby 的物理备份。 (PostgreSQL)
一个很实用的理解方式
把它类比成“拉流客户端”会更直观：
服务端像“推流端”pg_basebackup像“拉流端”
拉的不是业务查询结果，而是 数据库物理文件 + WAL
目标不是查询，而是生成一份 可恢复的物理备份。(PostgreSQL)
一张 pg_basebackup 备份时的 客户端 / walsender / WAL / 数据目录 交互流程图：
1）整体流程图
┌──────────────────────────────┐
│ 备份机 / 运维主机 │
│ │
│ pg_basebackup 客户端进程 │
│ ------------------------ │
│ 1. 建立 replication 连接 │
│ 2. 发送 BASE_BACKUP 请求 │
│ 3. 接收基础备份数据流 │
│ 4. 接收/获取 WAL │
│ 5. 写成本地备份文件 │
└──────────────┬───────────────┘
│ replication protocol
│
▼
┌──────────────────────────────┐
│ PostgreSQL 源库服务器 │
│ │
│ postmaster │
│ └─ walsender 进程 │
│ ------------------ │
│ 1. 响应 BASE_BACKUP │
│ 2. 读取数据目录文件 │
│ 3. 流式发送备份内容 │
│ 4. 按需发送 WAL │
└───────┬──────────────────────┘
│
│ 读取
▼
┌──────────────────────────────┐
│ PGDATA / tablespace │
│ 数据文件、控制文件等 │
└──────────────────────────────┘
pg_basebackup 是 PostgreSQL 自带的客户端工具，用来对正在运行的数据库集群做 base backup；它通过 replication protocol 和服务器通信。服务器侧则由 WAL sender process 来执行 BASE_BACKUP 并流式发送备份内容。
2）如果使用默认的 -X stream，流程会多一条 WAL 通道
这是最常见、也最容易考察“客户端进程作用”的场景。
主连接：基础备份数据
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ pg_basebackup 客户端进程 │─────▶│ walsender #1 │
│ │ │ 执行 BASE_BACKUP │
│ - 接收 data files │◀─────│ 发送数据目录/表空间内容 │
│ - 写到 backup 目录或 tar │ └──────────────────────────────┘
│
│
│ 第二连接：WAL 流
│ │─────▶┌──────────────────────────────┐
│ - 接收 WAL │◀─────│ walsender #2 │
│ - 保证备份可恢复 │ │ 流式发送 WAL │
└──────────────────────────────┘ └──────────────────────────────┘
官方文档说明，-X stream 会在备份时 打开第二个连接来流式接收 WAL，所以此时通常需要 两个 replication 连接。同时 max_wal_senders 也必须配置得足够大，因为它限制了 standby 或 streaming base backup client 可并发占用的 WAL sender 数。
3）客户端进程在备份中具体起什么作用
第一层：发起者
它先连上源库，使用 replication 连接发起 BASE_BACKUP。
没有这个客户端进程，服务端不会自己“主动备份”；它必须由 pg_basebackup 这类客户端触发。
第二层：协调者
它不是单纯拷文件，而是在和服务端协同拿一份 一致性基础备份。
服务端负责执行 BASE_BACKUP，客户端负责驱动整个会话，把这次备份从“请求”推进到“完整落盘”。pg_stat_progress_basebackup 里也能看到正在运行 BASE_BACKUP 并流送备份的 WAL sender 进度。
第三层：接收者
服务端读取 PGDATA、表空间等文件后，不是直接写到你的备份目录；真正把这些数据 接下来并写出去 的，是 pg_basebackup 客户端进程。
也就是说：
- 服务端负责“读源数据、发数据”
- 客户端负责“收数据、写备份”
第四层：WAL 获取者
要让 base backup 可恢复，只拿数据文件还不够，还要拿到对应 WAL。pg_basebackup 客户端根据参数决定 WAL 的获取方式：
-X stream：边备份边流式接收 WAL-X fetch：备份后再取所需 WAL-X none：不取 WAL，由外部自己保证 WAL 可用。
所以客户端进程不仅接收“静态数据文件”，还会接收“动态产生的 WAL”，它相当于这次备份任务里的 临时 WAL receiver。这个角色是保证“这份备份将来真的能恢复”的关键。
第五层：落盘者 / 封装者
客户端把收到的数据组织成你指定的输出形式，例如：
- 普通目录格式
- tar 格式
- 压缩输出
- 生成 backup manifest
- 可选写
standby.signal和连接配置（-R）以便直接启动成 standby。
4）一句话理解“客户端进程”的角色
pg_basebackup 客户端进程 = 备份任务的发起端 + 数据接收端 + WAL 接收端 + 备份落盘端。
它自己不负责在源库本地扫描并直接拷贝文件；真正读取数据库文件的是服务端的 walsender / BASE_BACKUP 执行端。客户端的核心职责是 发起、接收、组织、保存。
5）最容易混淆的一点
很多人会误以为：
“
pg_basebackup客户端进程就是在远程执行cp/tar拷文件”
这个理解不准确。
更准确地说，它是在 复制协议层 拉取一份服务端生成的物理备份数据流。
也就是说，它是 协议客户端，不是 SSH 上去直接扫目录的脚本。
6）这个流程
pg_basebackup 客户端
↓
连接 primary（replication 连接）
↓
发送 BASE_BACKUP
↓
服务端 walsender 读取数据文件并流式发送
↓
客户端接收并写备份
↓
同时或随后获取 WAL
↓
形成可恢复的物理基础备份
这份基础备份可用于 PITR，也可作为搭建 log-shipping / streaming-replication standby 的起点。
主库上会看到哪些进程（postmaster / walsender / checkpointer 等），其中 pg_basebackup 对应哪一个
pg_basebackup 客户端进程，不是在主库内部的某个常驻后台进程。
它是在备份机上运行的一个外部客户端；而它在主库上“对应出来”的，是一个或两个 walsender 进程。pg_stat_progress_basebackup 里显示的也是 正在执行 BASE_BACKUP 并流式发送备份的 WAL sender。
1）主库上的进程视角图
主库服务器（PostgreSQL）postmaster
├─ checkpointer
├─ background writer
├─ walwriter
├─ autovacuum launcher
├─ autovacuum worker(s)
├─ archiver (如果开启归档)
├─ postgres backend(s) (普通客户端会话)
└─ walsender(s)
├─ walsender #1 <== 被 pg_basebackup 客户端占用
│ 作用：执行 BASE_BACKUP，读取数据目录并发送基础备份数据
│
└─ walsender #2 <== 仅在 -X stream 时常见
作用：流式发送 WAL 给 pg_basebackup 客户端
也就是说：
- 你在备份机上看到的是：
pg_basebackup客户端进程 - 你在主库上看到的是：它建立出来的
walsender连接 - 不是 checkpointer / walwriter / bgwriter 在“替代”它做备份
这些进程仍做各自的数据库后台工作，只是为系统正常运行提供环境。
2）它在主库上到底“对应哪一个进程”
最准确的说法是：
在主库上，pg_basebackup 对应的是 WAL sender process
官方进度视图说明得很直接：pg_stat_progress_basebackup 中每一行，对应一个 正在运行 BASE_BACKUP 并流式发送备份的 WAL sender process。
所以当你问：
“
pg_basebackup客户端进程在主库上对应哪个进程？”
答案是：
对应主库上的 walsender 进程，而不是普通 postgres backend。
3）为什么是 walsender，不是普通 backend
因为 pg_basebackup 不是走普通 SQL 查询路径来“select 数据文件”，而是通过 replication protocol 发起 BASE_BACKUP。pg_basebackup 官方文档也明确说，它使用的是 replication protocol 的常规 PostgreSQL 连接。这类连接在服务端侧由 walsender 处理。
所以这里要分清两类服务端进程：
普通业务连接
- 对应主库上的普通 backend
- 执行
SELECT / INSERT / UPDATE / DELETE
复制 / 备份连接
- 对应主库上的
walsender - 执行
BASE_BACKUP、发送 WAL、提供流复制数据
pg_basebackup 属于第二类。
4）备份时各个进程分别干什么
① 备份机上的 pg_basebackup 客户端进程
它负责：
- 发起 replication 连接
- 发送
BASE_BACKUP - 接收主库发来的基础备份数据
- 接收或获取 WAL
- 把内容写到本地目录 / tar / 压缩包。
② 主库上的 walsender
它负责：
- 接收客户端发来的
BASE_BACKUP请求 - 读取数据目录、表空间等内容
- 将这些内容流式发送给客户端
- 在需要时发送 WAL。
③ 主库上的其他后台进程
例如：
checkpointerbgwriterwalwriterarchiver
它们不是 pg_basebackup 专属进程，但会影响备份环境的正常运行。
比如 WAL 会持续生成，归档可能在同步归档 WAL，checkpoint 会影响脏页刷盘节奏，但它们不是“备份会话的直接执行者”。这一点和 walsender 不一样。
5）-X stream 时为什么会看到两个相关连接
这是最容易在现场排查里碰到的点。
当你使用默认常见模式 -X stream 时：
- 一个
walsender用来执行BASE_BACKUP，发送基础备份内容 - 另一个连接用来 stream WAL
因此通常会占用 两个 replication 连接，也就可能在主库上看到两个相关的 walsender。官方文档明确写了：-X stream 会为 WAL 再打开一个第二连接。
所以你现场如果问：
“为什么一跑
pg_basebackup，主库上多了两个复制相关进程？”
很可能就是这个原因。
6）你在库里一般怎么识别它
可以从两个视角看：
视角 A：看进度
pg_stat_progress_basebackup
这里看到的是 执行 base backup 的 walsender 进度。
视角 B：看活动连接/复制连接
pg_stat_activity / pg_stat_replication
官方统计文档说明，pg_stat_replication 是 每个 walsender 一行。
也就是说，排查时你可以这样理解：
pg_stat_activity：看连接和进程类型pg_stat_replication：看复制发送侧状态pg_stat_progress_basebackup：看 base backup 具体进度
7）一句话定性
你可以直接这样记：
pg_basebackup是客户端；它在主库上体现为一个或多个walsender进程。
其中负责真正执行BASE_BACKUP、把数据文件流出来的，是主库上的walsender；客户端只负责发起、接收和落盘。
8）最适合面试/排障时的标准表述
你可以这样回答：
pg_basebackup本身是运行在备份端的客户端程序，不属于主库内部后台进程。它通过 replication protocol 连接主库，在主库侧会对应一个执行BASE_BACKUP的walsender进程；如果使用-X stream，还会再占用一个walsender用于流式接收 WAL。客户端负责发起备份、接收备份流并写到目标介质，服务端walsender负责读取集群文件并发送数据。
了解 www.876873.xyz 的更多信息
订阅后即可通过电子邮件收到最新文章。
pg_basebackup进程相关：等您坐沙发呢！