openGauss 主从架构核心原理.信创运维工程师技术教程

一、openGauss 主从架构核心原理

openGauss 主从架构基于物理流式复制实现，核心由「主库（Primary）」「备库（Standby）」「Wal Sender 进程」「Wal Receiver 进程」组成，架构逻辑如下：

主库将事务日志（WAL，Write-Ahead Log）写入本地 WAL 文件；

主库的 Wal Sender 进程实时推送 WAL 日志到备库；

备库的 Wal Receiver 进程接收日志并写入本地 WAL 缓存；

备库通过回放 WAL 日志，保持与主库数据一致（默认异步复制，支持同步复制）；

主从切换时，备库提升为新主库，原主库（若恢复）可转为备库。

核心特性：

高可用：主库故障时，备库可快速接管，RTO 低至分钟级；

读写分离：主库承担写请求，备库分担读请求，提升并发能力；

数据备份：备库可作为热备，避免备份对主库性能影响。

二、主从架构部署关键要点（基础运维前置）

部署前提
硬件要求：主备节点配置一致（推荐 8C16G 以上，存储 IOPS ≥ 1000）；
网络要求：主备节点网络延迟 ≤ 10ms（建议万兆网卡，避免日志传输卡顿）；
系统环境：CentOS 7.6+/EulerOS 2.0 及以上，关闭 SELinux、防火墙（或开放 5432 端口）；
软件版本：openGauss 3.0 及以上（推荐稳定版，支持自动主从切换）。
核心配置文件（postgresql.conf + pg_hba.conf）
（1）主库 postgresql.conf 关键配置

启用归档（主从复制基础）

archive_mode = on

archive_command = 'cp %p /opt/opengauss/archive/%f' # 归档目录需提前创建，权限为 omm:dbgrp

archive_timeout = 60s # 超时强制归档，避免日志堆积

复制相关配置

wal_level = replica # 日志级别（replica 满足主从复制）

max_wal_senders = 5 # 最大并发发送进程数（≥备库数量）

wal_keep_size = 16MB # 保留日志大小（避免备库同步时日志被删除）

hot_standby = on # 支持备库热备（读写分离场景必开）

（2）主库 pg_hba.conf 配置（允许备库连接）

允许备库（192.168.1.102）通过复制用户连接

host replication repl_user 192.168.1.102/32 md5

（3）备库 postgresql.conf 关键配置

hot_standby = on # 备库允许只读查询

max_standby_streaming_delay = 30s # 备库同步延迟阈值（超阈值则中断只读查询）

wal_receiver_status_interval = 10s # 备库向主库汇报状态间隔

（4）备库 recovery.conf 配置（核心复制文件）

standby_mode = 'on' # 标识为备库

primary_conninfo = 'host=192.168.1.101 port=5432 user=repl_user password=Repl@123 dbname=postgres application_name=standby1' # 主库连接信息

restore_command = 'cp /opt/opengauss/archive/%f %p' # 从归档目录恢复日志（主库归档目录需共享给备库，如 NFS）

recovery_target_timeline = 'latest' # 同步到最新时间线

部署验证

主库查看复制进程

gsql -d postgres -U omm -p 5432 -c "select pid, usename, application_name, state from pg_stat_replication;"

正常输出：state 为 streaming（流式复制中）

备库查看同步状态

gsql -d postgres -U omm -p 5432 -c "select pg_is_in_recovery();"

正常输出：t（表示备库处于恢复模式）

gsql -d postgres -U omm -p 5432 -c "select now() - pg_last_xact_replay_timestamp() as delay;"

正常输出：delay 接近 0（同步延迟≤1s）

三、日常运维核心操作（高频场景）

主从状态监控
（1）关键监控指标
复制状态：主库 pg_stat_replication 视图（state 需为 streaming）；
同步延迟：备库 pg_last_xact_replay_timestamp() 与主库当前时间差（≤3s 为正常）；
日志传输：主库归档目录日志是否持续生成，备库是否正常接收；
进程状态：主库 Wal Sender、备库 Wal Receiver 进程是否存活（ps -ef | grep wal）。
（2）自动化监控脚本示例（定时执行，异常告警）
#!/bin/bash

备库同步延迟监控

DELAY=$(gsql -d postgres -U omm -p 5432 -t -c "select extract(epoch from (now() - pg_last_xact_replay_timestamp()))::int;" 2>/dev/null)

if [ KaTeX parse error: Expected 'EOF', got '#' at position 26: ...30 ]; then #̲ 发送告警（如邮件、钉钉） ...DELAY s" | mail -s "openGauss 主从同步告警" ops@company.com

读写分离配置

通过应用层或中间件（如 MyCat、pgBouncer）实现读写分离：

写请求路由到主库（192.168.1.101:5432）；

读请求路由到备库（192.168.1.102:5432）；

备库只读验证：

-- 备库执行写操作会报错（正常现象）

insert into test_tb values (1);

-- 错误提示：ERROR: cannot execute INSERT in a read-only transaction

主从切换操作（手动切换）

（1）正常场景切换（主库维护）

1. 主库执行切换准备（禁止新事务，等待现有事务完成）

gsql -d postgres -U omm -p 5432 -c "select pg_wal_replay_resume();"

gsql -d postgres -U omm -p 5432 -c "select pg_stop_backup();"

2. 备库提升为主库

gsql -d postgres -U omm -p 5432 -c "select pg_promote();"

3. 验证新主库状态

gsql -d postgres -U omm -p 5432 -c "select pg_is_in_recovery();" # 输出 f（非恢复模式）

4. 原主库转为备库（修改 recovery.conf 指向新主库，重启数据库）

（2）异常场景切换（主库宕机）

1. 确认主库宕机（ping 不通、数据库进程不存在）

2. 备库强制提升为主库

gsql -d postgres -U omm -p 5432 -c "select pg_promote(true);" # true 表示忽略主库状态

3. 原主库恢复后，重新配置为备库

清理原主库数据目录（保留配置文件）

rm -rf /opt/opengauss/data/*

从新主库备份数据并恢复

gs_basebackup -h 192.168.1.102 -p 5432 -U repl_user -D /opt/opengauss/data -F p -X stream -P -v

修改 recovery.conf 指向新主库，重启数据库

数据备份与恢复（基于主从架构）
备库备份：避免备份对主库性能影响，在备库执行全量备份：
gs_basebackup -h 192.168.1.102 -p 5432 -U omm -D /opt/opengauss/backup/$(date +%Y%m%d) -F p -X stream -P
日志备份：主库归档日志需保留至少 7 天，用于时间点恢复（PITR）；
恢复测试：定期从备份恢复数据到测试环境，验证备份可用性。
四、常见故障处理（运维重点）
主从同步中断（备库 Wal Receiver 进程异常）
故障现象
备库 pg_stat_replication 无记录；
备库日志显示：could not receive data from WAL stream: connection closed。
处理步骤
检查主备网络：ping 192.168.1.101 + telnet 192.168.1.101 5432，确保网络连通；
检查主库 Wal Sender 进程：ps -ef | grep wal_sender，若未启动，重启主库；
检查备库 Wal Receiver 进程：ps -ef | grep wal_receiver，若未启动，重启备库；
若日志缺失导致同步失败，需重新初始化备库：

1. 备库停止数据库

gs_ctl stop -D /opt/opengauss/data

2. 清理备库数据目录

rm -rf /opt/opengauss/data/*

3. 从主库重新同步全量数据

gs_basebackup -h 192.168.1.101 -p 5432 -U repl_user -D /opt/opengauss/data -F p -X stream -P

4. 重启备库

gs_ctl start -D /opt/opengauss/data

备库同步延迟过大（延迟 > 30s）

故障原因

主库写入压力大（WAL 日志生成速度超过传输速度）；

主备网络延迟高（如跨机房部署）；

备库硬件性能不足（CPU/IO 瓶颈，回放日志缓慢）。

处理方案

优化主库写入：拆分大事务，避免批量插入导致 WAL 日志突发增长；

提升网络带宽：跨机房场景使用专线，降低网络延迟；

优化备库性能：升级 CPU/SSD，调整备库 shared_buffers（建议物理内存的 25%）；

启用同步复制（牺牲部分性能，保证数据一致性）：

主库 postgresql.conf 增加 synchronous_standby_names = 'standby1'（standby1 为备库 application_name）。

主库归档目录满（导致主库无法写入）
故障现象
主库日志显示：archive command failed with exit code 1；
主库无法执行写操作（如 insert/update）。
处理步骤
紧急清理归档目录：删除 7 天前的归档日志（保留最近备份对应的日志）；
扩展归档目录存储空间（如挂载新磁盘）；
优化归档策略：启用日志轮转，设置归档日志保留天数（如通过定时脚本删除过期日志）。
五、性能优化建议（主从架构专属）
复制性能优化
主库：wal_buffers 调整为 64MB（减少 WAL 日志刷盘次数）；checkpoint_timeout 设为 30min（减少 checkpoint 对复制的影响）；
备库：shared_buffers 设为物理内存的 25%，work_mem 设为 64MB（提升日志回放效率）；
网络：禁用主备节点的防火墙（或开放 5432 端口），关闭网卡节能模式。
读写分离优化
避免备库长事务：备库只读查询若执行时间过长，会导致同步延迟，建议查询超时设为 10s；
热点读路由：将高频读请求分散到多个备库（openGauss 支持一主多备）；
应用层适配：写操作后需读最新数据时，强制路由到主库（避免备库同步延迟导致数据不一致）。
监控优化
部署 Prometheus + Grafana 监控：通过 openGauss exporter 采集复制延迟、进程状态、日志传输等指标，配置可视化面板；
日志监控：开启主备库的 log_min_messages = warning，定期分析日志中的报错信息（如复制中断、连接失败）。
六、总结
openGauss 主从架构的运维核心在于「稳定复制、快速切换、精准监控」：日常运维需重点关注同步延迟、进程状态、日志归档三大核心；故障处理需遵循「先定位原因，再执行操作」的原则，避免盲目切换导致数据丢失；性能优化需结合主从架构特性，平衡一致性与并发能力。通过本文的运维实践指南，可帮助运维人员构建高可用、高性能的 openGauss 主从集群，为业务稳定运行提供保障。