目录标题GaussDB Balanced 状态与重平衡完全指南目录一、什么是 Balanced 状态1.1 定义1.2 为什么要检查 Balanced 状态1.3 状态判断标准二、GaussDB 数据分布原理2.1 集群架构2.2 数据分片 (Sharding)2.3 副本机制 (Replication)三、为什么第一次创建就需要重平衡3.1 集群启动时的数据分布3.2 当前集群状态分析3.3 为什么不直接在所有节点创建分片四、重平衡的意义4.1 数据完整性和一致性4.2 负载均衡4.3 高可用性保障4.4 备份安全五、重平衡过程详解5.1 重平衡的 4 个阶段5.2 时间估算5.3 时间线总结六、如何监控平衡进度6.1 检查平衡状态6.2 检查数据分布6.3 检查数据同步状态6.4 查看集群日志6.5 检查命令速查表七、如何加速平衡过程7.1 问题描述7.2 解决方案使用 cm_ctl switchover 自动重平衡步骤 1诊断当前状态步骤 2查看当前主备状态步骤 3执行自动主备切换步骤 4验证平衡状态7.3 切换前后对比7.4 关键命令总结7.5 注意事项八、重平衡的触发场景8.1 首次创建当前情况8.2 节点故障恢复8.3 扩容8.4 缩容九、常见问题Q1: 一直显示 Unbalanced 怎么办Q2: 可以强制执行备份吗Q3: 如何加速平衡过程Q4: 平衡状态与集群健康的关系Q5: 平衡完成后如何执行备份十、官方参考资源10.1 GaussDB/openGauss 官方文档10.2 关键概念参考10.3 gs_roach 命令参考十一、快速参考11.1 状态检查流程图11.2 关键命令速查11.3 故障排查检查表附录当前集群详细信息集群配置当前状态平衡解决方案记录GaussDB Balanced 状态与重平衡完全指南目录一、什么是 Balanced 状态二、GaussDB 数据分布原理三、为什么第一次创建就需要重平衡四、重平衡的意义五、重平衡过程详解六、如何监控平衡进度七、如何加速平衡过程八、重平衡的触发场景九、常见问题一、什么是 Balanced 状态1.1 定义Balanced平衡状态是 GaussDB 集群的一个重要状态指标表示数据分片在各个节点间均匀分布各个数据节点的负载基本均衡集群可以进行安全的数据操作备份、扩容等1.2 为什么要检查 Balanced 状态┌─────────────────────────────────────────────────────────────┐ │ Unbalanced 状态下禁止的操作 │ ├─────────────────────────────────────────────────────────────┤ │ ❌ 全量备份 (Full Backup) │ │ ❌ 增量备份 (Incremental Backup) │ │ ❌ 数据重分布 (Redistribution) │ │ ❌ 节点扩容 (Scale-out) │ └─────────────────────────────────────────────────────────────┘原因在数据不平衡状态下执行备份可能导致备份数据不完整恢复时数据不一致某些节点的数据遗漏1.3 状态判断标准balancedclusterStatus备份操作说明NoNormal❌ 禁止数据平衡中NoAbnormal❌ 禁止集群异常YesNormal✅ 允许正常状态YesAbnormal⚠️ 谨慎需检查重要Normal状态不等于Balanced状态二、GaussDB 数据分布原理2.1 集群架构┌─────────────────────────────────────────────────────────────────────────┐ │ GaussDB 集群架构 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ GTM 层 (全局事务管理) │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ gtm-0-0 │ │ gtm-1-0 │ │ gtm-2-0 │ │ │ │ zone1:10 │ │ zone1:10 │ │ zone2:4 │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ ↓ ↓ ↓ │ │ CN 层 (协调节点) │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ cn-0-0 │ │ cn-1-0 │ │ cn-2-0 │ │ │ │ zone1:10 │ │ zone1:10 │ │ zone2:4 │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ ↓ ↓ ↓ │ │ DN 层 (数据节点) │ │ ┌────────────┐ ┌────────────┐ │ │ │ dn0 组 │ │ dn1 组 │ │ │ ├────────────┤ ├────────────┤ │ │ │ dn0-0-0 ✓ │ │ dn1-0-0 ✓ │ ← shardInitial: true (主分片) │ │ │ dn0-1-0 │ │ dn1-1-0 │ │ │ │ dn0-2-0 │ │ dn1-2-0 │ │ │ └────────────┘ └────────────┘ │ │ │ │ 物理节点分布: │ │ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ │ │ xx-xx-xx-25 │ │ xx-xx-xx-26 │ │ xx-xx-xx-27 │ │ │ │ cm-1, dn0-1, │ │ cm-0, cn-0,1, │ │ cm-2, cn-2, │ │ │ │ dn1-0, gtm-0 │ │ dn0-0,2, dn1-1, │ │ dn0-2, dn1-2, │ │ │ │ │ │ gtm-1 │ │ gtm-2 │ │ │ │ Zone1 (优先10) │ │ Zone1 (优先10) │ │ Zone2 (优先4) │ │ │ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘2.2 数据分片 (Sharding)GaussDB 将表数据切分成多个分片每个分片存储在不同的节点上示例表orders (订单表) ┌───────────────────────────────────────────────────────────┐ │ orders 表数据分布 │ ├───────────────────────────────────────────────────────────┤ │ │ │ Shard 0: 订单 ID 1-10000 → dn0-0-0 (主) │ │ ↓ 复制 → dn0-1-0 (备) │ │ ↓ 复制 → dn0-2-0 (备) │ │ │ │ Shard 1: 订单 ID 10001-20000 → dn1-0-0 (主) │ │ ↓ 复制 → dn1-1-0 (备) │ │ ↓ 复制 → dn1-2-0 (备) │ │ │ └───────────────────────────────────────────────────────────┘2.3 副本机制 (Replication)每个分片有 3 个副本默认分布在不同节点上Primary: 主副本处理读写Standby 1: 备份副本 1Standby 2: 备份副本 2目的高可用性单个节点故障不影响服务负载均衡查询可以分发到不同副本数据安全多副本防止数据丢失三、为什么第一次创建就需要重平衡3.1 集群启动时的数据分布┌─────────────────────────────────────────────────────────────────────────┐ │ GaussDB 集群启动过程 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 步骤 1: 创建数据分组 (dn0, dn1) │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ dn0 组 │ │ dn1 组 │ │ │ │ 3个副本节点 │ │ 3个副本节点 │ │ │ └──────────────┘ └──────────────┘ │ │ │ │ 步骤 2: 初始分片 (shardInitial) │ │ 只在 1 个节点上创建主分片然后复制到其他节点 │ │ │ │ dn0 组: │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ dn0-0-0 ✓ │ │ dn0-1-0 │ │ dn0-2-0 │ │ │ │ shardInit:true│ ←复制 ← shardInit:false ←复制 ← │ │ │ │ 有主分片 │ │ 无主分片 │ │ 无主分片 │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ dn1 组: │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ dn1-0-0 ✓ │ │ dn1-1-0 │ │ dn1-2-0 │ │ │ │ shardInit:true│ ←复制 ← shardInit:false ←复制 ← │ │ │ │ 有主分片 │ │ 无主分片 │ │ 无主分片 │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ⚠️ 问题: 只有 2/6 节点有主分片其他 4/6 节点是空的 │ │ │ └─────────────────────────────────────────────────────────────────────────┘3.2 当前集群状态分析clusterStatus:Normalbalanced:No# ← 当前处于不平衡状态# 数据分片初始化状态shardInitial 节点:2 个-dn0-0-0 (zone1)-dn1-0-0 (zone1)# 副本节点: 4 个-dn0-1-0,dn0-2-0-dn1-1-0,dn1-2-0状态解读只有 2 个 DN 节点完成了初始分片 (shardInitial: true)其他 4 个 DN 节点还在等待数据同步Zone 优先级不一致 (zone1:10, zone2:4)3.3 为什么不直接在所有节点创建分片原因说明避免冲突串行创建比并发创建更安全避免主分片冲突可控性可以精确控制数据复制过程出现问题容易恢复一致性通过复制和验证机制确保所有节点数据一致效率先在主节点创建再并行复制到副本节点如果同时在多个节点创建分片的后果 dn0-0-0: 创建 Shard 0 dn0-1-0: 也创建 Shard 0 ← 冲突 结果数据不一致主分片冲突无法确定哪个是真正的数据源四、重平衡的意义4.1 数据完整性和一致性┌─────────────────────────────────────────────────────────────┐ │ 重平衡前的数据分布不完整 │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0: ████████████ (Shard 0 主分片) │ │ dn0-1-0: ░░░░░░░░░░░░ (空) │ │ dn0-2-0: ░░░░░░░░░░░░ (空) │ │ │ │ 如果此时备份 │ │ ❌ 只备份到 dn0-0-0 的数据 │ │ ❌ dn0-1-0, dn0-2-0 没有数据备份不完整 │ │ ❌ 恢复时数据丢失 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 重平衡后的数据分布完整 │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0: ████████████ (Shard 0 主分片) │ │ dn0-1-0: ████████████ (Shard 0 副本) ✓ │ │ dn0-2-0: ████████████ (Shard 0 副本) ✓ │ │ │ │ 此时备份 │ │ ✅ 每个节点都有完整数据 │ │ ✅ 任意节点都可以用于恢复 │ │ ✅ 数据冗余保护 │ └─────────────────────────────────────────────────────────────┘4.2 负载均衡┌─────────────────────────────────────────────────────────────┐ │ 重平衡前的负载分布 │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0: ████████████ 100% 负载 ← 过载 │ │ dn0-1-0: ░░░░░░░░░░░░ 0% 负载 ← 空闲 │ │ dn0-2-0: ░░░░░░░░░░░░ 0% 负载 ← 空闲 │ │ │ │ 问题 │ │ - dn0-0-0 承担所有查询 │ │ - dn0-1-0, dn0-2-0 浪费资源 │ │ - 无法利用分布式并行能力 │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 重平衡后的负载分布 │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0: ████████████ 33% 负载 ← 正常 │ │ dn0-1-0: ████████████ 33% 负载 ← 正常 │ │ dn0-2-0: ████████████ 33% 负载 ← 正常 │ │ │ │ 优势 │ │ - 查询可以分发到不同节点 │ │ - 充分利用硬件资源 │ │ - 提升并发性能 │ └─────────────────────────────────────────────────────────────┘4.3 高可用性保障节点故障时的数据保护 ┌─────────────────────────────────────────────────────────────┐ │ 重平衡完成 (3副本保护) │ ├─────────────────────────────────────────────────────────────┤ │ 正常状态: │ │ dn0-0-0: ✓ (主) dn0-1-0: ✓ (备) dn0-2-0: ✓ (备) │ │ │ │ dn0-0-0 故障: │ │ dn0-0-0: ✗ (故障) dn0-1-0: ✓ (提升为主) dn0-2-0: ✓ (备) │ │ → 服务不中断数据不丢失 │ │ │ │ 如果没有重平衡 (只有1副本): │ │ dn0-0-0: ✓ (唯一数据) dn0-1-0: 空 dn0-2-0: 空 │ │ dn0-0-0 故障: │ │ dn0-0-0: ✗ (故障) dn0-1-0: 空 dn0-2-0: 空 │ │ → 数据丢失服务中断 │ └─────────────────────────────────────────────────────────────┘4.4 备份安全┌─────────────────────────────────────────────────────────────┐ │ 重平衡状态与备份安全 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ Unbalanced (重平衡前): │ │ - 只有主节点有完整数据 │ │ - 备份节点 → 数据不完整 │ │ - 恢复时缺少副本数据 │ │ - ❌ 禁止备份 │ │ │ │ Balanced (重平衡后): │ │ - 所有节点都有完整副本 │ │ - 备份任意节点 → 数据完整 │ │ - 恢复时数据一致 │ │ - ✅ 允许备份 │ │ │ └─────────────────────────────────────────────────────────────┘五、重平衡过程详解5.1 重平衡的 4 个阶段┌─────────────────────────────────────────────────────────────┐ │ 阶段 1: 主分片创建 (shardInitial) │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0: 创建 Shard 0 主分片 │ │ dn1-0-0: 创建 Shard 1 主分片 │ │ │ │ 状态: 2/6 节点有数据 │ │ balanced: No │ └─────────────────────────────────────────────────────────────┘ ↓ 数据复制 ┌─────────────────────────────────────────────────────────────┐ │ 阶段 2: 数据同步 (Data Replication) │ ├─────────────────────────────────────────────────────────────┤ │ dn0-0-0 → dn0-1-0: 同步 Shard 0 │ │ dn0-0-0 → dn0-2-0: 同步 Shard 0 │ │ dn1-0-0 → dn1-1-0: 同步 Shard 1 │ │ dn1-0-0 → dn1-2-0: 同步 Shard 1 │ │ │ │ 状态: 所有节点都有数据副本 │ │ balanced: No (还需要一致性检查) │ └─────────────────────────────────────────────────────────────┘ ↓ 一致性校验 ┌─────────────────────────────────────────────────────────────┐ │ 阶段 3: 一致性验证 (Consistency Check) │ ├─────────────────────────────────────────────────────────────┤ │ - 检查所有节点的数据一致性 │ │ - 验证副本同步状态 │ │ - 确认没有数据丢失或损坏 │ │ │ │ 状态: 数据一致 │ │ balanced: No (还需要负载均衡) │ └─────────────────────────────────────────────────────────────┘ ↓ 负载均衡 ┌─────────────────────────────────────────────────────────────┐ │ 阶段 4: 负载均衡 (Load Balancing) │ ├─────────────────────────────────────────────────────────────┤ │ - 调整分片分布确保各节点负载均衡 │ │ - 更新路由表优化查询路径 │ │ - 验证所有功能正常 │ │ │ │ 状态: 数据分布均衡 │ │ balanced: Yes ← 可以备份了 │ └─────────────────────────────────────────────────────────────┘5.2 时间估算阶段空集群有数据说明主分片创建5-10 分钟5-10 分钟只在 2 个节点创建数据同步20-40 分钟取决于数据量复制到 4 个节点一致性验证5-10 分钟取决于数据量校验所有副本负载均衡5-10 分钟5-10 分钟调整路由表总计30-60 分钟更长空集群首次启动5.3 时间线总结┌─────────────────────────────────────────────────────────────┐ │ GaussDB 首次启动平衡时间线 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ T0 集群开始创建 │ │ T10min 所有 Pod Running │ │ T15min CN/DN 节点启动完成 │ │ T20min clusterStatus: Normal, balanced: No │ │ T35min 2/6 DN 完成初始分片 (当前状态) │ │ T60min 数据同步进行中 │ │ T90min balanced: Yes ← 可以备份了! │ │ │ └─────────────────────────────────────────────────────────────┘当前进度T35min还需 30-60 分钟六、如何监控平衡进度6.1 检查平衡状态# 方法1: 查看集群平衡状态exportKUBECONFIG/tmp/27-admin.conf ka get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.balanced}# 输出: Yes 或 No# 方法2: 查看完整状态ka get gaussdbcluster gaussdb-8204596d -o yaml|grep-A5balanced# 方法3: 持续监控每30秒检查一次watch-n30ka get gaussdbcluster gaussdb-8204596d -o jsonpath{.status.balanced}6.2 检查数据分布# 进入 CN 节点查看分片分布kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT * FROM pgxc_node;# 查看表分布kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT node_name, nodeis_preferred FROM pgxc_node;6.3 检查数据同步状态# 查看数据同步进度kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT * FROM pg_stat_replication;# 查看复制槽状态kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT * FROM pg_replication_slots;6.4 查看集群日志# CM 节点日志集群管理ka logs gaussdb-8204596d-cm-0-0 --tail100|grep-i balance# CN 节点日志ka logs gaussdb-8204596d-cn-0-0 --tail100|grep-i balance# DN 节点日志ka logs gaussdb-8204596d-dn0-0-0 --tail100|grep-idata\|replicat6.5 检查命令速查表# 状态检查 ka get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.balanced}ka get gaussdbcluster gaussdb-8204596d -o yaml|grep-EclusterStatus|balanced# 节点状态 ka get pods -lAppNamegaussdb-8204596d# 数据库连接测试 kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT version();# 日志查看 ka logs gaussdb-8204596d-cm-0-0 --tail50ka logs gaussdb-8204596d-cn-0-0 --tail50七、如何加速平衡过程7.1 问题描述在某些情况下GaussDB 集群可能长时间处于balanced: No状态即使所有节点都正常运行。这通常是由于以下原因┌─────────────────────────────────────────────────────────────────────────┐ │ 主备节点分布不匹配问题 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ dn0 组: │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ dn0-0-0 │ │ dn0-1-0 │ │ dn0-2-0 │ │ │ │ shardInit:✓ │ │ shardInit:✗ │ │ shardInit:✗ │ │ │ │ Standby │ │ Primary ❌ │ │ Standby │ │ │ │ │ │ (非初始分片) │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ dn1 组: │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ dn1-0-0 │ │ dn1-1-0 │ │ dn1-2-0 │ │ │ │ shardInit:✓ │ │ shardInit:✗ │ │ shardInit:✗ │ │ │ │ Standby │ │ Primary ❌ │ │ Standby │ │ │ │ │ │ (非初始分片) │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ 问题: 主节点Primary不是初始分片节点shardInitialtrue │ │ 结果: 集群判断为未平衡状态 → balanced: No │ │ │ └─────────────────────────────────────────────────────────────────────────┘7.2 解决方案使用 cm_ctl switchover 自动重平衡GaussDB 提供了cm_ctl switchover -a命令来自动切换主备节点实现集群重平衡。步骤 1诊断当前状态# 检查 balanced 状态exportKUBECONFIG/tmp/27-admin.conf ka get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.balanced}# 输出: No# 检查 DN 节点的 shardInitial 状态ka get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.components}|\jq -rto_entries[] | select(.key | contains(dn)) | \(.key): shardInitial\(.value.shardInitial)输出示例gaussdb-8204596d-dn0-0-0: shardInitialtrue gaussdb-8204596d-dn0-1-0: shardInitialfalse ← 当前是 Primary gaussdb-8204596d-dn0-2-0: shardInitialfalse gaussdb-8204596d-dn1-0-0: shardInitialtrue gaussdb-8204596d-dn1-1-0: shardInitialfalse ← 当前是 Primary gaussdb-8204596d-dn1-2-0: shardInitialfalse步骤 2查看当前主备状态# 进入 CM 节点查看详细状态kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query -Cv2/dev/null|grep-Edn0|dn1输出示例4 gaussdb-8204596d-dn0-0-0 6001 P Standby Normal | 5 gaussdb-8204596d-dn0-1-0 6002 S Primary Normal | 6 gaussdb-8204596d-dn0-2-0 6003 S Standby Normal 7 gaussdb-8204596d-dn1-0-0 6004 P Standby Normal | 8 gaussdb-8204596d-dn1-1-0 6005 S Primary Normal | 9 gaussdb-8204596d-dn1-2-0 6006 S Standby Normal步骤 3执行自动主备切换# 执行自动切换CM 会自动识别需要重平衡的节点并进行切换kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl switchover -a2/dev/null输出示例cm_ctl: cmserver is rebalancing the cluster automatically. ..... cm_ctl: switchover successfully.步骤 4验证平衡状态# 等待 10 秒后检查状态sleep10kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query2/dev/null|grep-Ecluster_state|balanced输出示例cluster_state : Normal balanced : Yes ← 平衡成功再次查看主备状态4 gaussdb-8204596d-dn0-0-0 6001 P Primary Normal | 5 gaussdb-8204596d-dn0-1-0 6002 S Standby Normal | 6 gaussdb-8204596d-dn0-2-0 6003 S Standby Normal 7 gaussdb-8204596d-dn1-0-0 6004 P Primary Normal | 8 gaussdb-8204596d-dn1-1-0 6005 S Standby Normal | 9 gaussdb-8204596d-dn1-2-0 6006 S Standby Normal7.3 切换前后对比┌─────────────────────────────────────────────────────────────────────────┐ │ 切换前 vs 切换后 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 切换前 (balanced: No): │ │ dn0-0-0: shardInitialtrue Standby ❌ │ │ dn0-1-0: shardInitialfalse Primary ← 主节点不是初始分片 │ │ │ │ 切换后 (balanced: Yes): │ │ dn0-0-0: shardInitialtrue Primary ✅ ← 初始分片节点成为主节点 │ │ dn0-1-0: shardInitialfalse Standby │ │ │ └─────────────────────────────────────────────────────────────────────────┘7.4 关键命令总结命令作用cm_ctl query查看集群状态含 balancedcm_ctl query -v查看详细节点状态cm_ctl query -Cv按主备关系查看状态cm_ctl switchover -a自动切换以重平衡集群cm_ctl switchover -s查看哪些节点需要切换7.5 注意事项业务影响主备切换期间会有短暂的服务中断通常几秒到十几秒执行时机建议在业务低峰期执行先决条件所有节点状态必须为NormalStandby 节点的数据必须已同步网络连接正常失败处理# 如果切换失败查看详细错误kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query -v2/dev/null|grep-A5dn0-1-0八、重平衡的触发场景8.1 首次创建当前情况场景集群刚创建 原因只在部分节点创建了主分片 过程主分片 → 副本同步 → 一致性验证 → 负载均衡 时间30-60 分钟8.2 节点故障恢复场景某个节点故障后恢复 原因该节点的数据落后了 过程从主节点同步缺失的数据 时间取决于数据量8.3 扩容场景添加新的 DN 节点 原因新节点没有数据 过程将部分分片迁移到新节点 时间取决于迁移的数据量8.4 缩容场景移除某个 DN 节点 原因需要将该节点的数据迁移到其他节点 过程数据迁移 → 更新路由 时间取决于迁移的数据量九、常见问题Q1: 一直显示 Unbalanced 怎么办检查步骤# 1. 检查所有节点是否正常运行ka get pods -lAppNamegaussdb-8204596d# 2. 检查集群状态ka get gaussdbcluster gaussdb-8204596d -o yaml|grep-EclusterStatus|balanced# 3. 查看是否有节点报错ka describe pod gaussdb-8204596d-dn0-0-0# 4. 查看集群事件ka get events --sort-by.lastTimestamp|grepgaussdb可能原因集群刚启动还在平衡中正常某个节点数据同步失败异常网络问题导致同步中断异常Q2: 可以强制执行备份吗不建议强制执行备份可能导致数据不一致备份文件损坏恢复时失败正确做法等待 Balanced 状态后再执行备份。Q3: 如何加速平衡过程快速解决方法如果集群长时间处于balanced: No状态超过 2 小时可以使用主备切换来加速平衡。详细步骤请参考七、如何加速平衡过程快速命令# 1. 检查当前状态kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query2/dev/null|grepbalanced# 2. 执行自动切换kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl switchover -a2/dev/null# 3. 等待 10 秒后验证sleep10kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query2/dev/null|grepbalanced预期结果balanced: Yes其他注意事项确保网络稳定检查数据量大小确保所有节点状态为 NormalQ4: 平衡状态与集群健康的关系clusterStatus: Normal → 集群功能正常 balanced: Yes → 数据分布均衡可备份 balanced: No → 数据分布中不可备份重要Normal状态不等于Balanced状态Q5: 平衡完成后如何执行备份# 1. 确认 balanced: Yeska get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.balanced}# 输出: Yes# 2. 触发备份ka annotate backup gaussdb-8204596d-backup job/full# 3. 监控备份进度ka get pods -lAppNamegaussdb-8204596d|grepbackup ka logs -fbackup_pod_name十、官方参考资源10.1 GaussDB/openGauss 官方文档GaussDB 官方文档: https://support.huaweicloud.com/opengauss/openGauss 官方文档: https://opengauss.org/zh/docs/GaussDB 备份恢复指南: https://support.huaweicloud.com/opengauss/docs/3.0.0/tool-gs-roach.htmlgs_roach 工具说明: https://opengauss.org/zh/docs/3.0.0/tool-gs-roach.html10.2 关键概念参考概念官方文档链接数据分布与分片https://opengauss.org/zh/docs/3.0.0/concepts/concepts.html高可用性机制https://opengauss.org/zh/docs/3.0.0/concepts/ha.html备份恢复https://opengauss.org/zh/docs/3.0.0/tool-gs-roach.html集群管理https://opengauss.org/zh/docs/3.0.0/maintain/cluster-manual.html10.3 gs_roach 命令参考# gs_roach 是 GaussDB/openGauss 的备份恢复工具# 官方文档: https://opengauss.org/zh/docs/3.0.0/tool-gs-roach.html# 查看帮助GaussRoach.py --help# 查看备份相关参数GaussRoach.py -t backup --help十一、快速参考11.1 状态检查流程图开始 ↓ 查看 balanced 状态 ↓ ┌─────────┐ │ balanced │ └────┬────┘ ↓ No │ Yes ↓ │ │ 等待/检查 可以执行 │ │ 查看日志 备份、扩容 │ │ └─────┘ └─────┘11.2 关键命令速查# 检查平衡状态 ka get gaussdbcluster gaussdb-8204596d -ojsonpath{.status.balanced}# 查看集群完整状态 ka get gaussdbcluster gaussdb-8204596d -o yaml|grep-EclusterStatus|balanced|shardInitial# 查看节点状态 ka get pods -lAppNamegaussdb-8204596d# 测试数据库连接 kaexecgaussdb-8204596d-cn-0-0 -n qfusion-admin --\su- omm -cgsql -d postgres -p 42050 -c SELECT version();# 触发备份仅在 balanced: Yes 时 ka annotate backup gaussdb-8204596d-backup job/full# 持续监控 watch-n30ka get gaussdbcluster gaussdb-8204596d -o jsonpath{.status.balanced}11.3 故障排查检查表现象可能原因解决方法balanced: No 超过2小时网络问题检查节点间连通性balanced: No 某个节点一直不启动节点故障查看节点日志重启 Pod备份失败并提示 “not balanced”正常情况等待 balanced: Yes集群状态 Abnormal集群异常查看集群日志和事件附录当前集群详细信息集群配置集群名称:gaussdb-8204596d命名空间:qfusion-admin存储类型:NAS节点分布:-3 个 CM 节点 (Coordinator Manager)-3 个 CN 节点 (Coordinator)-6 个 DN 节点 (Data Node)分 2 组-3 个 GTM 节点 (Global Transaction Manager)数据分组:-dn0 组:3 个副本 (dn0-0-0,dn0-1-0,dn0-2-0)-dn1 组:3 个副本 (dn1-0-0,dn1-1-0,dn1-2-0)分片初始化状态:-dn0-0-0:shardInitial:true (主分片)-dn1-0-0:shardInitial:true (主分片)-其他 4 个节点:shardInitial:false (等待同步)Zone 分布:-zone1 (优先级 10):大部分节点-zone2 (优先级 4):少部分节点当前状态clusterStatus: Normal balanced: Yes ✅ 状态更新: 已通过主备切换完成平衡 切换方法: cm_ctl switchover -a 切换时间: 2026-02-04平衡解决方案记录问题诊断主节点dn0-1-0, dn1-1-0的 shardInitial 为 false初始分片节点dn0-0-0, dn1-0-0处于 Standby 状态导致集群判断为未平衡状态解决步骤# 1. 查看当前状态kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query -Cv# 2. 执行自动切换kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl switchover -a# 3. 验证结果kaexecgaussdb-8204596d-cm-0-0 -n qfusion-admin --\su- omm -ccm_ctl query切换结果切换前: dn0-0-0: Standby (shardInitialtrue) dn0-1-0: Primary (shardInitialfalse) 切换后: dn0-0-0: Primary (shardInitialtrue) ✅ dn0-1-0: Standby (shardInitialfalse)文档更新时间: 2026-02-04集群: gaussdb-8204596d当前状态: Normal, Balanced ✅解决方案: 使用 cm_ctl switchover -a 自动主备切换