最近在 CentOS 7.8 上跑了一轮 openGauss 一主两备的安装测试趁着印象还清楚把整个流程、踩过的坑和验证结果整理出来。这次测试用的是三台内网虚拟机目标是搭一套主库可读写、备库实时同步、并通过手动切换验证高可用能力的集群环境。整个过程从系统准备、集群初始化到故障切换实测踩了不少报错也积累了一些经验。这篇文章适合正准备部署 openGauss 三节点集群、或者正在评估国产数据库高可用方案的读者参考直接对照操作能省掉不少试错时间。1. 一主两备方案的前期设计再确认1.1 为什么是一主两备而不是单机或双机单机数据库最大的问题不是性能而是故障时没有兜底。磁盘坏、内存故障、误操作删数据随便哪个都能让业务直接中断数据恢复完全依赖备份而备份本身也有延迟和丢失风险。主备双机虽然多了一个节点可以做到故障切换但风险其实也很明显只剩下一个备节点的时候它既是唯一的冗余又是故障切换后唯一的承载者如果这个节点刚好在切换前出现硬件异常、网络抖动或者磁盘空间不足整个集群就没有任何退路。一主两备的意义在于冗余度。openGauss 本身支持同步复制和异步复制混合配置两台备机可以一台走同步模式保证数据强一致另一台走异步模式负责兜底和分担读压力。即使同步备机在关键时点出问题异步备机还能立即顶上。对于生产环境的高可用诉求来说一主两备在成本和可靠性之间是比较均衡的配置。而且从测试角度讲两个备节点能顺带验证多节点同步时的一些细节行为比如备机角色提升、同步状态变化、原主节点重新建库这些是双机环境测不出来的。1.2 版本选型和操作系统兼容性梳理openGauss 的安装包分好几种形态最常见的是企业版和轻量版。一主两备这种多节点集群部署必须使用企业版安装包因为它自带完整的集群管理工具链gs_om、gs_install、gs_checkos 等可以通过一份 XML 配置文件一次性把三台机器的数据目录初始化、复制关系建立、集群状态管理全部搞定。轻量版更偏向单机或嵌入式场景很多集群管理命令是不带或者不完整的用来搭一主两备会非常别扭甚至压根走不通。操作系统方面这次用的是 CentOS 7.8x86_64 架构。openGauss 对 CentOS 7.x 的兼容性总体不错安装工具在 7.6、7.8、7.9 上都有实际部署案例。但 CentOS 7 默认自带的 Python 是 2.7而 openGauss 的安装脚本依赖 Python 3.6 及以上版本所以系统准备阶段必须额外装好 Python 3这是很多人装到一半报错才发现的问题。另外如果选择源码编译方式安装依赖会更复杂需要 gcc、flex、bison 等编译工具链耗时也更长。我这次直接用的企业版二进制包把主要精力放在集群配置和功能验证上。1.3 三台机器的节点规划和目录约定测试环境规划了三台同样的虚拟机角色分配如下角色主机名内网 IP数据目录日志目录主节点db1172.16.100.11/home/omm/data/dn/home/omm/log/dn同步备机db2172.16.100.12/home/omm/data/dn/home/omm/log/dn异步备机db3172.16.100.13/home/omm/data/dn/home/omm/log/dn数据目录统一放在 /home/omm/data/dn 下目的是让后续操作命令在三台机器上保持一致避免因为路径差异造成误操作。日志目录与数据目录分离是生产环境的基本习惯数据库运行日志、审计日志和实际数据文件如果混在同一块磁盘上高负载时日志写入会跟数据写入争抢 IO故障排查时也不容易定位。数据目录所在分区建议单独预留足够的空间一主两备下备库的 WAL 接收、数据 build、日常归档都会持续消耗磁盘我这次给每台机器额外挂了一块数据盘避免和系统盘互相挤占。2. 系统准备阶段互信、内核参数和依赖库2.1 创建专用账号并打通三机互信openGauss 明确规定不能使用 root 用户启动和运行集群我按常规做法创建了 omm 用户和 omm 用户组并在三台机器上都执行同样的操作groupadd omm useradd -g omm -m -d /home/omm -s /bin/bash omm创建好之后建议马上给 omm 设置一个密码后面很多操作会用到。然后最关键的一步是配置三台机器之间的 SSH 互信。openGauss 的集群安装工具在初始化过程中会通过 SSH 协议在三个节点之间分发文件、执行远程命令如果互信没配好安装程序会在连不上远程节点时直接中止。互信配置的常规做法是su - omm ssh-keygen -t rsa -N -f ~/.ssh/id_rsa ssh-copy-id omm172.16.100.11 ssh-copy-id omm172.16.100.12 ssh-copy-id omm172.16.100.13三台机器都需要把自己的公钥复制到另外两台这样任意节点之间互相 ssh 都不需要输密码。之后用ssh db1、ssh db2、ssh db3或者 IP 方式验证一下能免密登录再继续向下走。实际测试中遇到过一次因为 .ssh 目录权限是 755 导致互信失效的情况SSH 对 authorized_keys 的权限要求很严格目录是 700、文件是 600 才正常这个细节值得留意。2.2 安装依赖库这一步偷懒后面补的代价更大openGauss 在初始化数据目录和启动实例时会依赖一批系统库缺失的情况下报错信息往往模棱两可。比如 libaio-devel 缺失会导致异步 IO 初始化失败readline-devel 缺失会导致交互终端出现异常。我在三台机器上统一执行了下面的安装yum install -y libaio-devel flex bison ncurses-devel glibc-devel patch readline-devel gcc gcc-c make其中 flex 和 bison 是 SQL 语法解析器生成时需要的工具虽然企业版二进制包一般不需要现场编译 SQL 解析器但系统预检查阶段会扫描这些组件是否存在缺了会在环境检查环节直接警告甚至拒绝继续。readline-devel 关系到 gsql 客户端交互模式下的命令行编辑和历史记录能力不装的话 gsql 虽然能起来但用起来体验很差还会在特定操作下报错。Python 3 的安装也要在这个阶段完成。CentOS 7.8 的 yum 源如果配好了 epel直接yum install -y python3 python3 --version执行后看到 Python 3.6 或更高版本即可。openGauss 的安装脚本会调用 python3 命令如果系统里只有 python2.7安装时大概率会报Python path does not exist或者类似的解析错误。这个问题的隐蔽之处在于报错信息不会直接说需要 Python 3而是在环境检查或脚本解释阶段绕来绕去让人误以为是安装包损坏。2.3 内核参数、资源限制与 SELinux 处理数据库对操作系统共享内存、网络缓冲和进程限制都有比较明确的要求这一步直接决定后面的初始化能否一次通过。在三台机器的 /etc/sysctl.conf 中统一追加以下配置并sysctl -p生效kernel.sem 250 32000 100 128 kernel.shmall 1073741824 kernel.shmmax 549755813888 net.core.rmem_max 21299200 net.core.wmem_max 21299200 net.ipv4.tcp_rmem 8192 87380 2048000 net.ipv4.tcp_wmem 8192 87380 2048000 vm.overcommit_memory 0kernel.shmmax 和 kernel.shmall 必须足够大因为 openGauss 的共享内存段包含了 shared_buffers、WAL 缓冲区以及其他共享数据结构。实际生产环境下如果 shared_buffers 配置了几个 GB 而 shmmax 设置过小数据库启动时会直接报could not create shared memory segment这个报错非常经典。网络参数的调整主要是为了支撑主备节点之间的 WAL 传输备库在追主库日志时如果网络缓冲太小高吞吐场景下会出现延迟波动。还需要修改 /etc/security/limits.conf为 omm 用户放开文件句柄和进程数限制omm soft nofile 1000000 omm hard nofile 1000000 omm soft stack 10240 omm hard stack 32768SELinux 的处理也很重要。CentOS 7 默认开启 SELinux enforcingopenGauss 的初始化脚本和数据库进程在访问数据目录、创建 socket 文件时会频繁被策略拦截而且被拦截后日志里不一定有直观提示排查起来极其痛苦。我在测试节点上统一setenforce 0并修改 /etc/selinux/config 里SELINUXpermissive保证重启后也不会自动回到 enforcing。防火墙方面测试环境直接放行了三台机器之间的 5432 端口避免数据库通信端口被挡住导致备机永远连不上主库。3. 集群安装实操XML 配置和 gs_install3.1 解压安装包并准备 cluster_config.xmlopenGauss 企业版安装包拿到后我放在每台机器的 /opt/software 目录下用 omm 用户解压。安装包解压后会得到数据库二进制、脚本工具和模板文件。集群安装的核心是准备一份 cluster_config.xml它描述了三节点的角色、IP、路径和拓扑关系。下面是我实际使用的 cluster_config.xml 的核心结构CLUSTER PARAM nameclusterName valueogCluster/ PARAM namenodeNames valuedb1,db2,db3/ PARAM namegaussdbAppPath value/home/omm/app/ PARAM namegaussdbLogPath value/home/omm/log/ PARAM nametmpMppdbPath value/home/omm/tmp/ PARAM namegaussdbToolPath value/home/omm/app/ PARAM namecorePath value/home/omm/core/ PARAM namebackIp1s value172.16.100.11,172.16.100.12,172.16.100.13/ MODE nameprimary valuedb1/ MODE namestandby valuedb2/ MODE namestandby valuedb3/ NODE namedb1 PARAM namebackIp1 value172.16.100.11/ PARAM namedataNum value1/ PARAM namedataPath value/home/omm/data/dn/ PARAM namelogPath value/home/omm/log/dn/ /NODE NODE namedb2 PARAM namebackIp1 value172.16.100.12/ PARAM namedataNum value1/ PARAM namedataPath value/home/omm/data/dn/ PARAM namelogPath value/home/omm/log/dn/ /NODE NODE namedb3 PARAM namebackIp1 value172.16.100.13/ PARAM namedataNum value1/ PARAM namedataPath value/home/omm/data/dn/ PARAM namelogPath value/home/omm/log/dn/ /NODE /CLUSTER关于同步备机和异步备机的区分openGauss 在初始化阶段会根据同步参数来决定备机的同步模式。默认情况下两个 standby 节点都可以被选为同步备机具体哪个走同步、哪个走异步取决于复制队列中的角色状态和参数配置。如果要指定某个备机为同步备机需要在数据库参数中设置synchronous_standby_names我这次测试保留了默认配置让系统自动分配。XML 文件的权限要注意gs_install 会以 omm 用户读取该文件如果文件放在 root 目录或者权限是 600 且属主不是 omm安装时会出现读取失败的报错。把 cluster_config.xml 放在 /home/omm 下并确认属主为 omm 即可。3.2 配置环境变量并执行集群安装初始化环境变量是安装前最后一步准备工作。在 omm 用户的 ~/.bashrc 末尾追加以下内容export GAUSSHOME/home/omm/app export PATH$PATH:$GAUSSHOME/bin export LD_LIBRARY_PATH$GAUSSHOME/lib export PGDATA/home/omm/data/dn然后执行source ~/.bashrc让环境变量生效。这里需要注意gs_install 的过程本身会在各节点上自动分发安装包但 GAUSSHOME 路径必须与 cluster_config.xml 中的 gaussdbAppPath 保持一致不然后续命令会找不到二进制文件。确认环境无误后在安装包的解压目录下执行gs_install -X /home/omm/cluster_config.xml执行过程会依次完成系统环境检查、安装包分发、数据目录初始化、配置 pg_hba.conf、启动三节点集群等步骤。首次执行时我遇到过一次因 sudo 权限缺失导致的警告openGauss 的安装脚本会尝试在部分节点上检查 root 权限相关的满足条件但 omm 用户如果不在 sudoers 中某些检查项会以 warning 形式跳过并不影响整体安装。看到输出中出现类似Successfully installed的关键行时说明集群已经初始化完成。3.3 初始化后的集群状态检查安装完成后第一件事是确认集群状态。执行gs_om -t status --detail输出结果中三个节点的角色、状态、数据目录、端口信息都会显示出来。正常情况下 db1 标记为 Primarydb2 和 db3 标记为 Standby整体状态为 Normal。如果某个节点显示异常比如 Degraded 或者 Down需要先检查对应节点的数据目录是否存在、端口是否被占用、日志中是否有初始化错误。我还会单独在每个节点上执行一次gs_ctl query -D /home/omm/data/dn这个命令可以快速看到当前节点自身的角色和运行状态。db2、db3 上执行时如果显示 state 为 Secondary 或 Standby说明收到主库的复制流是正常的。如果这里显示 Primary说明主备角色混乱属于异常情况大概率是初始化时 XML 配置写错了。4. 一主两备的功能验证写入、同步与切换4.1 主库写入数据验证备库实时同步集群起来之后我用主库连接数据库创建了测试库和表gsql -d postgres -p 5432 -U ommCREATE DATABASE testdb; \c testdb CREATE TABLE user_info (id INT PRIMARY KEY, name VARCHAR(50), created_time TIMESTAMP DEFAULT now()); INSERT INTO user_info (id, name) VALUES (1, alice), (2, bob);数据写入后可以看复制状态SELECT * FROM pg_stat_replication;如果在主库执行这条查询会看到备机对应的 sender 信息state 列可能是 Sync同步复制或 Stream异步复制。Stream 状态说明主库发送 WAL 到备机但备机的确认机制是异步的Sync 状态说明备机已经确认收到对应 LSN此时主库的事务提交才算完成。然后在备机 db2 上以只读方式连接gsql -d testdb -p 5432 -U ommSELECT * FROM user_info;正常情况下能看到和主库一致的数据。openGauss 的备机是只读模式如果直接执行 INSERT 或 UPDATE会报cannot execute INSERT in a read-only transaction之类的错误这不是故障而是备机的设计行为。通过备机查询可以确认同步链路是通的数据确实实时复制到了备端。4.2 模拟主库故障手动提升备机openGauss 的高可用切换有两种场景。如果部署了 CMCluster Manager组件主库故障时可以实现自动 failover但我这次测试没有装 CM走的是 OM 工具的手动 failover 流程这也是最小化安装场景下最常见的处理方式。模拟故障的操作很简单在主库节点 db1 上直接停掉数据库进程gs_ctl stop -D /home/omm/data/dn -m immediate此时相当于主库宕机。然后到 db2 节点上执行gs_ctl failover -D /home/omm/data/dn执行成功后 db2 的角色会切换为 Primary。随后再执行 gs_om 状态查看可以看到 db2 变成了主库db3 作为备机继续同步db1 显示异常或离线状态。故障切换后我重新在新主库 db2 上插入了一条新数据然后到 db3 上查询确认数据能够继续同步整个链路恢复可用。手动 failover 之前有两个细节必须确认。第一执行 failover 的节点必须已经 catch up 到了主库的最新状态否则提升之后会丢失数据第二failover 前备机上不要有活跃的长事务或查询连接否则切换时会遇到锁或者连接占用导致的异常。实际操作中最好提前把应用连接断开再执行切换等角色确认后再恢复连接。4.3 把旧主节点重新纳回集群切换完成后还需要处理原主节点 db1。直接把它重新启动通常会出问题因为 db1 的数据目录里记录的角色还是 Primary它会下意识尝试以主库身份拉起并与当前的新主库产生冲突。正确做法是先做数据 rebuild让旧主变成全新的备机再纳入集群。我在 db1 上执行了gs_ctl build -D /home/omm/data/dnbuild 过程会从新主库重新加载基础数据和 WAL完成后 db1 就变成了一个干净的备节点。接着再启动数据库并执行gs_om -t status --detail确认 db1 恢复为 Standby 状态。这个流程看起来简单但回切确实比故障切换更容易踩坑。我第一次测试时没有做 build直接启动 db1结果两个节点同时认为是主库复制关系完全乱了最后只能清掉数据目录重新 build 才恢复正常。所以哪怕切换成功也不要急着调应用先把旧主处理干净再说。5. 部署期间的常见问题与排查清单5.1 高概率报错速查表整个部署过程里遇到的典型报错我整理成了下面这张速查表基本覆盖了一主两备部署最容易翻车的几类问题报错现象出现阶段常见原因解决办法[GAUSS-51400]: Failed to execute the command安装、互信验证阶段SSH 互信失效或 authorized_keys 权限错误重新配置互信保证 .ssh 目录权限 700authorized_keys 权限 600Python path does not exist或解释器相关错误环境检查阶段缺少 Python 3或 python3 不在 PATH 中安装 python3确认python3 --version可用could not create shared memory segment数据库启动阶段kernel.shmmax 或 shmall 设置过小调大 sysctl 参数执行 sysctl -p 生效备机一直显示 Catchup 或 Disconnected集群运行阶段主备网络拥塞、备机磁盘空间不足查看 pg_log 中的复制日志确认网络和磁盘余量端口被占用导致节点无法启动初始化阶段5432 已被其他进程占用或防火墙未放行执行ss -lntp检查端口放行防火墙规则gs_install提示权限拒绝读取 XML 阶段cluster_config.xml 属主不是 omm 或权限受限确认文件属主为 omm权限至少 644这类问题的共同点是报错信息往往并不直接指向根因。比如 SSH 互信没配好的时候[GAUSS-51400]后面还会跟一串远程执行失败的输出稍不注意就以为是数据库安装包的问题。遇到报错时先冷静下来从执行命令的用户身份、文件权限、网络连通性三个方向排查往往比陷在报错堆里更高效。5.2 日志定位与诊断工具的使用openGauss 的日志体系分两层。第一层是 OM 工具日志记录了集群安装、启动停止、状态切换等操作过程路径一般在 /var/log/omm 下文件名类似 om_installation.log、gs_om.log。安装和切换出问题时去这里找对应时间段的记录最直接。第二层是数据库运行日志在数据目录下的 pg_log 目录中按日期滚动里面记录了各实例的启动、复制、连接和错误信息。定位问题的顺序我是这样掌握的先执行gs_om -t status --detail看集群层面的状态至少能判断问题是出在主节点还是备节点然后到对应节点的 pg_log 里 grep 报错时间段的日志只有这一步找不到线索时才会去 OM 日志里翻安装或切换时的历史记录。直接从头开始读日志会非常耗时顺着时间点和报错关键词去 grep 效率高得多。gs_checkos 这个工具也值得特别注意它可以在安装前对系统环境做一轮预扫描gs_checkos -i A执行后会对 IP 地址、内核版本、磁盘空间、内存、内核参数、依赖库等多个项目进行检查结果分为 OK、Warning 和 Error 三档。建议在正式执行 gs_install 之前先跑一轮把 Error 项目全部处理掉再继续能避免很多中途失败的情况。我自己完整跑完这轮测试后的体会是openGauss 一主两备的安装本身并不复杂真正的难点全在安装之前的准备工作。互信、Python 版本、内核参数、依赖库、目录权限这些琐碎的东西只要有一项没到位报错就会绕得人非常头疼。真正部署时先花半小时把三台机器的环境整理一致再动手执行安装过程中多用 gs_om -t status 和 gs_ctl query 确认状态比自己埋头猜问题要高效得多。后续如果想让这套环境更接近生产水准可以继续研究 CM 组件的自动切换、独立数据盘上的归档配置以及一主两备在同步复制模式下的真实延迟指标这些都是这个测试环境可以直接扩展的方向。