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 资源规划与网络要求

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

节点	IP	配置	角色
节点A	192.168.10.11	4C8G，磁盘100G	主
节点B	192.168.10.12	4C8G，磁盘100G	备机1
节点C	192.168.10.13	4C8G，磁盘100G	备机2

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

三台机器的 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 方案。测试过程中如果发现这个问题，也是合理的收获——实际生产架构必须规划好连接访问层。