CentOS 7.8 安装 openGauss 配置一主两备高可用集群实战

我们做一个很实际的数据库部署任务：在 CentOS 7.8 上安装 openGauss，并配置成一主两备的高可用架构。

如果你已经接触过 openGauss，应该知道它是国内开源的关系型数据库，兼容 PostgreSQL 语法，主打企业级特性。但真正在生产或测试环境里把它跑起来、把主备关系搭好，很多人会在初始化参数、节点间的清理逻辑、同步模式的切换上卡住。这篇博文就是围绕这套流程，把我实测过的东西、踩过的坑、以及每一步背后的原因整理出来，给正要动手的你一份可以直接抄的作业。

先说清楚适用的场景：这个方案适合在测试环境验证 openGauss 高可用能力、为后续生产架构做预演，或者是你刚接触 openGauss、想快速搭一套集群观察主备同步和切换效果的场景。整个流程不用复杂工具，三台机器加命令行就能完成，核心命令我都会给出，参数也会说明为什么这么设。

1. 整体方案与架构设计

1.1 为什么选择一主两备

生产环境讲高可用，最常见的底线是“别单点”。一主一备已经能解决物理机宕机的问题，但备机本身也可能出故障、需要维护，或者机房层面的故障需要跨站点冗余，这时候两备的架构价值就出来了。

openGauss 的架构里，一主多备属于标准的 shared-nothing 架构，主节点提供读写服务，备节点通过物理日志复制保持数据一致性。两备意味着：

• 主机故障时有更大概率找到可切换的备机；
• 备机可以作为只读节点分担部分查询压力（取决于你配置的同步模式）；
• 某一台备机异常下线时，集群仍有剩余副本，不会立刻失去容灾能力。

当然两备也有代价：存储成本差不多是三份，主机写入要等待备机确认的耗时也会增加，尤其同步模式下更明显。所以这个测试就是为了摸清这套代价到底值不值。

1.2 方案选型的几个关键取舍

在动手之前，有几个方向性问题需要先定下来，否则装到一半会非常被动。

CentOS 7.8 的选择。openGauss 官方对操作系统的支持从 7.6 到 8.x 都有，7.8 在 glibc 版本和内核特性上满足要求，而且 7.x 系列的运维习惯大家都很熟悉。这里不要贪新用太高版本的系统，避免一些尚未踩平的兼容性问题。

安装方式。openGauss 提供企业版和轻量版，企业版的安装包本身包含一主多备的配置工具，也就是 openGauss 的 OM（运维管理）组件。我这次用的是企业版安装包，因为我们需要的是集群部署能力，不是单机体验。

数据同步方案。openGauss 主备同步有两种：同步模式和潜在模式。测试时我准备先跑同步模式，验证数据零丢失，再加压测试潜在模式的性能差异。

字符集和编码。初始化时直接指定 UTF-8，避免后续业务迁移时出现乱码问题。

1.3 资源规划与网络要求

三台机器的角色规划如下：

测试环境的机器配置不用太高，但有几个硬性要求不能忽略：

• 三台机器的 hostname 必须不同，建议直接按角色命名，比如 osdba-node1、osdba-node2、osdba-node3；
• /etc/hosts 必须写全三台机器的 IP 和 hostname 对应关系，并且每台机器都要一致；
• 确保 22 端口（SSH）、5432 端口（openGauss 默认端口）互相可达，防火墙要么关闭，要么放行，不要在这里浪费时间。

2. 安装准备与前置配置

2.1 操作系统基础配置

很多人一开始就急着解压安装包，实际上前置工作没做好，后面配置互信和执行安装脚本时会疯狂报错。我先梳理一遍必做项。

关闭防火墙和 SELinux，这是老生常谈，但在多节点部署时尤其重要，因为 openGauss 的 OM 工具会自动在各节点之间推送文件、执行命令，任何网络拦截都会导致半途失败：

systemctl stop firewalld systemctl disable firewalld sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config setenforce 0

配置各节点的主机名和 hosts 解析：

hostnamectl set-hostname osdba-node1 cat >> /etc/hosts << EOF 192.168.10.11 osdba-node1 192.168.10.12 osdba-node2 192.168.10.13 osdba-node3 EOF

如果你对 Linux 比较熟，会知道断开 SSH 再登录时主机名才会刷新，所以做完这些之后，直接退出重连一次，让环境干净起来。

2.2 创建用户与目录规划

openGauss 不允许使用 root 用户初始化数据库，官方要求用普通用户执行安装。规范做法是创建一个专用的数据库系统用户，比如 omm，设置密码后规划数据目录：

useradd omm echo "omm123" | passwd --stdin omm mkdir -p /data/opengauss && chown -R omm:omm /data/opengauss

这里有个细节：数据目录所在的磁盘分区空间要足够，裸容量至少有 50G 以上才比较从容。测试环境可能不大在意，但后面如果开启归档日志、WAL 日志累积，几十 G 很容易被吃掉。

内核参数也需要调整，前几次我直接跳过，结果初始化的时候报 shared memory 相关的错误。openGauss 对共享内存和信号量有要求：

cat >> /etc/sysctl.conf << EOF kernel.semmsl = 250 kernel.semmns = 32000 kernel.semopm = 100 kernel.semmni = 128 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 kernel.shmmni = 4096 kernel.msgmax = 8192 kernel.msgmnb = 16384 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 4194304 EOF sysctl -p

这些参数里，shmmax 和 shmall 是数据库进程使用共享内存的上限，改完之后最好重启一遍系统或者至少确认 sysctl -p 没有报错。

2.3 依赖库检查与安装

openGauss 安装过程中，会调用 Python 脚本做集群配置，还会用到一些基础的库文件。在纯最小化安装的 CentOS 7.8 上，容易出现缺库的情况。建议先把必备的工具装上：

yum install -y libaio-devel flex bison ncurses-devel glibc-devel patch readline-devel yum install -y python3 python3-devel

注意一点，openGauss 安装工具虽然自带部分运行环境，但对系统 Python 环境有依赖，最好提前确认 python3 能正常执行。如果机器的 yum 源有问题，先花时间修源，不要贸然开始安装。

2.4 互信配置

openGauss 的 OM 工具需要从执行节点免密登录其他节点，以便下发安装包、同步配置文件。官方工具会在安装过程中自动配置互信，但提前手动配好可以少走弯路，排查问题也更简单。

用 omm 用户执行：

su - omm ssh-keygen -t rsa -P ""

然后把每个节点的公钥都追加到其他节点的 authorized_keys 文件里。手动操作三台机器其实也不麻烦，就是循环执行：

ssh-copy-id omm@192.168.10.11 ssh-copy-id omm@192.168.10.12 ssh-copy-id omm@192.168.10.13

最终验证就是三台机器两两之间都能免密 SSH，尤其是从执行安装的节点发起的连接要通畅。

3. 下载与安装 openGauss

3.1 安装包选择

openGauss 的官方安装包分为企业版和轻量版。如果只需要单机，轻量版更合适，直接解压即用；但我们这种一主两备的集群需求，必须使用企业版，因为集群部署、节点配置、状态查询的命令都集成在 OM 组件中。

下载时注意对应版本和操作系统的类别，比如 x86_64 架构和 CentOS 7.8 的组合，不要下错包。有些版本的安装包解压后包含 setup 工具，有些版本则提供完整的 tar 包，逻辑上差不多，核心是最终能看到 script 目录下有 gs_install、gs_ctl、gs_om 这些可执行文件。

3.2 解压与安装目录设置

把安装包上传到三台机器的同一个路径，比如 /opt/software/openGauss，然后用 omm 用户解压：

su - omm mkdir -p /opt/software/openGauss tar -zxvf openGauss-x.x.x-CentOS-64bit.tar.gz -C /opt/software/openGauss/

解压后一般会得到一个名为 openGauss 的目录，里面包含了安装执行目录，最重要的就是 bin 和 script 目录。解压完成后不要着急下一步，先看一眼磁盘空间和文件属主：

chown -R omm:omm /opt/software/openGauss df -h /data/opengauss

目录属主不对会导致执行初始化时报 Permission denied，而磁盘空间不足则会导致初始化到一半直接失败，日志可能还没办法完整写出，排查起来很痛苦。

3.3 执行安装脚本

openGauss 企业版安装时，入口脚本通常集中在 installation 目录下。执行时使用 omm 用户：

cd /opt/software/openGauss/script ./gs_preinstall -U omm -G omm -X /opt/software/openGauss/conf/cluster_config.xml

这一步骤的作用是预检查操作系统环境、创建相关目录、完成互信配置等，它并不是真正初始化数据库，所以如果你在这个阶段看到某些 WARNING，比如“磁盘空间较小”“IO 调度策略非 deadline”等，先认知为警告而不是错误，但要注意区分 FATAL 和 ERROR。

如果预安装顺利结束，接下来就需要准备 cluster_config.xml 配置文件，再执行真正的初始化安装。

4. 一主两备集群的核心配置文件

4.1 cluster_config.xml 结构解析

这是整个一主两备部署中最关键的环节，配置文件的写法直接决定集群能不能建起来。官方模板位置在解压包内的 doc 目录，可以拷贝出来再改。

最简配置如下：

<?xml version="1.0" encoding="UTF-8"?> <ROOT> <CLUSTER> <PARAM name="clusterName" value="opengaussCluster" /> <PARAM name="nodeNames" value="osdba-node1,osdba-node2,osdba-node3" /> <PARAM name="gaussdbAppPath" value="/opt/software/openGauss/app" /> <PARAM name="gaussdbLogPath" value="/data/opengauss/log/omm" /> <PARAM name="tmpMocPath" value="/tmp/opengauss" /> <PARAM name="gaussdbToolPath" value="/opt/software/openGauss/tool" /> <PARAM name="corePath" value="/data/opengauss/corefile" /> <PARAM name="backupIp" value="192.168.10.11,192.168.10.12,192.168.10.13" /> </CLUSTER> <DEVICELIST> <DEVICE sn="node1"> <PARAM name="name" value="osdba-node1"/> <PARAM name="azName" value="AZ1"/> <PARAM name="azPriority" value="1"/> <PARAM name="backIp1" value="192.168.10.11"/> <PARAM name="dataNum" value="1"/> <PARAM name="dataPath" value="/data/opengauss/data"/> </DEVICE> <DEVICE sn="node2"> <PARAM name="name" value="osdba-node2"/> <PARAM name="azName" value="AZ1"/> <PARAM name="azPriority" value="1"/> <PARAM name="backIp1" value="192.168.10.12"/> <PARAM name="dataNum" value="1"/> <PARAM name="dataPath" value="/data/opengauss/data"/> </DEVICE> <DEVICE sn="node3"> <PARAM name="name" value="osdba-node3"/> <PARAM name="azName" value="AZ1"/> <PARAM name="azPriority" value="1"/> <PARAM name="backIp1" value="192.168.10.13"/> <PARAM name="dataNum" value="1"/> <PARAM name="dataPath" value="/data/opengauss/data"/> </DEVICE> </DEVICELIST> </ROOT>

每个参数的作用解释一下：

• nodeNames：集群内所有节点，逗号分隔，顺序建议与业务规划一致；
• gaussdbAppPath：openGauss 程序安装路径，需要在三台机器上保持一致；
• dataPath：数据目录，三台机建议一致，方便后期维护；
• azName 和 azPriority：表示同可用区，x86 架构下区别不大，但如果做跨机房容灾，这两个参数十分关键。

注意：配置文件中“sn”属性只是编号，不参与实际逻辑，可以随便写。

4.2 为什么配置节点顺序有讲究

nodeNames 的顺序不只是“列出节点”，它会决定主备初始化的次序和某些默认逻辑，比如哪台机器最可能被初始化为备机、工具执行时的节点排序。为了减少不确定性，我习惯把规划中的主节点放在第一位。

4.3 初始化主库并拉起数据库实例

配置文件写好后，真正执行初始化的命令是：

cd /opt/software/openGauss/script ./gs_install -X /opt/software/openGauss/conf/cluster_config.xml \ -L zh_CN \ --pkg=/opt/software/openGauss/openGauss-x.x.x-CentOS-64bit.tar.gz \ --data-char-set=UTF-8

这里的初始化步骤会做几件事：初始化主库数据目录、生成配置文件、启动实例、然后在其他节点上初始化备库。

如果这条命令没有一次通过，先看安装包和配置文件所在目录的日志，通常日志路径在 /data/opengauss/log/omm 下，找以 cluster 开头的日志文件。

初始化完成后，使用 gs_om 命令检查整个集群的状态：

gs_om -t status --detail

如果输出显示三台机器都是正常状态，且 Primary 节点是 osdba-node1、Standby 节点有 osdba-node2 和 osdba-node3，那恭喜你，基础集群已经成型。此时先创建一个测试用户和测试库，确认写入和查询正常：

gsql -d postgres -p 5432 -r CREATE USER test_user WITH PASSWORD 'Test@123'; CREATE DATABASE testdb OWNER test_user;

5. 主备同步测试与高可用切换验证

5.1 查看同步模式和流复制状态

openGauss 默认的同步模式可以在配置文件中查看，也可以用 SQL 查询：

SELECT * FROM pg_stat_replication;

如果能看到两个备机的 sender 状态为 active，且 write_location、flush_location 等逐渐推进，说明同步链路是通的。此时可以进一步查看主备同步模式：

gs_om -t status --detail

若当前是同步模式，输出中会标识 SYNC 状态。openGauss 支持同步、潜在（异步）两档，直接在配置文件中改 synchronous_mode 参数后重启才能生效。

5.2 数据同步一致性验证

最简单直接的方式就是建一张表，持续写入数据，然后在备机查询验证。

主机上执行：

CREATE TABLE sync_test (id int primary key, name varchar(50), ts timestamp default now()); INSERT INTO sync_test (id, name) VALUES (1, 'opengauss'); INSERT INTO sync_test (id, name) VALUES (2, 'standby_test');

然后在两台备机上分别查询：

gsql -d postgres -p 5432 -c "SELECT * FROM sync_test;"

正常情况下，备机能立刻看到主库提交的数据。但要注意，如果备库配置了只读模式，需要确认 SQL 是允许执行的只读语句，写操作会报错。

5.3 主备切换演练

切换演练是整个高可用验证的重头戏。openGauss 提供了两种切换方式：计划内切换和故障切换。

计划内切换使用：

gs_ctl switchover -D /data/opengauss/data

触发后，原主库会降级为备库，某个备库选举成为新的主库。这里有一点必须注意：运维时不要擅自 kill 主库进程来模拟故障，除非你确实要验证极端故障场景，否则会造成不必要的 WAL 日志残留。

如果是模拟故障切换：

gs_ctl failover -D /data/opengauss/data

执行后，备机提升为主机，原主机恢复后会自动尝试以备机身份重新加入集群。整个过程的详情可以通过日志观察。

切换完成后，再次执行：

gs_om -t status --detail

你会看到主备角色已经互换，此时在旧主机上继续写入不会成功，因为它的角色已经变成备机。

5.4 同步模式对延迟的影响

同步模式下，主库的每次提交都需要等待至少一个备机确认。测试结果表明：

• 单行写入同步模式和潜在模式的延迟差异大约在 1~3ms 左右，对于并发小的 OLTP 场景几乎无感；
• 批量写入场景差距会拉大，潜在模式明显写入更快；
• 同步模式下，如果某个备机挂了，主库提交会被阻塞或者降级（取决于配置），这也是需要权衡的地方。

所以如果业务对事务提交延迟非常敏感，但又能容忍极小的数据丢失窗口，潜在模式是有价值的。如果强调零丢失，则必须同步模式。

6. 常见故障与排查技巧

6.1 初始化时报权限不足

表现：gs_install 执行时报无法创建目录或无法写入文件。

原因基本都是 omm 用户对目标目录没有写权限，或者是某些目录属主是 root。解决办法很简单，重新检查 /data/opengauss 和 /opt/software/openGauss 的属主与 chmod。

6.2 节点之间无法连接

表现：gs_preinstall 时测试互信失败，或者数据库实例之间的复制通道建立不起来。

排查要点：三台机器的 /etc/hosts 是否完全一致，SSH 免密是否通，防火墙是否真的关闭。有些环境使用云安全组，需要额外确认安全组放行 5432 端口和 OM 工具使用的临时端口。

6.3 备机一直显示 Pending 或 Down

表现：gs_om -t status --detail 显示某个备节点状态异常。

优先看备机上的数据库日志，路径一般位于 /data/opengauss/log/omm/opengaussCluster 下，文件比如 postgresql-xxx.log。经常见的原因是磁盘空间满，或者 WAL 归档路径不可写。清理掉日志或者扩容后重新 start 实例即可。

6.4 主备切换后应用连接中断

应用在切换后无法连库，这是因为连接串里写死了主库 IP，没有使用虚拟 IP 或者负载均衡地址。openGauss 本身不做连接自动路由，所以应用层需要配合 VIP 或者连接池组件，比如经典的 keepalived 方案。测试过程中如果发现这个问题，也是合理的收获——实际生产架构必须规划好连接访问层。

6.5 备机恢复后如何重新加入集群

备机因故障宕机，恢复后先检查端口和目录，然后执行：

gs_ctl start -D /data/opengauss/data

正常情况下会自动连接主库并追平 WAL 日志。若日志差距太大，需要重新 build 备机：

gs_ctl build -D /data/opengauss/data

注意 build 操作会把备机数据目录清空，重新从主库拉全量数据，因此不要在生产环境随意操作，务必先确认备机数据已无价值。

7. 参数调优与生产环境注意事项

7.1 内存与连接配置

openGauss 的关键内存参数是 shared_buffers 和 max_connections。测试环境的默认配置能用，但生产环境建议按总内存的 25% 设置 shared_buffers，连接数根据实际并发评估。修改方式是在 postgresql.conf 中调整后重启实例。

7.2 WAL 日志与归档

openGauss 在同步模式下，WAL 日志量会显著增加，如果开启了归档，归档目录必须有足够空间。测试阶段可以暂时关闭归档以简化问题，但生产环境必须开启，否则 PITR 恢复无从谈起。

7.3 备份策略提醒

一主两备并不等于有备份。备机数据是基于物理日志的副本，无法应对误删除、DDL 错误等逻辑故障。因此，即使部署了高可用集群，仍然需要定期做全量备份，并保留备份文件在独立的存储位置。这一点经常被新人忽略。

7.4 监控建议

生产环境建议对每个节点配置监控脚本或接入监控系统，重点关注指标包括：主备复制延迟、备机状态、磁盘空间、连接数、共享内存使用率。openGauss 的 pg_stat_replication 视图提供了复制延迟的核心信息，定时采集这个视图的数据就够用。

8. 从测试环境到生产环境的思考

测试环境只需要验证功能，生产环境会面对更多实际问题，比如 IP 规划、机柜分布、跨机房容灾、灾备演练的周期等。但我始终认为，先把测试环境的这套流程跑通，把每个命令背后的原理弄清，比直接在生产环境强行部署更有价值。

关于后续扩展，一主两备验证通过后，你可以考虑在这个框架上继续加一主多备的节点，或者测试级联备机。openGauss 的选择相对灵活，逻辑类似，主要是配置文件中新增节点即可。另外，如果你想做读写分离，可以在备机上加只读负载均衡，但要注意同步模式下备机存在一定的资源开销，需要对业务做详细的压测。

最后再分享一个小技巧：部署这种多节点数据库环境时，建议每完成一个阶段就在终端记录下来，包括用到的命令、输出结果的异常和解决办法。等到整套环境搭完，你会发现自己有了一份比任何官方文档都更贴合自身环境的运维手册。我当初整理这组操作时，就是靠着阶段记录排查掉了两个隐藏问题，节省了大量时间。