同步复制因主库需等待备库确认wal接收或应用，导致在备库延迟、宕机或网络不佳时主库事务阻塞；通过配置多个同步备库、调整synchronous_commit级别及监控延迟可缓解该问题。
PostgreSQL 的同步复制（Synchronous Replication）在确保数据高可用的同时，可能会导致主库出现阻塞。这种现象的根本原因在于其复制机制的设计逻辑。
同步复制的基本原理
在 PostgreSQL 中，同步复制要求事务提交时，日志（WAL，Write-Ahead Logging）不仅写入主库的磁盘，还必须确认已传输并接收到至少一个同步备库的接收反馈。只有满足这个条件后，事务才能真正返回成功给客户端。
关键点包括：
- 主库将 WAL 记录发送到配置为“同步”的备库。
- 主库等待来自同步备库的确认信息（如“已接收”或“已应用”）。
- 只有收到确认后，主库才向客户端返回事务提交成功。
这种机制保证了即使主库崩溃，至少有一个备库拥有最新的数据变更，避免数据丢失。
为何会阻塞主库
当同步复制启用后，主库的行为会受到备库状态的直接影响。以下几种情况会导致主库阻塞：
- 备库延迟或宕机：如果唯一的同步备库网络中断、宕机或重放速度慢，主库无法收到确认，事务提交会被挂起，直到超时或备库恢复。
- 网络延迟高：跨地域部署时，网络往返时间增加，每个事务都需要等待更久，降低整体吞吐量。
- 备库重放压力大：如果备库 I/O 或 CPU 资源不足，处理 WAL 的速度跟不上主库生成速度，造成积压，进而拖慢主库。
- synchronous_commit 设置为 on：这是默认设置，意味着每次提交都必须等待同步备库响应。若此时无可用同步备库，系统会自动降级到异步模式（取决于 synchronous_standby_names 配置），但在此之前可能出现短暂阻塞。
如何缓解主库阻塞
为了避免同步复制带来的性能影响和阻塞风险，可以采取以下措施：
-
合理配置 synchronous_standby_names：使用多个候选备库，并指定“ANY”或“FIRST”策略，提高可用性。例如：
synchronous_standby_names = 'FIRST 1 (s1, s2)'
表示只要 s1 或 s2 中任意一个完成接收即可。 -
调整 synchronous_commit 级别：根据业务需求，可设为
remote_write或off，牺牲部分持久性换取性能。 - 监控备库延迟：通过 pg_stat_replication 视图实时查看备库状态，及时发现异常。
-
设置合理的 timeout：启用
wal_receiver_timeout和commit_delay等参数，防止无限等待。
总结
PostgreSQL 同步复制通过强制主库等待备库确认来保障数据安全，但也因此引入了潜在的阻塞风险。理解其基于 WAL 传输与确认的机制，有助于合理配置集群，平衡数据一致性与系统性能。基本上就这些。
