5.1 主备复制原理与搭建

5.1 主备复制原理与搭建

本节摘要：物理流复制把主机的 WAL 日志实时传给备机重放，是 openGauss 高可用的地基。本节讲清同步级别参数的取舍逻辑，给出从零搭建一主一备的完整流程，并用真实案例拆解回放延迟的三类成因。

一个反例：为什么"装好了"不等于"能用"

某项目交付时主备环境搭建完成，验收测试一切正常。上线第三个月，主机一次批量更新让备机回放延迟冲到十分钟，业务方在备机上的报表读到的是十分钟前的数据，差评工单直接打到项目经理。复盘发现：环境搭的时候没人为"延迟多少算正常"定过阈值，没人对批量窗口做过回放压力预估，同步级别参数按文档默认值抄的、没人说得清选它的理由。安装成功只覆盖了本节四分之一的内容——剩下四分之三是参数取舍、监控阈值与故障演练。带着这个反例，我们把原理和实操一起讲。

原理：复制的就是那本日志

第 2 章讲过，任何数据修改都先记 WAL 日志再落数据页。流复制做的事情朴素到令人感动：主机把日志按字节流实时发给备机，备机回放这些日志，于是两台机器的数据页走向一致。理解三个要点。第一，复制单位是物理日志而不是 SQL 语句，备机不执行 SQL，只重放数据页变更——这也是主备版本与参数必须严格一致的原因。第二，同步级别是一道可调的保险丝：参数设为同步提交时，主机要等备机确认收到并写入日志才向应用报提交成功，做到不丢已提交事务，代价是每次提交多一个网络往返；设为异步则主机提交不等备机，故障切换时可能损失最近若干秒的事务。第三，备机可读，报表与只读查询可以分流到备机，但要接受读到的数据有回放延迟这个客观事实。

动手：从零搭一套一主一备

以下流程在测试环境完整可复现，命令为示意格式，路径按实际安装目录调整。

# 第一步 主机准备：创建复制专用账号
gsql -d postgres -c "CREATE USER repl WITH REPLICATION PASSWORD 'Repl@1234';"
# 第二步 主机配置：允许备机连接复制
# 在认证文件中增加复制规则，在主配置中设置监听与同步级别
# listen_addresses = '*'
# synchronous_standby_names = 'dn_isorepl1'
# 第三步 基础备份：用主备搭建工具从主机克隆数据目录到备机
gs_basebackup -D /data/standby -h 主机IP -p 5432 -U repl -W
# 第四步 备机生成配置并启动为备机模式
# 备机配置文件中写入主备连接串与应用名，应用名须与同步配置匹配
gs_ctl start -D /data/standby -M standby
# 第五步 验证：主机查询备机状态
gsql -d postgres -c "SELECT client_addr, state, sync_state FROM pg_stat_replication;"
# 预期输出一行：state 为 streaming，sync_state 为 sync
​

搭完必做的三件收尾：在备机跑一遍只读查询确认可读；在主机做一次小事务更新并在备机立即查到，验证端到端链路；把"备机回放延迟秒数"接入监控，阈值建议先设三十秒告警、五分钟升级。

图：流复制链路与三类延迟成因

延迟排障实战：三类成因的现场识别

案例一，洪峰型。月初跑批向交易表灌两千万行，备机延迟八分钟。识别特征：主机侧日志产生速率在跑批窗口陡增，备机回放线程满负荷。处置：跑批改分批提交、错峰到业务低谷，并把"跑批当晚备机延迟预期升高"写进变更单——预期管理有时比技术修复更重要。案例二，冲突型。备机上跑着长查询报表，主机更新了报表正在读的表，备机回放该日志时与本地查询冲突，按参数选择让查询优先，回放推迟，延迟累积。识别特征：延迟与备机上特定查询的起止时间吻合。处置：给备机查询设置语句超时、调整回放等待参数、或把报表迁到专门的延迟备机。案例三，瓶颈型。备机磁盘老化，回放写入吞吐上不去，延迟常年缓涨。识别特征：与负载无关的持续延迟，备机磁盘利用率高位。处置：换盘或迁库，这类是硬件问题，参数救不了。

同步级别的深读：N 个备机怎么组合

一主多备时，同步级别参数的组合方式比单备时丰富：可以要求"至少一台同步备机确认"、可以指定备机名单、可以配置同步与异步备机的混编。组合的选择逻辑回到业务问题：你防的是什么？防单点故障，一台同步加任意异步即可；防数据丢失且要求读扩展，两台同步（或一台同步一台潜在同步）加异步读备机。还有一个常被忽略的细节：同步备机失联时主机的行为——严格模式下主机停止服务等备机回归，宽松模式下自动降级为异步继续服务。两种策略对应两种业务哲学：宁可停服不丢数据，宁可冒丢尾风险不停服。这个选择必须由业务方签字，交付文档里要白纸黑字——它是 5.3 切换预案的第一块基石。

常见搭建故障速查

第一次搭主备，报错往往集中在几个固定位置。连接被拒：按顺序查认证文件是否包含复制条目、监听地址是否放通、防火墙与安全组规则、复制账号的权限；基础备份中断：查主机磁盘空间（克隆需要与数据量等身的空间）、复制账号权限、网络稳定性；备机起不来：查配置文件里的主备连接串写法、数据目录属主与权限、版本是否严格一致；状态显示不是流复制：查应用名与同步配置是否匹配、备机恢复配置是否生效。这套速查表覆盖了新手搭建故障的绝大多数——遇到表外的情况，抓取两端的日志关键字到社区检索，通常已有前人踩坑。

复制链路的日常巡检项

主备搭好之后，链路巡检固化成每日动作：查复制状态（流是否正常、同步级别是否符合设计）、查回放延迟曲线（异常毛刺往往对应夜间的批任务，属正常波动）、查日志传输错误计数（偶发网络闪断会有记录，频繁出现就要查网络质量）、查备机磁盘的日志保留空间（保留过少会强制清理，影响备机的追平能力）。四项巡检加起来不超过五分钟，建议做成脚本输出一屏结果。特别提醒一个容易忽略的点：主备切换演练之后，复制方向的配置要按新拓扑重新核对——演练切过去的配置残留，是下次真故障时的隐形地雷。

同步复制下的雪崩防御

严格同步模式有一个必须预演的故障分支：备机失联时，主机的提交全部等待直至超时——如果不设防，备机的网络故障会演变成主机的写服务停摆，高可用架构反而制造了新的单点。防御手段按层级：提交等待参数设置超时上限，超时后按策略降级为异步并发出明确告警，避免无限等待；降级动作要与业务方的事前约定一致（"最多等三秒，然后自动降级并通知"），这条约定写入 5.3 的切换预案。演练清单里加一个场景：切换演练时拔掉备机网线，观察主机在等待期、降级期、备机回归期的完整行为与告警链路。预演过的降级是预案，没预演的降级是事故——这句话在同步复制场景里字字都是经验。

备机可读的边界约定

备机可读虽好，边界要事先与业务方约定清楚，约定三件事。第一，延迟容忍度：业务能接受读到多少秒之前的数据，这决定哪些查询允许上备机——对账类查询通常不能容忍，报表类大多可以。第二，一致性敏感查询的处理：会话内"写后立即读"的查询不能去备机（写发生在主机，备机可能还没回放到），应用的路由层要识别这类查询强制回主机。第三，备机故障时的降级路径：备机不可用时只读流量是自动回主机（接受主机压力上升）还是直接失败（保护主机），两种策略选一个并写进预案。三件事谈清楚，备机可读才会是助力而不是新的投诉源。经验上，一半以上的"备机读出旧数据"投诉，根源都是第一件事没约定。

本节要点回顾

• 复制的是物理日志：主备一致性等同数据页一致性，版本参数必须严格一致；
• 同步级别是保险丝：同步不丢提交但加延迟，异步低延迟但切换可能丢尾，按业务代价选；
• 搭建五步：建账号、配同步、基础备份、起备机、验证链路，收尾必接监控；
• 延迟三成因：洪峰错峰、冲突让路、硬件换盘，对症下药；
• 阈值要预先定：三十秒告警、五分钟升级，预期写进变更单。

链路保住了增量，存量还得靠备份——下一节讲怎么备、怎么恢复、怎么演练。