很多 PostgreSQL 用户把 cluster_name 当成一个"好看但没用"的参数——改了它，ps 输出里进程名变了，似乎到此为止。但在有同步复制（synchronous replication）的架构里，这个参数扮演的角色远比表面重要：主节点正是靠 standby 的 cluster_name 来确认谁是同步副本。搞错它，你的同步复制可能静默失效。
进程列表里的"化妆标签"
cluster_name 最直观的效果体现在操作系统进程列表中。默认值是空字符串，此时 PostgreSQL 进程在 ps 里显示为：
postgres: writer process
postgres: wal receiver process
一旦设置了 cluster_name，所有进程名前都会加上这个前缀：
my_cluster: writer process
my_cluster: wal receiver process
在多实例共存的机器上，这个标签确实方便区分哪个进程属于哪个集群。但如果你以为这就是它的全部功能，那就要踩坑了。
同步复制中的隐秘角色
PostgreSQL 的同步复制机制要求主节点明确知道哪个 standby 是"同步的"。主节点通过 synchronous_standby_names 配置来指定，而这个列表里填的名字——正是 standby 上 cluster_name 的值。
流程是这样的：
- standby 启动后，向主节点发起连接，在 replication handshake 中上报自己的
cluster_name。 - 主节点拿这个名字去匹配
synchronous_standby_names列表。 - 匹配成功，该 standby 被认定为同步副本；匹配失败，它就降级为异步副本，即使网络一切正常。
这意味着：如果 standby 的 cluster_name 和主节点 synchronous_standby_names 中期望的名字不一致，同步复制不会报错，不会告警，只是静默地不生效。你的写入操作以为有同步保障，实际上数据只落在了主节点本地。
实际配置与验证
下面用一个完整示例演示正确配置和验证方法。
主节点配置（postgresql.conf）
# 主节点：声明期望的同步 standby 名称
synchronous_standby_names = 'FIRST 2 (standby_a, standby_b)'
synchronous_commit = on
standby 配置（postgresql.conf）
# standby_a 节点：cluster_name 必须与主节点列表中的名字一致
cluster_name = 'standby_a'
# standby_b 节点
cluster_name = 'standby_b'
验证同步状态
在主节点上执行以下查询，确认同步复制确实生效：
-- 查看当前同步副本的状态
SELECT pid, application_name, state, sync_state
FROM pg_stat_replication;
期望输出类似：
pid | application_name | state | sync_state
-----+------------------+------------+------------
123 | standby_a | streaming | sync
456 | standby_b | streaming | sync
sync_state 列出现 sync 才说明同步复制真正生效。如果看到 async，说明名称匹配失败。
用 shell 快速检查进程标签
# 在 standby 机器上确认 cluster_name 已生效
ps -ef | grep postgres | head -5
# 预期看到类似输出：
# standby_a: wal receiver process ...
# standby_a: startup process ...
常见踩坑场景
改名不通知主节点。 运维为了"规范命名"把 standby 的 cluster_name 从 standby_a 改成 prod_standby_01，但没有同步更新主节点的 synchronous_standby_names。结果：同步复制静默降级为异步，直到有人查 pg_stat_replication 才发现。
多 standby 共用同一个 cluster_name。 两个 standby 都设 cluster_name = 'standby_a'，主节点只认第一个连接的为同步副本，第二个即使连上了也不会被当作同步节点，还可能干扰主节点的匹配逻辑。
空字符串的陷阱。 如果 cluster_name 保持默认空值，standby 上报的名字会变成连接字符串中的 application_name（通常来自 primary_conninfo）。这时主节点匹配的其实是 application_name，行为更难预测，调试也更复杂。
上线检查清单
在配置或修改 cluster_name 前，逐项确认：
- ☐ standby 的
cluster_name值是否与主节点synchronous_standby_names中的名称完全一致（大小写敏感）。 - ☐ 修改
cluster_name后是否需要重启 standby（该参数属于postmaster级别，改后必须重启，不能仅pg_ctl reload）。 - ☐ 主节点修改
synchronous_standby_names后是否已pg_ctl reload或ALTER SYSTEM。 - ☐ 修改完成后，在主节点执行
SELECT * FROM pg_stat_replication，确认sync_state为sync。 - ☐ 多 standby 场景下，每个 standby 的
cluster_name是否唯一。
cluster_name 是 PostgreSQL 里那种"看起来无害、改错了后果严重"的参数。把它当成纯粹的装饰品，迟早会在同步复制上栽跟头。把它当成复制的身份凭证，你的高可用架构才能真正可靠。