1. 流复制协议到底在解决什么问题很多刚接触PostgreSQL高可用方案的朋友上来就搜“流复制怎么配”“pg_basebackup怎么用”配好之后能跑就完事了。但一旦遇到主备切换失败、备库一直追不上主库、WAL日志堆积到磁盘爆炸这类问题往往就抓瞎了。根子上的原因就是没搞明白流复制协议在工作时到底经历了什么、交换了哪些消息、数据是怎么一步步对齐的。流复制协议本质上是一套定义在PostgreSQL客户端与服务端之间的交互规范。它负责解决三件事备库如何向主库发起复制请求、主库如何把WALWrite-Ahead Log预写式日志数据持续推送给备库、以及双方如何感知彼此的健康状态和进度差异。这套协议从PostgreSQL 9.0开始引入经过这么多年迭代到了9.1加入同步复制、9.4加入复制槽、10版本引入两阶段切换协议已经非常成熟稳定也是Patroni、repmgr、pg_auto_failover这些高可用组件的底层依赖。这篇文章我会先讲协议的分层结构和核心交互流程然后带你手动模拟一次完整的复制握手过程最后把运行时的高频故障和排查方法整理出来。读完之后你不仅能把主备配起来还能在出问题时知道该看什么日志、抓什么包、查什么视图真正把流复制吃透。这篇文章适合三类人正在搭建PostgreSQL高可用集群的运维工程师、想深入理解复制原理的DBA、以及准备基于流复制协议做二次开发或者写工具的同学。基础要求是熟悉PostgreSQL的基本配置知道wal_level、archive_mode这些参数是干什么的但不需要你提前研究过协议源码。2. 协议的分层结构与核心设计思想2.1 从复制模式看协议定位PostgreSQL的复制体系里有三层东西容易混流复制、逻辑复制和归档恢复。很多人分不清它们之间的边界这里先梳理清楚。流复制是物理级别的复制协议它传输的是WAL日志的原始字节流。备库拿到日志后直接在数据块层面重放操作的是相同版本、相同校验规则的页面文件。逻辑复制则是把WAL中的变更解析成逻辑元组流通过输出插件如pgoutput重新编码后传输订阅端可以跨版本、跨库甚至跨平台地应用这些变更。归档恢复走的是另一条路它把WAL日志写满后先归档到远端存储备库通过restore_command拉取归档日志来恢复这种方式的延迟取决于归档周期和轮询间隔通常秒级到分钟级。流复制协议只关心物理字节的对齐不关心业务语义所以协议本身设计得相当精简。整个交互可以理解成一个循环备库告诉主库“我要从WAL的哪个位置开始给我日志”主库就从那个位置开始持续发送直到把最新日志发完然后等待新日志产生再继续发。中间没有业务字段、没有库表结构定义只是一条源源不断的字节流。2.2 协议的消息类型与交互基础流复制协议构建在PostgreSQL的前后端协议层之上。也就是说备库首先得完成一次普通的客户端认证连接然后在同一个连接里升级为复制模式。核心交互由五种消息组成全都定义在protocol/sync.h和replication相关源文件中Identify System备库启动时发送的一条查询消息用于获取主库的系统标识符system identifier、当前时间线和最新WAL位置。系统标识符是初始化数据目录时生成的全局唯一ID备库通过它确认主备是否来自同一个数据祖先防止把不相关的实例接到一起。Start Replication备库发送这条消息指定要从哪个WAL位置开始复制。可以带上一个可选的槽名称slot name主库会记录这个备库的消费进度这就是复制槽机制的基础。CopyBothResponse / CopyData主库确认复制开始后会在同一个连接里持续发送CopyData消息把WAL字节流封装在数据包里传给备库。备库也可以在这条连接里发送备份取消请求如CopyFail消息。Standby Status Update备库周期性地报告自身的接收和重放位置主库据此判断备库的存活状态和滞后程度这是同步复制和延迟监控的核心依据。Primary keepalive主库在长时间没有新WAL产生时会定期默认wal_sender_timeout内发送空的心跳消息告诉备库“我还活着”。这里有个细节值得注意流复制协议跟普通查询协议共用同一个连接通道。也就是说你可以在同一条连接里先执行IDENTIFY_SYSTEM命令再执行START_REPLICATION命令整个会话从普通查询模式切换到复制模式后就不能再执行普通SQL了。这也是协议设计上最优雅的地方——复用已有的认证、SSL、连接管理机制不用另起炉灶。2.3 同步复制与异步复制的协议差异异步复制下主库写入本地WAL后就通知客户端提交成功备库落后多久主库并不关心。同步复制则不同主库在提交事务时必须等待至少一个备库确认已经接收到了该事务对应的WAL数据才会返回客户端成功。这个确认机制完全通过Standby Status Update消息实现。主库知道每个同步备库的确认位置flush位置在提交时比较该位置是否已覆盖当前事务的结束LSN。为了精确控制这个行为PostgreSQL引入了两个参数synchronous_commit和synchronous_standby_names。前者控制事务提交时要等多久后者决定哪些备库被纳入同步备库名单。有个关键概念叫“事务提交的延迟审计”主库在commit时等待的是备库的刷盘确认flush LSN而不是备库的重放确认。这意味着同步复制保证的是“备库已经持久化保存了这条WAL”但不保证备库已经把这个事务应用到了数据页面里。如果此时主库宕机备库接管后会重放这些日志数据不丢但存在短时间内主备同时宕机且备库未完全重放的极小窗口。理解这一点你才能真正理解同步复制的高可用边界而不是盲目相信“同步零丢失”。特性异步复制同步复制主库提交等待不等备库等指定备库确认刷盘数据丢失窗口主库宕机时丢最近未同步的WAL主备同时宕机时才可能丢数据延迟影响不影响主库性能备库故障时主库提交会阻塞或降级典型场景只读扩展、分析型负载金融、交易系统强一致场景3. 复制握手全流程解析从连接建立到数据同步3.1 备库启动后的六步握手过程一次典型的流复制会话可以拆解成六个阶段每个阶段都有明确的目的。我以手动运行pg_basebackup并启动备库为例把全过程串起来讲。第一步备库进程walreceiver向主库发起一条普通的TCP连接目标端口是主库的listen_port。连接建立后按照普通协议发送StartupMessage其中有一个关键的连接参数replication database。这个参数告诉主库“我不是来跑查询的我是来做复制的”主库会据此把会话标记为复制模式并应用pg_hba.conf中replication条目的认证规则。第二步如果认证通过备库发送一条Identify System命令。主库返回三样核心信息系统标识符、当前时间线timeline、最新的WAL插入位置。备库拿到系统标识符后会和自己本地pg_control文件里的值比对。如果不一致会直接报错拒绝连接这能防止误接一个完全无关的数据库实例。第三步备库决定从哪个位置开始请求WAL。如果是首次搭建备库这个位置来自pg_basebackup结束时记录的备份标签backup_label里的START WAL LOCATION。如果备库已经运行过一段时间后重启会从pg_control里记录的最近重放位置开始。在STANDBY模式下备库还会先读取recovery.confPG12之前或postgresql.conf中的primary_conninfo设置确认主库地址。第四步备库发送Start Replication消息参数包括开始的LSN位置、时间线和可选的槽名。主库的walsender进程收到后会检查时间线是否匹配、请求位置是否早于当前WAL保留点。如果一切正常主库回复CopyBothResponse然后开始从请求位置发送WAL数据。第五步进入持续的流式传输阶段。主库把WAL字节封装为XLogData消息每条消息包含一个头部记录起始LSN、发送时间戳和实际数据负载。备库收到后写入WAL文件更新接收位置然后周期性地发送Standby Status Update回执。第六步备库的重放进程startup process持续读取收到的WAL应用变更到数据页。备库进入正常的恢复模式后可以接受只读查询。这个阶段主库和备库的进度不再通过一次性消息同步而是靠持续的双向消息流维持。3.2 手动模拟一次复制握手纸上谈兵不够我用最原始的方式带你模拟一次协议交互。你可以自己在测试环境里跑一遍看到真实的数据流。先在主库上打开两个会话。会话A作为“模拟备库”不用任何复制工具直接用psql以复制模式连接主库psql host主库IP port5432 userreplicator dbnamepostgres replicationdatabase这个连接建立后你会在主库的pg_stat_replication视图里看到一条walsender记录state显示startup。现在在会话A里执行协议命令这种模式下psql可以直接发送协议级命令IDENTIFY_SYSTEM;你立刻会看到类似这样的输出systemid | timeline | xlogpos | dbname ------------------------------------- 7148372764912345678 | 1 | 0/3000060 | postgres这串systemid就是主库数据目录的身份证。接下来从当前WAL位置发起复制请求START_REPLICATION SLOT slot1 PHYSICAL 0/3000060;执行完这条命令后会话A不会再返回普通的结果集而是持续阻塞等待主库推送WAL数据。此时你可以在主库上随便插入几条数据然后切到会话A观察你会看到主库把WAL以CopyData消息的形式持续推送过来。这套手动模拟能让你直观感受到“复制连接并没有那么神秘”本质上就是一条被特殊标记的普通数据库连接。在整个复制过程中备库与主库之间传递的消息长度一般不会超过8KB为兼容旧版本协议的分片大小当WAL数据量超过这个值时会被自动分包传输。3.3 复制槽在协议中扮演的角色没有复制槽的情况下如果备库断开太久主库的WAL可能已经被清理掉通过wal_keep_size或归档完成备库重连时发现需要的LSN已经不存在了只能重新做全量备份。复制槽解决的就是这个问题主库会为每个槽记录备库最新消费的WAL位置并保留该位置之后的所有WAL即使备库离线数天WAL也不会被清理。创建槽有两种方式。一种是在协议握手时自动创建另一种是在主库上手动创建SELECT * FROM pg_create_physical_replication_slot(slot1);然后在primary_conninfo里指定槽名即可。这里有个日常操作中很容易踩的坑复制槽会增加主库WAL磁盘占用如果备库长期断开WAL会无限堆积直到磁盘写满。所以生产环境中务必配套监控pg_replication_slots视图重点关注active槽是否被激活和restart_lsn备库仍需要的最早WAL位置这两个字段。我自己维护的一套告警规则是这样的如果某个槽active为false超过设定阈值比如30分钟发告警如果restart_lsn对应的WAL文件超过主库磁盘可用空间的30%发紧急告警。没有这套保护流复制协议越稳你反而越容易在磁盘维度上翻车。4. 核心参数与配置实战从零搭建一套主备环境4.1 主库侧必须调整的配置项搭建一套可用的流复制环境主库侧有四个参数是硬性要求缺一不可。我按重要性排序列出来# postgresql.conf wal_level replica # 或 logical逻辑复制需要更高等级 max_wal_senders 10 # 允许同时存在的walsender进程数至少大于备库数量 wal_keep_size 1024 # 保留的WAL文件总量单位MBPG15前为wal_keep_segments max_replication_slots 10 # 复制槽数量上限wal_level取值为minimal时系统不产生足够详细的WAL无法开启流复制replica是流复制的最低要求如果还要做逻辑复制就必须用logical。需要注意wal_level不能在运行中热修改必须重启实例生效。max_wal_senders不仅限制复制连接数量还直接影响系统视图pg_stat_replication里的记录上限。如果你的备库数量超过这个值多余的备库会连接失败错误信息是“number of requested standby connections exceeds max_wal_senders”。这个参数的检查周期很短我个人建议直接按“未来备库数量上限5”来设置。pg_hba.conf里还需要添加复制用户的访问规则。这里容易踩一个隐藏坑很多人只加了普通数据库连接的规则忘了加replication条目结果主库日志报错“no pg_hba.conf entry for replication connection”。正确配置如下# pg_hba.conf host replication replicator 192.168.1.0/24 scram-sha-256注意第一列必须是replication关键字而不是数据库名第三列是专门的复制账号建议单独创建不要用超级用户直接扛CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 强密码;4.2 备库侧的配置要点与启动流程备库的配置核心是primary_conninfo参数它告诉备库如何去连接主库。PG12之后统一写在postgresql.conf里。备库搭建有两种路径一种是用pg_basebackup从主库拉一个全量备份另一种是通过pg_rewind把已有实例对齐到新时间线。绝大多数新建场景用第一种。先看看pg_basebackup的全流程。在主库上执行pg_basebackup -h 主库IP -p 5432 -U replicator -D /data/pgdata -X stream -Fp -R这条命令的关键在于三个参数-X stream在备份过程中直接通过流复制协议传输WAL而不是在备份结束时再统一拷贝归档日志。这是保证备份期间产生的WAL不丢失的核心选项。-R在备份目录里自动生成standby.signal文件PG12并在postgresql.conf中写入primary_conninfo。如果没有这个参数你还要手动创建signal文件容易漏。-Fp输出格式为普通目录配合pg_basebackup默认的tar格式区分开。备份完成后备库的数据目录还不能启动需要先确认几个文件到位。PG12以上版本里standby.signal文件存在即表示实例以备库模式启动postgresql.conf里必须有primary_conninfo。在PG11及以下版本对应的是recovery.conf文件。很多新手从老教程复制命令漏掉了这个版本的差异启动时报错或者启动后始终进入不了恢复模式。备库启动后通过以下SQL确认复制状态是否正常-- 在主库执行 SELECT client_addr, state, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication; -- 在备库执行 SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();主库的state字段显示streaming、sync_state显示async或sync备库的pg_is_in_recovery返回true说明流复制已经跑起来了。4.3 同步复制的进阶配置如果业务要求强一致需要把异步升级为同步。修改主库的postgresql.confsynchronous_commit on synchronous_standby_names FIRST 1 (node1, node2)synchronous_standby_names的取值语法从PG9.6开始支持多备库优先级配置。FIRST 1表示在括号列出的备库中按顺序选择第一个状态正常的作为同步备库ANY 1表示任意一个确认即可。多数生产环境用FIRST 1确保最有保障的那台备库承担同步职责。配置生效后pg_stat_replication视图的sync_state列会显示sync或potential。敲黑板如果同步备库故障主库的事务提交会卡住此时可以用synchronous_commit remote_apply强制降级但这个参数本身是动态的实际上更适合的方法是部署Patroni这类自动化切换工具让它可以自动调整同步名单。5. 故障排查实战从日志到协议层的定位方法5.1 备库一直追不上主库怎么办流复制运行中最常见的故障就是备库的replay_lag越来越大。打开备库日志可能会看到类似这样的输出LOG: restartpoint complete: wrote 1024 buffers (5.6%) LOG: recovery restart point at 0/5E0000A8这种日志本身不代表故障但要结合延迟指标判断。排查思路分三步走第一步检查网络带宽和延迟。流复制对带宽要求极高备库重放慢往往不是CPU不够而是网络传输太慢。在主库和备库之间用iperf3测一下吞吐低于持续写入速率时瓶颈基本在网络。第二步确认备库磁盘性能。备库的恢复进程是单线程写盘随机写性能差会拖慢恢复速度。建议备库使用SSD或者调整full_page_writes和wal_compression等参数减小写入量。第三步分析主库端的walsender进程。在备库上执行查询看接收LSN和重放LSN的差值SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()) AS diff_bytes;如果receive_lsn和replay_lsn差距持续拉大说明恢复进程跟不上如果receive_lsn本身落后主库插入位置问题出在网络或主库端推送速度。这两个场景的优化方向完全不同。5.2 主备断开重连后的时间线冲突备库长时间断开后重连如果主库经历过一次切换时间线变化直接重连会报错FATAL: requested timeline 2 does not contain recovery point 0/6000000这是因为备库还在请求旧时间线的WAL而主库已经切换到新时间线了。此时需要做的是把备库重新基于新主库做一次pg_basebackup或者使用pg_rewind快进到新时间线。生产环境建议用Patroni或repmgr做自动处理手动处理时最容易犯的错误是直接删掉整个备库目录重做全量备份如果数据量大恢复时间会非常长。5.3 协议层抓包与Message内容分析当真正常规手段定位不了问题时就该上协议层技术了。PostgreSQL的复制协议没有加密细节时可以直接用tcpdump抓包tcpdump -i eth0 -s 0 -w /tmp/pg_copy.pcap tcp port 5432然后通过Wireshark打开过滤postgresql协议你会看到完整的Identify System、Start Replication、CopyData消息流。如果看二进制字节不方便可以使用Wireshark的PostgreSQL解析器直接展示XLogData的消息头和负载大小。这种方法能快速判断是连接在START_REPLICATION阶段就失败协议没握手成功还是在后续CopyData阶段断了传输中断这对排除DNS解析、防火墙状态、认证超时等问题帮助很大。我遇到过一个诡异案例备库每运行17小时左右就断连一次重连后一切正常。日志里没有任何报错TCP层也没有RST。最后靠抓包发现是主库和备库之间有个负载均衡器空闲连接超时设为17小时把长连接断掉了。解决办法很简单在primary_conninfo里加上keepalives_idle、keepalives_interval连接参数让系统层面的心跳包能及时刷新负载均衡器的状态。5.4 常见问题速查表现象可能原因排查方法备库长时间状态为startup认证失败或WAL位置无效查看主库日志确认pg_hba.conf规则检查START_REPLICATION请求位置state为catchup但迟迟不进入streaming备库正在追赶大量积压WAL查看replay_lag评估追赶预计时间不必干预WAL磁盘持续增长复制槽激活但备库离线查询pg_replication_slots确认active状态同步复制下主库写入卡住同步备库故障或延迟高检查sync_state确认synchronous_standby_names配置备库切换后无法接受只读查询replay位置未追平查看pg_last_wal_replay_lsn确认恢复已到达一致性点6. 协议演进回顾与关键版本特性流复制协议从9.0诞生到现在每个大版本都有实质性的增强这些演进直接决定了你手上的版本能做什么、怎么优化。我把关键节点挑出来方便你做版本选型和特性评估。9.0版本引入了物理流复制协议本体支持流式WAL传输但当时的设计限制很多比如备库必须通过recovery.conf配置切换也依赖人工操作。9.1版本加入同步复制机制和synchronous_standby_names开始有能力支撑金融级场景。9.4版本是最重要的一个里程碑复制槽机制诞生同时引入了逻辑复制的概念输出插件逻辑解码这套架构一直沿用到现在。10版本做了一次大整合把同步复制的优先级语法从synchronous_standby_names node1升级为FIRST/ANY语法并且引入了两阶段提交协议支持。11版本开始加入pg_rewind工具针对时间线冲突的问题给出了正规解决路径。12版本用standby.signal文件取代recovery.conf把备库配置统一归入postgresql.conf简化了运维心智负担。13版本起同步复制的管理粒度更细支持通过SQL直接管理复制槽pg_replication_slots视图增加confirmed_flush_lsn等字段逻辑复制也允许在多个发布端和订阅端之间做双向复制需要额外插件。14版本加入了pg_walinspect工具可以直接查看WAL内容排查复制问题时不用再盲猜。15版本之后流复制协议的最大变化在于对压缩的支持通过参数wal_compression控制以及当主库配置了多个同步备库时支持quorum-based的确认机制进一步降低同步阻塞风险。这些特性叠加在一起让PostgreSQL的高可用能力在开源数据库里已经属于第一梯队甚至部分能力超过了商业数据库的默认实现。选型建议很简单如果你的技术栈允许优先使用16或17版本。16版本在共享内存和IO方面做了大量优化对高并发复制场景的承受能力更强17版本则进一步完善了逻辑复制和监控视图。如果因为历史原因停留在老版本至少应该知道你现在用的版本在协议层缺了什么。比如PG10以前的版本没有复制槽备库离线久了连回去基本等于重新搭这种限制会直接颠覆你的运维流程设计。7. 监控与预防性维护的落地经验7.1 必看的监控指标与告警阈值流复制跑起来只是开始持续稳定运行才是重点。我自己的监控体系围绕以下几个指标每个都有明确告警阈值复制延迟主库的pg_stat_replication中write_lag、flush_lag、replay_lag任一项持续时间超过30秒则告警。注意write_lag是传输延迟replay_lag是重放延迟两者超过阈值的原因不同。复制槽状态activefalse持续超过15分钟或restart_lsn距离当前WAL写入位置的量超过磁盘容量20%时告警。WAL生成速率与保留空间通过pg_wal目录大小变化估算超过总磁盘空间50%时预警80%时紧急因为清理不及会导致不可恢复的复制中断。主备角色漂移定期在主库执行pg_is_in_recovery()并对比各节点结果防止出现双主分裂或无人为主。监控采集有个细节pg_stat_replication视图是在主库上查询的备库侧没有对应视图。如果想在备库侧看自己的状态需要查询pg_stat_wal_receiver视图它展示接收端的连接信息、最新接收位置、状态等。这套配套的监控脚本我建议直接用开源的pg_monz或者自建一套Python采集脚本避免过度依赖管理面板。7.2 预防性检查清单每次做版本升级或者机房迁移之前我习惯按这份清单检查一遍能把大多数故障消灭在萌芽期[ ] 主备版本一致且小版本不低于主库最好完全同版本[ ] 主库max_wal_senders和max_replication_slots是否覆盖所有备库[ ] 复制账号密码是否有泄露风险pg_hba.conf中replication条目是否限制了来源IP[ ] 备库的磁盘IO能力是否支撑全量备份后的持续追平[ ] 同步复制环境下synchronous_standby_names列表是否已涵盖所有关键备库[ ] pg_wal目录是否纳入备份和清理策略比如通过pg_archivecleanup配合archive_command[ ] 如果使用复制槽是否配置了槽回收机制或定时巡检任务我在实际生产中踩过一个典型的坑新加了一台备库但忘了更新复制槽数量上限结果那台备库在启动几十秒后就被主库断开日志显示slot不存在或max_slot_wal_keep_size限制。这类配置问题如果提前跑一遍检查清单几分钟就能发现。7.3 长期运行中的资源老化与重搭策略流复制有一个隐藏问题很少被人提备库长期运行后由于WAL重放的随机性磁盘页面碎片化程度会逐渐加重导致同一个数据目录的整体性能不如刚搭建时。这种情况在大版本升级或者硬件更换时最容易暴露因为此刻往往要做全量重新同步。因此我的建议是每半年或者每次大版本升级时评估一下备库的响应延迟是否偏离基线。如果备库的重放延迟从稳定值慢慢爬升到偶尔跳变先排查硬件再看是否需要用pg_basebackup重搭一次。重搭虽然成本高但能让数据页重新对齐主库的物理排列后续的流复制性能也会更好。这种“预防性重搭”在大型集群里是很常规的运维动作不是故障处理。8. 从协议走向高可用架构的扩展思考流复制协议本身只解决了数据同步的问题但它衍生出的应用形态非常丰富。我这里聊几个实战中常见的扩展方向帮你理解协议能力边界和架构演化路径。第一类扩展是读写分离中间件。Pgpool-II、HAProxy等工具本质上是在复用流复制协议建立的主备链路把读流量分发到备库。但要注意备库在恢复模式下虽然能接受读查询延迟水平却不一定能满足所有业务。中间件的读一致性控制如延迟超过阈值剔除节点就是基于流复制协议的延迟参数做的。第二类扩展是故障自动切换和管理器。Patroni是当前事实标准它通过更新etcd或Consul中的领导键来仲裁主备关系但底层的健康检查和切换动作完全基于流复制协议的状态。你可以把Patroni理解为“给流复制协议加了一层自动控制器”它做的事情就是持续探测WAL接收状态、时间线信息并在主库故障时选一台数据最接近主库的备库提升为新主。第三类扩展是跨数据中心容灾。这里通常采用级联复制或者同步复制跨机房部署。级联复制的拓扑里一台备库同时承担了“下游备库的主库”角色靠的是walsender进程可以同时为多个备库服务的能力同步复制跨机房则在两地三中心里管理网络延迟和仲裁关系这个场景下流复制协议的quorum机制就非常有价值。如果继续向上延伸到全链路数据平台还可以把WAL通过流式管道接入消息队列比如基于wal2json或decoding进入Kafka形成实时的CDCChange Data Capture管道为数据仓库或搜索索引提供准实时同步。这一步的底层依然是流复制协议中的逻辑复制部分但逻辑上你已经把数据库的增量变更变成了可编程的流事件。这些扩展方向没有一个是脱离流复制协议本身能独立存在的。所以我才反复强调把协议层的细节吃透远比配好一套环境更有价值——因为架构设计、性能调优、故障排查的每一个决策最后都要落到协议的行为上。我自己多年的体会是流复制协议看起来只是几十页文档但真正理解和掌握它需要一个“从配置到源码、从现象到原理”的反复循环。如果你能独立完成一次手动协议握手再自己抓一次包分析完整的消息交互你对PostgreSQL高可用的理解层次就已经超过大半数DBA了。