仲裁高可用方案

仲裁概述

对于分布式数据库来说，当多个数据副本间发生半数异常时（一半副本故障或与另一半网络隔离），可以通过集群之外的仲裁服务来参与变更决策（选主/成员组变更），进而恢复服务。OceanBase 数据库 V4.1.0 版本开始支持仲裁服务（Arbitration Service），仲裁服务是为 OceanBase 集群提供仲裁能力的一个独立进程。这是一种基于 Paxos 多副本容灾方案提出的新型高可用方案。

仲裁服务独立于 OceanBase 集群部署，是一个以特殊模式启动的轻量级 observer 进程，它承载着日志流级别的仲裁成员。 仲裁成员具备如下特征：

• 仅参与选举、Paxos Prepare 以及成员组变更投票，不参与日志多数派投票（Paxos Accept）。
• 不存储日志，无 MemTable 和 SSTable，资源（带宽/内存/磁盘/CPU）开销极小。
• 不能当选为主提供服务。

仲裁服务的优势

仲裁高可用方案的优势如下：

• 仲裁成员可取代之前日志型副本的使用场景，在可用性几乎不变的情况下降低部署成本。
• 半数全功能副本故障时，仲裁自动降级恢复服务，降级后业务 RT 不受影响（无需跨城同步日志）。
• 仲裁成员无需同步日志、回放日志，也不存储 Redo 日志、基线数据，因此仲裁服务的资源（CPU /内存/磁盘/带宽）开销显著降低。
• 与主备库方案相比，仲裁方案在两个全功能副本的基础上利用极低的额外资源开销实现了无损双活能力，支持自动升降级，且无数据损失（RPO=0）。

应用场景

仲裁高可用方案的适用场景如下：

• 同城双机房，且具备独立部署仲裁的条件（可跨城）。
• 跨城带宽资源稀缺。
• 成本敏感或预算有限。
• 希望具备无损双活能力，且能接受可用性略低于 3F/5F。

仲裁高可用方案和全 F 部署方案相比，成本更低，但代价是可用性也略低于后者。以 2F1A 为例，1 个 F 副本故障后触发仲裁降级，之后仅剩单副本同步日志，极端情况下如果第二个 F 副本也发生故障且无法恢复，之后即使第一个 F 副本恢复了，也会有数据丢失，原因是仲裁成员不存储 Redo 日志，3F 部署场景则没有这个问题。

不适合使用仲裁的场景：

• 仅有两个机房，没有额外的机器/机房可用于部署仲裁，这种场景适合使用主备库容灾方案；
• 希望系统具备极致的可用性，能接受全功能副本的使用成本，适合使用 Paxos 多副本容灾方案。

各个容灾方案的对比请参见容灾部署方案。

配置仲裁服务

前提条件

仅当租户的 Locality 为 2F 或 4F 时，才可以开启仲裁服务。

部署仲裁服务

仲裁服务目前是单机部署的，您需要准备一台适合的机器，其资源规格需要满足相应的部署需求。然后，您可以使用仲裁模式特有的启动参数来启动 observer 进程。更多内容请参见 使用命令行部署两副本加仲裁服务的 OceanBase 集群。

使用仲裁服务

仲裁服务部署完成后，首先在 OceanBase 集群中执行添加仲裁服务操作，之后集群内的租户就可以使用仲裁服务了。 单个仲裁服务可以支持多个 OceanBase 集群使用。

开启/关闭仲裁服务

在 OceanBase 集群内，支持按照租户为单位来开启或关闭仲裁服务。

• 为租户开启仲裁服务

• 为租户关闭仲裁服务

自动升降级机制

租户开启仲裁后，当半数以上的全功能副本发生故障导致日志无法达成多数派时，可以通过仲裁实现自动降级，以恢复服务，并且实现 RPO = 0。待故障副本恢复后，集群可以自动升级，恢复为初始的成员列表。

自动升降级的实现原理如下图所示，在降级时，将发生故障的全功能副本变更为 Learner 角色；在升级时进行反向变更，将 Learner 变更回全功能副本。

可能触发降级的场景如下：

• Server 网络中断或宕机
• 触发 Rebuild 副本
• 执行了 STOP SERVER/STOP ZONE/ISOLATE SERVER 指令
• 对 observer 进程执行了 kill -9、kill -15、kill -19 操作
• Server 上租户日志盘满或日志盘 Hang（日志盘指 Clog 目录所在的盘）

操作仲裁服务

在 OceanBase 集群内开启仲裁服务后，支持替换或删除仲裁服务操作。

• 为集群替换仲裁服务

• 为集群删除仲裁服务