主集群执行gs_sdr -t start -m primary后,在主集群主节点检查集群状态,在备集群主节点执行gs_sdr -t start -m disaster_standby是,一直在staring the cluster集群等待,日志中也没看到明显报错
可以先排查一下搭建步骤有没有问题
- 先搭建两个主备的集群:
- 两个集群创建相同的复制用户,密码保持一致。
gsql -d postgres -p 12300 -c “create user sdru1 with replication password ‘opengauss@123’;” - 主集群执行 gs_sdr -t start -m primary -X /opt/pkg/sdr1.xml --time-out=1200 -U ‘sdru1’ -W ‘opengauss@123’
- 同时也在灾备执行 gs_sdr -t start -m disaster_standby -X /opt/pkg/sdr2.xml --time-out=1200 -U ‘sdru1’ -W ‘opengauss@123’
答案内容由AI生成,仅供参考:
openGauss 主备集群容灾搭建问题分析与解决方案
针对用户在搭建 openGauss 主备集群容灾时遇到的问题——主集群执行 gs_sdr -t start -m primary 后,在备集群执行 gs_sdr -t start -m disaster_standby 时卡在 “starting the cluster” 状态且日志无明显报错——以下是基于所提供信息的全面分析和解决建议。
问题诊断
当前状态分析
根据提供的 gs_sdr -t query 查询结果:
{
'hadr_cluster_stat': 'full_backup',
'hadr_failover_stat': '',
'hadr_switchover_stat': '',
'RPO': '',
'RTO': ''
}
hadr_cluster_stat: 'full_backup'表明当前集群处于“全量备份”状态。RPO和RTO为空,说明尚未建立有效的流式复制链路,无法计算恢复点目标和恢复时间目标。- 此状态可能表示备集群尚未完成初始化同步或配置不一致导致无法正常启动。
常见原因分析
-
主备集群未正确配置
主集群与灾备集群之间需保持复制用户、密码、XML 配置文件的一致性和正确性。 -
配置文件路径或参数错误
若未显式指定 XML 配置文件(如-X /opt/pkg/sdr1.xml),可能导致命令使用默认配置,与预期不符。 -
网络连接或权限问题
主备节点之间若存在防火墙、SSH 访问限制或主机名解析问题,会导致数据同步失败。 -
复制用户权限不足
用于流复制的数据库用户必须具有REPLICATION权限,并设置正确的密码认证方式。 -
灾备集群未处于可启动的准备状态
在执行gs_sdr -t start -m disaster_standby前,必须确保灾备集群已完成初始化并处于等待接入状态。
正确的主备集群容灾搭建步骤(参考专家建议)
此方案由用户 zhangxubo 提供并验证有效:
1. 搭建两个独立的主备集群
确保主集群和灾备集群各自完成部署并运行正常。
2. 创建统一的复制用户
在两个集群中创建相同的复制用户,密码保持一致:
gsql -d postgres -p 12300 -c "create user sdru1 with replication password 'opengauss@123';"
3. 启动主集群为 Primary 模式
在主集群主节点执行:
gs_sdr -t start -m primary -X /opt/pkg/sdr1.xml --time-out=1200 -U 'sdru1' -W 'opengauss@123'
-X /opt/pkg/sdr1.xml:指定主集群的灾备配置文件。-U/-W:指定拥有复制权限的用户名和密码。
4. 启动灾备集群为 Disaster Standby 模式
在灾备集群主节点并发执行:
gs_sdr -t start -m disaster_standby -X /opt/pkg/sdr2.xml --time-out=1200 -U 'sdru1' -W 'opengauss@123'
注意:
sdr2.xml是灾备集群的配置文件,需正确定义主集群地址等参数。- 主备两端应同时或快速连续启动,避免超时中断。
故障排查建议
1. 检查配置文件一致性
确认以下内容一致:
- 复制用户名和密码
- 端口、IP 地址配置
sdr1.xml与sdr2.xml中的互连信息准确无误
2. 检查网络与主机名解析
- 确保主备节点能通过主机名互相访问。
- 检查
/etc/hosts是否配置正确。 - 检查防火墙是否开放所需端口(如数据库端口、CM 端口等)。
3. 使用 gs_om 检查集群状态
在各节点运行以下命令查看集群运行状况:
gs_om -t status --detail
确认所有节点状态为 Normal 或 Primary/Standby,没有 Down 或 Unknown。
4. 查看日志文件定位潜在错误
尽管终端未提示明显错误,但仍应检查日志文件:
# 日志路径通常为:
$GAUSSLOG/pg_log/
# 或
/data/opengauss/data/dn/pg_log/
重点关注是否有以下关键词:
FATALreplication connection failedauthentication failedcould not connect to primary
其他相关概念补充
| 概念 | 说明 |
|---|---|
gs_sdr 工具 |
openGauss 提供的流式灾难恢复管理工具,用于配置和管理主备集群间的数据同步。 |
| RPO=0(零数据丢失) | 通过黑匣子(Blackbox)技术可实现异地容灾零数据丢失,关键业务推荐启用。 |
| Multi-Cluster Deployment | 支持“两地三中心”架构,提升系统高可用性与容灾能力。 |
总结与建议
| 项目 | 建议 |
|---|---|
| 配置同步 | 主备集群必须使用相同的复制用户和密码。 |
| 命令完整调用 | 务必带上 -X 指定配置文件,否则可能使用默认配置导致失败。 |
| 启动顺序 | 主备两端应快速连续执行启动命令,建议并发操作。 |
| 状态监控 | 使用 gs_sdr -t query 定期检查 hadr_cluster_stat 是否变为 normal。 |
| 专家支持 | 本方案已由 zhangxubo 用户提供并被标记为“解决方案”,具备实际参考价值。 |
最终目标状态:
gs_sdr -t query应返回:{'hadr_cluster_stat': 'normal', 'RPO': '0', ...}
若按上述步骤操作仍无法解决,请导出 $GAUSSLOG/pg_log/ 下的日志进行深入分析。
