Pacemaker 集群 CIB 版本機制深度解析：epoch/num_updates 遞增規則、分區合併策略與 RA 開發避坑指南

Pacemaker 集群 CIB 版本機制深度解析

Pacemaker 通過 admin_epoch, epoch, num_updates 三元組版本號管理 CIB 配置一致性。本文基於實測數據，詳細解析版本遞增規則、網絡分區下的合併行為、以及資源代理（RA）開發的關鍵注意點。

版本三元組含義

比較規則：元組字典序比較，admin_epoch > epoch > num_updates。節點加入時，版本最高者成為配置來源，覆蓋其他節點。

實測驗證環境

• 3 節點：srdsdevapp69/71/73，CentOS 6.3，Pacemaker 1.1.14，Corosync 1.4.1
• 初始版本：epoch=48304, num_updates=4, admin_epoch=2

關鍵行為實測

1. 配置變更觸發 epoch+1, num_updates 歸零

crm_attribute --type crm_config -s set1 --name foo1 -v "1"
# epoch: 48304 → 48305, num_updates: 4 → 0

2. 幂等更新不改變版本

重複設置相同值，版本號不變。

3. forever 節點屬性屬配置變更

crm_attribute -N hostname -l forever -n foo2 -v 2
# epoch +1

4. reboot 節點屬性屬狀態變更

crm_attribute -N hostname -l reboot -n foo3 -v 2
# num_updates +1

網絡分區合併實測

場景一：DC 在多數派分區

1. 隔離節點 69，形成兩分區（69 無 quorum；71/73 有 quorum，DC=73）
2. 少數派 69 執行 2 次配置更新 → epoch +2
3. 多數派 71 執行 1 次配置更新 → epoch +1
4. 恢復網絡 → 集群採用版本較高的少數派配置，多數派更新丟失

風險：未獲 quorum 分區的配置可能覆蓋有效配置。

場景二：DC 在少數派分區

1. 隔離 DC 節點 73，多數派 69/71 選出新 DC=71，epoch +1（DC 協商導致）
2. 恢復網絡 → 採用多數派配置（版本更高），DC 恢復為原 DC (73)

規律：DC 協商會導致 epoch +1；分區恢復傾向保留分區前 DC。

總結：Pacemaker 行為特徵

1. CIB 配置變更 → epoch +1
2. DC 協商 → epoch +1
3. 分區合併 → 採用版本號最高者的配置
4. 分區合併 → 傾向恢復原 DC

RA 開發避坑指南

1. 極力避免動態修改集群配置
2. 必須動態修改時，合併多參數為單一參數（如 MySQL RA 的 mysql_REPL_INFO）
3. 檢查 crm_attribute 返回碼並重試（參考 PostgreSQL RA 實現）
4. 失去 quorum 時的資源停止處理（demote/stop）嚴禁修改集群配置