OceanBase 学习笔记（三）：高可用与弹性

前两篇把 OB 跑起来、建了租户能写数据，算是”能用”了。但这篇才是分布式数据库最该懂的部分——它凭什么敢说自己高可用、能弹性扩缩容。核心就两样东西：日志流 + Paxos 多数派，以及在这之上的一套自动调度。这也是我们生产 K8s+OB 上最该心里有数的容灾逻辑。

继续学习笔记体。下面有些机制我一开始也绕了好久，标了”我原来以为…后来才懂”，供同样新手的你参考。

1. 一致性核心：日志流 + Paxos 多数派

每个分区（Tablet）的 Redo 日志会汇成一条日志流（Log Stream），日志流在多个 Zone 之间有多副本。其中有一个主副本（Leader）负责接受写入，其他的都是从副本。

一次写入能不能算成功，看的是：多数派副本都把这个 Redo 日志持久化落盘了，主副本才确认提交。这就是 OB 敢谈高可用的底气——挂掉少数节点，只要多数派还在，服务就不受影响。

主副本不是”终身制”，它靠租约（Lease）活着：被选成主时拿到一段租约，正常工作时在租约期内不停续租；一旦所在机器出问题、租约续不上，等租约失效后其余从副本就会选出新主并授予新租约。主副本只在租约有效期内干活——这才是防脑裂的关键：网络分区时老主最多撑到租约到期，之后不可能出现两个主同时对外服务。

顺带提一句 GTS（全局时间戳服务），这块我一开始和选主搞混了：它不是用来防脑裂的，而是在租户内产生连续递增时间戳的服务，给事务定”提交版本号”、给语句/事务定”读取版本号”，从而实现多版本并发控制（MVCC）和全局一致性快照。至于”时间戳不回退”，那也是 GTS 自己的机制：它本身是多副本的，新主上任前会回放原主写下的预分配区间日志，保证新主给出的时间戳不会比旧主小。

我原来以为”主从复制 + 半同步”就够稳了，后来才搞明白：Paxos 的多数派提交 + 租约防脑裂，才是 OB 高可用的真正机制。半同步顶多算”尽量不丢”，Paxos 是”数学上保证少数派挂了照样对”。

用图把”写入怎么提交、挂了怎么选主”串一下：

日志流 Paxos 多数派提交与选主

仅主副本接受写入；Redo 日志同步给从副本，多数派落盘即提交；主副本故障则重新选主。

2. 副本分布：locality 与 primary_zone

副本到底放在哪些 Zone、Leader 优先在哪，由两个旋钮控制，这俩是运维时最常调的：

locality：决定”租户下日志流在各 Zone 的副本类型和分布”。比如：
- F@z1, F@z2, F@z3：三个 Zone 各一个全能型副本（F = Full）。
- F@z1, F@z2, L@z3：z3 放一个日志型副本（L = Log，只存 Redo 日志不存数据，省存储）。
primary_zone：决定 Leader 优先落在哪些 Zone。分号 ; 表示优先级，逗号 , 表示同优先级。比如 z1;z2;z3 就是 z1 最优先当主。

要容几个机房、读写主战场放哪，全靠这俩配合。

我踩的坑：以为 locality 建完就定死了。其实可以在线改——ALTER TENANT ... SET locality = 'F@z1, F@z2, L@z3'，OB 会自动去创建 / 删除 / 迁移副本，直到贴合新的 locality。不用停机重建。

3. 弹性：加节点扩容与自动均衡

传统库扩容往往要停机、或者自己搞分库分表。OB 的弹性是”加机器 → 自动再均衡”：

往集群加 OBServer（集群维度多出资源）；
给租户调大资源规格——比如 Resource Pool 加 Unit，或者调大 UNIT_NUM；
新资源形成新的 Unit，RootService 把日志流分裂、把 Tablet 迁移到新机器上；
等各机器负载重新均衡，扩容就完成了。

缩容反过来：先把目标机器上的日志流迁走、合并，再下线机器。整个过程由均衡层负责（日志流分裂/合并 + Tablet 迁移），不需要人工去搬数据。

体会：这一步对运维太友好了——以前加一台机器意味着一堆手工活，现在基本是声明式地”给租户多点资源”，剩下的 RootService 自己跑。

4. 一个 Zone 挂了会发生什么（容灾视角）

这才是重点，直接对应我们 K8s 上”一个 AZ 挂了”的场景：

少数派副本所在 Zone 挂：多数派还在，服务不受影响，只是少了一份冗余，赶紧修机器。
主副本所在 Zone 挂：租约续不上 → 其余副本选新主 → 服务恢复。期间没提交完的事务，靠两阶段提交状态机回放 Redo / Commit 日志恢复，最终一致。

所以生产至少建议 3 个 Zone（3 副本，容忍 1 个挂）；两地三中心通常用 5 副本，容忍一整个 IDC 挂。落到我们 K8s+OB 场景：K8s 的一个可用区（AZ）失联，在 OB 看来就是一个 Zone 失联，上面的机制完全适用——理解到这一层，才算真懂”云上高可用”是怎么来的。