详细介绍 OceanBase 中的 Config Log 机制

详细介绍 OceanBase 中的 Config Log 机制。

---

## Config Log 详解

### 一、基本概念

**Config Log（配置日志）** 是 OceanBase 数据库中一种特殊类型的日志条目，用于记录和同步 Paxos Group 的成员配置变更信息。与普通的数据操作日志（Redo Log）不同，Config Log 承载的是"元数据"的变更——即集群拓扑结构、副本分布、Leader 位置等系统级状态的变化。它是实现 Joint Consensus 成员变更、动态扩缩容、故障自动恢复等核心能力的基础机制。

在 OceanBase 的日志体系（Clog）中，Config Log 与事务日志（Trans Log）共同构成了完整的日志流。Config Log 虽然不直接记录业务数据的增删改，但它决定了数据在哪些节点上存储、如何复制、以及故障时如何切换，是整个分布式系统的"神经中枢"。

---

### 二、设计背景与必要性

#### 1. 为什么需要独立的 Config Log

在分布式数据库中，成员配置（Membership）本质上是一种需要持久化和复制的状态。如果仅将配置保存在内存或独立存储中，会面临严重问题：

- **一致性断层**：配置变更与数据变更不同步，可能导致"配置已改但数据未复制"或相反的情况
- **崩溃恢复难题**：节点重启后无法确定自己属于哪个 Paxos Group，无法参与选举和复制
- **脑裂风险**：不同节点对当前配置的认知不一致，可能形成多个独立集群

将配置变更日志化（Log-structured），使其遵循与数据相同的 Paxos 复制协议，是解决上述问题的根本方案。

#### 2. 与普通日志的本质区别

| 特性 | Config Log | 普通 Trans Log |
|------|------------|----------------|
| 内容 | 成员配置、Leader 任期、Zone 信息 | 事务的 Redo/Undo 记录 |
| 消费方式 | 所有副本必须应用以更新本地配置 | 仅 Follower 重放以同步数据 |
| 持久化要求 | 必须在数据日志之前落盘 | 按事务提交顺序刷盘 |
| 清理策略 | 长期保留，用于故障诊断 | 定期合并、压缩、回收 |

---

### 三、核心结构与类型

Config Log 在物理存储上与普通日志条目格式统一，但通过特定的日志类型标识符（Log Type）区分。主要包含以下几类：

#### 1. 成员配置日志（Membership Log）

记录 Paxos Group 的副本组成变化：

```cpp
// 简化示意
struct MembershipLog {
LogType type = MEMBERSHIP_CHANGE;
int64_t config_version; // 配置版本号，单调递增
ObMemberList old_members; // 旧成员列表
ObMemberList new_members; // 新成员列表
int64_t replica_num; // 副本数
common::ObRegion region; // 地域信息
};
```

这是 Joint Consensus 的核心载体，包含从 $C_{old}$ 到 $C_{new}$ 的完整转换信息。

#### 2. Leader 活跃日志（Active Info Log）

记录 Leader 的任期和活性信息：

```cpp
struct ActiveInfoLog {
LogType type = LEADER_ACTIVE;
int64_t proposal_id; // Leader 提案编号（Paxos 术语）
int64_t lease_start_time; // 租约开始时间
int64_t lease_end_time; // 租约过期时间
ObAddr leader_addr; // Leader 地址
};
```

用于防止旧 Leader 在网络分区后"假死"继续服务，是实现 Leader 租约（Lease）机制的基础。

#### 3. 元数据配置日志（Meta Config Log）

记录分区级别的元数据变更：

- 分区的创建、删除、合并
- 存储引擎参数调整（如合并阈值、压缩算法）
- 副本类型变更（全功能副本 ↔ 日志副本 ↔ 只读副本）

---

### 四、生命周期与状态机

Config Log 的生命周期紧密跟随 Paxos Group 的状态演进，构成一个严格的**配置状态机（Configuration State Machine）**。

#### 1. 生成阶段

Config Log 的生成触发点包括：

- **管理员命令**：`ALTER SYSTEM ADD/REMOVE/MIGRATE REPLICA`
- **自动故障检测**：RootService 发现节点故障，触发副本重建
- **负载均衡调度**：自动扩容/缩容、Leader 重新分布
- **定时活性刷新**：Leader 定期刷新租约信息

生成后，Config Log 被写入 Log Buffer，与普通事务日志一起批量刷盘，确保持久化。

#### 2. 复制阶段

Config Log 遵循标准 Paxos 复制流程：

1. **Leader 提议**：Leader 将 Config Log 作为提案（Proposal）发送给所有副本
2. **Follower 接受**：Follower 收到后持久化到本地 Clog，返回确认（ACK）
3. **多数派达成**：Leader 统计确认数量，满足联合多数派（Joint Consensus）或普通多数派条件后，标记为已提交（Committed）
4. **广播提交**：Leader 向所有副本广播提交消息，Config Log 正式生效

**关键约束**：在 Joint Consensus 阶段，Config Log 本身也必须满足联合多数派条件才能提交，这是安全性的核心保障。

#### 3. 应用阶段

副本收到已提交的 Config Log 后，执行**配置应用（Apply）**操作：

- **更新本地成员列表**：修改 `ObPartitionMeta` 中的成员信息
- **调整复制目标**：根据新配置确定需要同步的节点
- **触发状态转换**：如从 Follower 变为 Leader，或进入联合配置态
- **持久化元数据**：将配置写入本地存储（如 `/data/1/obmeta`），保证重启后可恢复

#### 4. 归档与清理

Config Log 具有长期价值，清理策略特殊：

- **不参与日志回收**：即使数据已被合并（Major Freeze），Config Log 仍保留
- **定期快照**：系统定期对配置状态做快照（Checkpoint），旧 Config Log 可归档
- **审计追溯**：所有配置变更历史可用于故障排查、合规审计

---

### 五、与系统模块的协作

#### 1. 与 Clog 模块的集成

Config Log 复用 Clog 的完整基础设施：

- **共享 Log Buffer**：与事务日志共用内存缓冲区，批量顺序刷盘
- **统一文件格式**：存储在相同的 Clog 文件中，通过日志头标识类型
- **相同压缩算法**：使用 LZ4/ZSTD 压缩，减少存储开销

这种设计避免了为配置单独维护存储栈，降低了复杂度和资源消耗。

#### 2. 与 RootService 的交互

RootService 是 OceanBase 的"大脑"，负责全局调度：

- **下发变更指令**：RootService 生成成员变更计划，通过 RPC 通知目标分区 Leader
- **监控执行进度**：通过查询 `__all_virtual_clog_stat` 等系统视图，跟踪 Config Log 的复制状态
- **异常处理**：若 Config Log 长期未提交，触发重试或回滚

#### 3. 与选举模块的协同

Config Log 直接影响选举行为：

- **投票约束**：节点仅向配置中存在的候选者投票
- **任期隔离**：不同 Config Version 的日志属于不同"逻辑任期"，防止旧配置节点干扰新配置选举
- **优先级策略**：Config Log 中可携带 Leader 优先级信息，影响选举结果

---

### 六、关键特性与优化

#### 1. 幂等性与去重

由于网络重传或 Leader 切换，同一 Config Log 可能被多次接收。系统通过 `<config_version, proposal_id>` 二元组唯一标识，确保重复日志仅应用一次。

#### 2. 原子性广播

一批相关的配置变更（如同时添加两个副本）被打包为单个 Config Log，保证原子性生效，避免部分成功导致的配置不一致。

#### 3. 快速路径（Fast Path）

对于单节点变更（如 3 副本替换 1 个节点），OceanBase 优化了 Config Log 的处理：
- 跳过完整的 Joint Consensus 阶段
- 直接生成新配置日志，利用数学性质保证安全
- 减少一次网络往返，变更时间从秒级降至毫秒级

#### 4. 配置校验与防护

Config Log 提交前经过严格校验：
- **合法性检查**：新配置必须包含当前 Leader（避免自杀式变更）
- **多数派保护**：确保变更后仍有足够副本形成多数派
- **地域约束**：校验 Zone/Region 分布符合容灾策略

---

### 七、故障场景处理

#### 1. Config Log 丢失

若某副本磁盘损坏导致 Config Log 丢失：
- 通过 Clog 的 checksum 和连续性检测发现断点
- 向 Leader 请求缺失的日志段
- 极端情况下触发副本重建（Rebuild）

#### 2. 配置分歧检测

系统定期执行**配置一致性校验**：
- 比较各副本的最新 Config Version
- 发现分歧时，以多数派为准，少数派回滚或重建
- 记录到 `__all_virtual_partition_table` 供运维查看

#### 3. 脑裂恢复

若因软件缺陷发生脑裂（理论上 Joint Consensus 应防止）：
- 通过全局时间戳（GTS）和租约过期检测发现
- 强制旧配置节点下线，保留新配置集群
- 人工介入进行数据比对和修复

---

### 八、总结

Config Log 是 OceanBase 实现**配置即日志（Configuration as Log）** 理念的关键组件。它将原本脆弱的"配置管理"转化为可靠的"日志复制"问题，借助 Paxos 协议的强一致性保证，实现了成员变更的绝对安全。

通过 Config Log，OceanBase 得以支持：
- **在线弹性扩缩容**：业务无感知的节点增减
- **自动故障恢复**：秒级的 Leader 切换和副本重建
- **复杂拓扑调度**：异地多活、单元化部署等高级架构
- **审计与合规**：完整的配置变更历史追溯

理解 Config Log 的工作机制，是掌握 OceanBase 高可用架构、进行深度运维调优的必备知识，也是理解现代分布式系统"日志中心化"设计范式的典型案例。