GBase 8a 高可用机制详解：gcware 仲裁、副本一致性与故障切换

本文深入讲解 GBase 8a 集群的高可用底层逻辑，包括 gcware 的仲裁原理、多副本的一致性控制、节点故障时的自动切换流程，以及运维中常见的副本状态异常处理方法。

一、高可用三层架构

GBase 8a 的高可用能力由三个组件协同实现：

┌─────────────────────────────────────────────────────────┐
│  gcware（集群仲裁层）                                     │
│  - 基于 Corosync/Pacemaker                               │
│  - 奇数节点部署（3 或 5 个）                              │
│  - 负责节点心跳、脑裂防护、Leader 选举                    │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│  gcluster（协调层）                                       │
│  - 多节点部署，任意节点可对外提供服务                     │
│  - 元数据（表定义、分布信息）在各 gcluster 节点间同步     │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│  gnode（数据层）                                          │
│  - 每份数据有 1 主 + N 副本（取决于 distribution 配置）   │
│  - 主副本负责读写，副本同步主副本数据                     │
│  - gcware 仲裁主副本角色                                  │
└─────────────────────────────────────────────────────────┘

二、gcware：仲裁核心

gcware 是 GBase 8a 集群的"大脑"，基于 Corosync 实现节点间心跳和消息传递。它只负责仲裁，不存储用户数据。

2.1 奇数节点的必要性

gcware 使用多数派（Quorum）原则：只有超过半数节点存活，集群才能正常工作。

如果部署偶数个 gcware 节点（如 4 个），一旦发生网络分区，两边各 2 个节点都认为自己是多数派，产生"脑裂"，集群会拒绝服务保护数据一致性。因此 gcware 必须奇数部署。

2.2 V953 独立部署的变化

V952 及以前，gcware 必须与 gcluster 部署在同一节点。V953 开始，gcware 可以独立部署，这带来两个好处：

1. 可以用低配机器（轻量 VM）单独跑 gcware，不占用数据节点资源
2. gcluster 节点扩展不受 gcware 奇数限制约束

实际生产中，常见的部署模式：

gcware:    3 个节点（轻量 VM，各 4C/8G）
gcluster:  3~5 个节点（与 gnode 混部）
gnode:     N 个节点（根据数据量决定）

2.3 gcware 与 gnode 的交互

gnode 周期性向 gcware 上报自身状态（存活、数据版本号）。gcware 维护一张全局的副本状态表，记录每个 Segment 的主副本归属和版本号。

当某个 gnode 挂掉，gcware 感知到心跳超时后：

1. 将该节点标记为 DOWN
2. 在存活节点中选出数据版本号最新的副本晋升为新主
3. 通知 gcluster 更新路由表

三、数据副本机制

3.1 分片（Segment）与副本

建立 distribution 时通过以下命令指定副本数：

# p 2 表示 2 个主分片副本，d 1 表示 1 个从副本（即 1 主 1 从）
gcadmin distribution gcChangeInfo.xml p 2 d 1 pattern 1

查看分片分布：

gcadmin showdistribution node

输出示例：

Distribution ID: 1 | State: normal | Total segment num: 6

===========================================================
|  nodes   | 10.168.10.26 | 10.168.10.27 | 10.168.10.28 |
-----------------------------------------------------------
| primary  |      1       |      2       |      3       |
| segments |      4       |      5       |      6       |
-----------------------------------------------------------
|duplicate |      3       |      1       |      2       |
|segments 1|      5       |      6       |      4       |
===========================================================

上图中：

• 节点 26 存放 Segment 1（主）、4（主）、3（从）、5（从）
• 每个 Segment 的主副本和从副本分布在不同节点上
• 单个节点故障时，其主副本角色可由其他节点上的从副本接管

3.2 副本同步方式

GBase 8a 的主副本同步是异步复制：主副本写入完成后立即返回客户端，后台异步将变更推送给从副本。

这意味着在极端情况下（主节点刚写完数据就宕机），从副本可能短暂落后于主副本。gcware 通过比较各副本的**版本号（LSN）**来选出最新的从副本晋升为主。

3.3 查看副本一致性状态

-- 查看各 Segment 的主副本和状态
SELECT
    segment_id,
    node_name,
    is_primary,
    data_state,
    version
FROM gclusterdb.segment_info
ORDER BY segment_id, is_primary DESC;

data_state 字段含义：

四、节点故障切换流程

4.1 自动切换（正常故障）

当 gnode 宕机，自动切换流程如下：

1. gcware 检测到节点心跳超时（默认 5s）
2. gcware 仲裁：将该节点标记为 DOWN
3. gcware 从存活节点选取数据版本最新的从副本
4. 新主副本开始对外提供读写服务
5. gcluster 收到 gcware 通知，更新内部路由表
6. 后续 SQL 自动路由到新主副本，业务无感知

整个自动切换通常在 5~30 秒内完成（取决于心跳超时配置和副本追赶时间）。

4.2 主副本不一致时的处理

如果发生主副本与从副本数据不一致（如从副本落后较多），集群会进入降级状态。此时可通过参数控制处理策略：

# gcluster 的 gbase.cnf
# 0 = 不一致时报错拒绝服务（保守策略）
# 1 = 不一致时自动选主（可能丢失少量数据）
gcluster_suffix_consistency_resolve = 1

生产环境建议在充分评估数据丢失可接受程度后再配置此参数。

4.3 节点恢复后的数据同步

宕机节点重启后，会自动与当前主副本进行数据对齐（Resync）：

# 查看同步进度
gcadmin showdistribution node

# 如果同步状态长时间卡住，可强制触发
gcadmin resync node <node_name>

五、常见高可用故障排查

故障 1：gcware 无法启动，报 can not connect to any server

Could not initialize CRM instance error: [122]->[can not connect to any server]

原因：gcware 服务未启动，或 Corosync 通信端口（UDP 5405）被防火墙阻断。

排查步骤：

# 检查 gcware 进程
ps -ef | grep gcware

# 检查 Corosync 端口
netstat -tunlp | grep 5405

# 尝试手动启动 gcware
gcware_services all start

# 查看 gcware 日志
tail -200 $GCWARE_BASE/log/gcware.log

故障 2：某 gnode 状态 CLOSE，日志报内存超限

express total heap size exceeds memory limit!

原因：gnode 堆内存参数配置过低，超出系统内存限制。

处理：修改该节点的 gbase.cnf：

gbase_memory_pct_target = 0.75
gbase_heap_data         = 4096M
gbase_heap_temp         = 2048M
gbase_heap_large        = 4096M

重启该节点后验证：

gcluster_services all restart
gcadmin  # 确认节点状态变为 OPEN

故障 3：集群状态 INACTIVE，半数以上节点不可达

当超过半数 gcware 节点不可用时，集群进入 INACTIVE 状态，拒绝所有写操作（保护数据一致性）。

不要尝试强制写入，先恢复 gcware 节点到多数派状态，再逐节点检查 gnode 状态。

六、高可用运维建议

七、快速命令参考

# 查看集群整体状态
gcadmin

# 查看各节点分片分布和副本状态
gcadmin showdistribution node

# 手动启动 gcware（所有 gcware 节点执行）
gcware_services all start

# 手动启动 gcluster/gnode（所有节点执行）
gcluster_services all start

# 查看 gcware 日志
tail -f $GCWARE_BASE/log/gcware.log

# 查看 gcluster 日志
tail -f $GCLUSTER_BASE/log/gcluster/system.log

# 查看 gnode 日志
tail -f $GNODE_BASE/log/gbase/system.log