PostgreSQL 中的常见后台进程

知识点图片

PostgreSQL 采用的是 多进程架构（而非多线程）。当你启动 PostgreSQL 时，首先会启动一个主进程（通常称为 postgres，早期版本称为 postmaster），然后由这个主进程 fork（派生）出多种负责不同任务的后台进程。

这些后台进程负责管理内存、磁盘 I/O、日志、清理垃圾数据以及处理复制等核心任务。以下是 PostgreSQL 中最常见的核心后台进程及其详细说明：

1. 核心后台进程

1.1 Checkpointer（检查点进程）

作用：定期将“共享缓冲区（Shared Buffers）”中的“脏页（Dirty Pages，即被修改过但尚未写入磁盘的数据）”刷入磁盘。
机制：当执行检查点时，它会在预写式日志（WAL）中记录一个标记，表明在这个点之前的所有数据都已经安全落盘。
意义：一旦数据库崩溃，重启恢复时只需要从最近的检查点开始重放 WAL 即可，从而大大缩短数据库崩溃后的恢复时间（Crash Recovery Time）。

1.2 Background Writer / bgwriter（后台写进程）

作用：也是将共享缓冲区中的脏页写入磁盘，但它的工作方式与 Checkpointer 不同。
机制：它在后台“缓慢、持续”地清理脏页。
意义：它的主要目的是平滑 I/O 峰值。如果在客户端查询需要加载新数据到内存时，发现内存满了，客户端进程就需要自己去把脏页刷入磁盘，这会导致查询变慢。bgwriter 提前把脏页写盘，释放出干净的缓冲区，从而提高客户端的查询响应速度，并减轻 Checkpointer 集中写盘的压力。

1.3 WAL Writer（预写式日志写进程）

作用：将 WAL 缓冲区（WAL Buffers）中的日志数据写入到磁盘上的 WAL 文件中。
机制：PostgreSQL 遵循“日志先行（Write-Ahead Logging）”原则，任何数据的修改必须先记入 WAL 才能算成功。WAL Writer 会根据配置（如 wal_writer_delay 或事务提交时的同步设置 synchronous_commit）定期或实时地将日志刷盘。
意义：保证数据库的持久性（Durability），即 ACID 中的 D。

1.4 Autovacuum Launcher & Worker（自动清理启动进程与工作进程）

Autovacuum Launcher：负责定期检查数据库表的状态，决定哪些表需要清理（Vacuum）或分析（Analyze）。
Autovacuum Worker：由 Launcher 调度启动，执行实际的清理和分析工作。
意义：
- 回收被删除或更新的旧数据行（Dead Tuples）占用的空间，防止表膨胀（Bloat）。
- 更新表的统计信息，供查询优化器（Query Planner）生成高效的执行计划。
- 防止事务 ID 绕卷（Transaction ID Wraparound）导致的数据库停机灾难。

2. 日志与归档相关进程

2.1 Archiver（归档进程）

作用：当一个 WAL 文件被写满并切换后，Archiver 进程会把这个旧的 WAL 文件复制到指定的归档目录或云存储中。
触发条件：只有在 postgresql.conf 中开启了 archive_mode = on 时才会启动。
意义：这是实现 PITR（基于时间点恢复） 和搭建温备/冷备份节点的基础。

2.2 Syslogger（系统日志进程 / 记录器进程）

作用：捕获主进程及其所有子进程的 stderr 和 stdout 输出，并将其写入到日志文件中（通常在 pg_log 目录下）。
触发条件：需要开启 logging_collector = on。
意义：它还负责日志文件的自动轮转（Rotation，比如按天或按大小生成新日志文件），是 DBA 排查数据库报错和慢查询的重要依赖。

3. 复制与高可用相关进程 (Streaming Replication)

如果你配置了主从复制，还会看到以下进程：

3.1 WAL Sender（WAL 发送进程）

运行在 主库（Primary） 上。负责将 WAL 记录通过网络发送给从库。有几个从库连接，就会有几个 WAL Sender。

3.2 WAL Receiver（WAL 接收进程）

运行在 从库（Standby） 上。负责接收来自主库的 WAL 数据，并将其写入到本地的 WAL 文件中。

3.3 Startup Process（启动进程 / 恢复进程）

运行在从库上（或主库崩溃重启时）。在从库上，它负责持续读取 WAL Receiver 接收到的日志，并将这些更改应用（重放）到本地数据文件中，使从库数据与主库保持一致。

4. 其他重要进程

4.1 Logical Replication Launcher / Worker（逻辑复制进程）

如果你使用了 PostgreSQL 10 引入的逻辑复制（发布/订阅模式），会出现这类进程。Launcher 负责管理，Worker 负责具体的逻辑变更应用。

4.2 Stats Collector（统计信息收集进程）—— 注意版本差异

PG 14 及以前版本：负责收集数据库的活动统计信息（如表被访问的次数、索引使用率等），通过 UDP 协议发送给自己并写入临时文件。
PG 15 及以后版本：该进程已被移除！ PostgreSQL 15 将统计信息的收集改为了使用动态共享内存（Shared Memory），大大降低了系统的 I/O 开销。

如何在系统中查看这些进程？

1. 在操作系统层面查看（Linux）
使用 ps 命令可以清晰地看到这些进程（注意进程名通常带有清晰的标识）：

bash

ps -ef | grep postgres

输出示例：

plaintext

postgres   1234      1  0 10:00 ?     00:00:00 /usr/pgsql-14/bin/postgres -D /var/lib/pgsql/14/data
postgres   1235   1234  0 10:00 ?     00:00:00 postgres: logger          # syslogger
postgres   1237   1234  0 10:00 ?     00:00:00 postgres: checkpointer    
postgres   1238   1234  0 10:00 ?     00:00:00 postgres: background writer 
postgres   1239   1234  0 10:00 ?     00:00:00 postgres: walwriter       
postgres   1240   1234  0 10:00 ?     00:00:00 postgres: autovacuum launcher 
postgres   1241   1234  0 10:00 ?     00:00:00 postgres: stats collector # PG 14及以前
postgres   1242   1234  0 10:00 ?     00:00:00 postgres: logical replication launcher

(注：如果有客户端连接，还会看到类似 postgres: username dbname 192.168.1.100 idle 的 Client Backend 进程。)

2. 在数据库内部查看
PostgreSQL 10 以后，可以通过查询系统视图来查看后台进程状态：

sql

SELECT pid, backend_type, state 
FROM pg_stat_activity 
WHERE backend_type != 'client backend';

右滑查看面试常问

播面