openGauss 主从架构【华为根技术】

一、openGauss 主从架构核心原理

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

• 主库将事务日志（WAL，Write-Ahead Log）写入本地 WAL 文件；
• 主库的 Wal Sender 进程实时推送 WAL 日志到备库；
• 备库的 Wal Receiver 进程接收日志并写入本地 WAL 缓存；
• 备库通过回放 WAL 日志，保持与主库数据一致（默认异步复制，支持同步复制）；
• 主从切换时，备库提升为新主库，原主库（若恢复）可转为备库。

核心特性：

• 高可用：主库故障时，备库可快速接管，RTO 低至分钟级；
• 读写分离：主库承担写请求，备库分担读请求，提升并发能力；
• 数据备份：备库可作为热备，避免备份对主库性能影响。

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

1. 部署前提

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

2. 核心配置文件（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'  # 同步到最新时间线

3. 部署验证

# 主库查看复制进程
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. 主从状态监控

（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 [ $DELAY -gt 30 ]; then
    # 发送告警（如邮件、钉钉）
    echo "openGauss 备库同步延迟超过 30s，当前延迟：$DELAY s" | mail -s "openGauss 主从同步告警" ops@company.com
fi

2. 读写分离配置

通过应用层或中间件（如 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

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

（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 指向新主库，重启数据库

4. 数据备份与恢复（基于主从架构）

• 备库备份：避免备份对主库性能影响，在备库执行全量备份：

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）；
• 恢复测试：定期从备份恢复数据到测试环境，验证备份可用性。

四、常见故障处理（运维重点）

1. 主从同步中断（备库 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

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

故障原因

• 主库写入压力大（WAL 日志生成速度超过传输速度）；
• 主备网络延迟高（如跨机房部署）；
• 备库硬件性能不足（CPU/IO 瓶颈，回放日志缓慢）。

处理方案

• 优化主库写入：拆分大事务，避免批量插入导致 WAL 日志突发增长；
• 提升网络带宽：跨机房场景使用专线，降低网络延迟；
• 优化备库性能：升级 CPU/SSD，调整备库 shared_buffers（建议物理内存的 25%）；
• 启用同步复制（牺牲部分性能，保证数据一致性）：

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

3. 主库归档目录满（导致主库无法写入）

故障现象

• 主库日志显示：archive command failed with exit code 1；
• 主库无法执行写操作（如 insert/update）。

处理步骤

• 紧急清理归档目录：删除 7 天前的归档日志（保留最近备份对应的日志）；
• 扩展归档目录存储空间（如挂载新磁盘）；
• 优化归档策略：启用日志轮转，设置归档日志保留天数（如通过定时脚本删除过期日志）。

五、性能优化建议（主从架构专属）

1. 复制性能优化

• 主库：wal_buffers 调整为 64MB（减少 WAL 日志刷盘次数）；checkpoint_timeout 设为 30min（减少 checkpoint 对复制的影响）；
• 备库：shared_buffers 设为物理内存的 25%，work_mem 设为 64MB（提升日志回放效率）；
• 网络：禁用主备节点的防火墙（或开放 5432 端口），关闭网卡节能模式。

2. 读写分离优化

• 避免备库长事务：备库只读查询若执行时间过长，会导致同步延迟，建议查询超时设为 10s；
• 热点读路由：将高频读请求分散到多个备库（openGauss 支持一主多备）；
• 应用层适配：写操作后需读最新数据时，强制路由到主库（避免备库同步延迟导致数据不一致）。

3. 监控优化

• 部署 Prometheus + Grafana 监控：通过 openGauss exporter 采集复制延迟、进程状态、日志传输等指标，配置可视化面板；
• 日志监控：开启主备库的 log_min_messages = warning，定期分析日志中的报错信息（如复制中断、连接失败）。

六、总结

openGauss 主从架构的运维核心在于「稳定复制、快速切换、精准监控」：日常运维需重点关注同步延迟、进程状态、日志归档三大核心；故障处理需遵循「先定位原因，再执行操作」的原则，避免盲目切换导致数据丢失；性能优化需结合主从架构特性，平衡一致性与并发能力。通过本文的运维实践指南，可帮助运维人员构建高可用、高性能的 openGauss 主从集群，为业务稳定运行提供保障。