仲裁服务概述

OceanBase 数据库在当前版本引入了仲裁服务（Arbitration Service），不仅可以解决两地三中心同城副本故障时 RT 变大的问题，还能降低跨城带宽开销，并将第三机房的成本降到极低。

仲裁服务中维护着租户日志流对应的仲裁成员，仲裁成员具备如下特征：

• 仅参与选举、Paxos Prepare 以及成员组变更投票，不参与日志多数派投票（Paxos Accept）。

• 不存储日志，无 MemTable 和 SSTable，资源（带宽/内存/磁盘/CPU）开销极小。

• 不能当选为主提供服务。

当半数全功能副本故障导致日志同步失败并且达到日志流降级控制时间时，仲裁服务会自动执行日志流降级流程，将故障副本从成员列表中删除（但租户的 Locality 不会变化），从而恢复服务，且能做到 RPO = 0。待故障的全功能副本恢复时，仲裁服务又会执行日志流升级流程，将被降级的副本重新加入成员列表，提供更高的可用性保证。

日志流降级策略

目前，当半数副本出现以下异常并导致日志无法同步时，仲裁服务会执行日志流降级操作：

• 副本所在的 Server 宕机

• 对副本所在节点执行了 ALTER SYSTEM STOP SERVER 命令或对副本所在的 Zone 执行了 ALTER SYSTEM STOP ZONE 命令

• 对副本所在的 observer 进程执行了 kill -9、kill -15、kill -19 等操作

• 副本所在的 Server 网络中断

• 副本所在的 Server 上租户日志盘满

• 副本因长时间故障导致日志落后于 Leader，故障恢复后将触发副本 Rebuild，Rebuild 期间由于该副本数据和日志不完整，无法执行日志流升级。

日志流降级的主要流程如下：

1. 日志流 Leader 上运行的仲裁服务发现一些副本在 arbitration_timeout 内没有向 Leader 回复日志确认消息，仲裁服务将执行进一步检查，准备对日志不同步的副本进行日志流降级操作。

2. 仲裁服务通过周期性探测，检查日志不同步的副本是否存在降级策略中所列的异常，如果存在异常，则执行日志流降级操作。

   注意

   仅当故障副本（包括已降级的副本）总数等于全功能副本总数的一半时，仲裁服务才会执行日志流降级操作。例如，4F1A（4 个 F 副本加 1 个仲裁服务）部署场景下：

   • 如果只有 1 个 F 副本出现异常，仲裁服务不会执行日志流降级，因为此时 4F 的多数派 3F 依然存活，可以正常同步日志。
   • 如果有 2 个 F 副本出现异常（例如：2 个 F 副本网络中断，或者一个 F 副本 Rebuild，一个 F 副本所在 Server 宕机），仲裁服务会执行日志流降级。
   • 如果有 3 个及以上 F 副本出现异常，此时仅存活一个 F 副本和仲裁服务，不满足多数派，日志流将会无主，无法执行日志流降级。

集群中是否发生了日志流降级可以通过语句 SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE DEGRADED_LIST NOT LIKE ''; 来确认，如果查询结果中有日志流对应的 DEGRADED_LIST 记录不为空，则表示该日志流发生了降级。

日志流升级策略

如果当前日志流已经处于降级状态，仲裁服务会周期性检测 DEGRADED_LIST 中的副本，如果发现被降级的副本的日志同步已恢复，并且该副本不存在降级策略中所列出的异常，则允许日志流升级。

日志流升级的主要流程如下：

1. 日志流 Leader 上运行的仲裁服务周期性检测 DEGRADED_LIST 中的副本，如果被降级的副本向 Leader 回复了日志确认消息，仲裁服务将执行进一步检查，准备对被降级的副本进行日志流升级。

2. 仲裁服务检查被降级的副本是否还存在日志流降级策略中所列出的异常，如果不存在异常，则执行日志流升级操作。

   注意

   日志流升级时，不要求所有被降级的副本均没有异常。例如，4F1A（4 个 F 副本加 1 个仲裁服务）部署场景下，2 个 F 副本由于所在的 Server 宕机被降级，如果后续只有 1 个 F 副本恢复并开始同步日志，仲裁服务依然会针对该恢复的副本执行日志流升级操作。

相关文档

更多仲裁服务相关的操作，请参见以下内容：

• 部署两副本加仲裁服务的 OceanBase 集群

• 为租户开启仲裁服务

• 为租户关闭仲裁服务

• 修改日志流降级控制时间

• 为集群替换仲裁服务

• 为集群删除仲裁服务

• 清理残留的集群信息