OceanBase 数据库选举

详细说明

OceanBase 数据库的选举（Election）是 OceanBase 数据库的基础组件之一，为上层提供选主服务。OceanBase 是一款分布式数据库，以分区为单位的数据保存在数据库不同副本中，选举模块能够在多个全功能副本中选举出一个 Leader 作为主副本对外提供数据服务。

OceanBase 数据库的选举模型是依赖时钟同步的选举方案，同个分区的多个全能副本在一个选举周期内进行预投票、投票、计票广播以及结束投票，最终敲定唯一的主副本。当选举成功后，每个副本会签订认定 Leader 的租约（Lease）。在租约过期前，Leader 会不断发起连任，正常情况下能够一直连任成功。如果 Leader 没有连任成功，在租约到期后会周期性的发起无主选举，保证数据有主副本对外提供数据服务。

OceanBase 数据库的选举模块会选举出 Leader 副本对外提供数据服务，为了方便解释，我们在解释选举原理时，先将选举的基础条件假定成理想的环境：

• 多个副本节点之间时钟完全一致。

• 所有选举的投票消息都有效快速地达到了目标地。

OBServer 在正常运行过程中，每个副本会签订认定 Leader 的租约（Lease），在租约过期前，Leader 会不断发起连任，连任成功，原主保持 Leader 副本角色，继续对外提供数据服务，这叫做有主连任。如下图所示，解释了最简单的有主连任场景，原主在租约周期过期前经过一次连任尝试就已经连任成功。

说明

图中的时间轴仅标明时间的先后发生序列，跨度距离与绝对时间不强对应。

OBServer 在正常运行过程中，原主副本因为各种原因不能作为主副本对外提供数据服务，OceanBase 数据库在其他多数派的副本中选举出新的 Leader 副本作为新主上任，这个过程就是发起了无主选举，最终新主上任。无主选举是每个 OBServer 发起的。

说明

图中的时间轴仅标明时间的先后发生序列，跨度距离与绝对时间不强对应。

在 OceanBase 数据库的实际运行中，上面的理想环境是几乎不可能，所以选举模块的实际实现要考虑的因素和异常处理要远比上述解释的基础原理要复杂的多。在大部分时候，如果是想要理论学习 OceanBase 数据库选举模块的原理，不需要一次性地深入细节。但是当遇到具体问题，特别是在故障诊断情况下，有可能需要与 OceanBase 数据库技术支持人员共同梳理细节，分析问题。

相关参数/变量

相关系统视图/系统表

名词解释

1.OceanBase 选举有哪几种，分别是由谁发起的？

OceanBase 在实现上主要包含无主选举、有主连任、有主改选（切主）这几个部分。其中，无主选举是在集群启动或者 Leader 连任失败的时候才会进行。除了手动切主以及无主选举，其他的自动选举均是 RootService（OceanBase 主控服务）的 Leader Coordinator 组件发起的。

2.什么样的副本可以参与选举？

OceanBase 的副本类型有全能型副本（FULL）、日志型副本（LogOn）、只读型副本（ReadOnly）。其中，日志型副本和全能型副本参与选举投票。 只有全能型副本可以作为选举中 Leader 的候选者（Candidate），变为主提供数据库服务。日志型副本可以提供日志服务但不是选举中 Leader 的候选者，不能被选举为主提供数据服务。

3.OceanBase 的选举模块的对基础设施的要求有哪些？

OceanBase 的选举模型是依赖时钟同步的选举方案，在选举模块的运行过程中，OceanBase 会在节点间发送 RPC 消息来传送选举相关的消息。为了保证选举模块的正常运行，OceanBase 内核对 OBServer 间的网络延迟时间、NTP 时钟服务的正确性准确性都有比较高的要求。同时，节点间传输的 RPC 消息除了选举的消息还有 cLog 同步相关的信息等。连同 OceanBase 的 clog 模块、事务等基础模块的要求，OceanBase 整体上推荐节点间的网络延迟时间（单向延迟）最好保证在 50ms 以内，最差（单向延迟）也要在 100ms 以内。OBServer 环境中的时钟服务应该保证时钟同步的偏差在 100ms 以内，且不能够产生 1s 及以上的时钟跳变。如果运行 OceanBase 的基础设施达不到上述提到的网络延迟，NTP 服务的最低要求，有可能会出现 OceanBase 事务、选举、日志、主控模块，主备库场景等基础模块的异常情况。

4.OceanBase 的选举模块是如何保证 RTO< 30s 的？

OceanBase 的选举模型是依赖时钟同步的选举方案，同个分区的多个全能型副本在一个选举周期内进行预投票、投票、计票广播以及结束投票，最终敲定唯一的主副本。当选举成功后，每个副本会签订认定 Leader 的租约（Lease）。在租约过期前，Leader 会不断发起连任，正常情况下能够一直连任成功。如果 Leader 没有连任成功，在租约到期后会周期性地发起无主选举，保证副本的高可用。比如在三个副本（全能型副本）场景下，当一个副本出现异常（比如说该节点机器故障，OBServer 下线等单点故障），OceanBase 选举模块能够做到：如果原主副本连任成功，原主可以连续提供主副本服务；如果原主副本下线，Leader 连任失败，OceanBase 进行无主选举，新主上任的时间在 30s 内完成。

5.如果多数派副本宕机，OceanBase 的选举模块是否还可以选出 Leader 副本保证高可用？

当 OceanBase 中的多数派副本同时宕机时，OceanBase 无法再选举出主副本（Leader 副本）对外提供数据服务。

6.Oceanbase 的选举模块是否需要做任何主动运维操作？

在集群的正常运行过程中，不需要 DBA 或者管理员进行任何人为的操作或者干预来控制或影响 OBServer 的选举模块完成其功能。在进行集群管理动作时，比如说停止 OBServer，上线新的 OBServer，修改租户的 Primary Zone 设置也都有可能会触发选举模块进行选举来保证租户中的数据副本会有主副本作为 Leader 对外提供数据服务。到目前为止没有任何的系统运行情况需要管理员直接对选举模块进行运维干预。

7.在选举中哪个副本会被选为主？OceanBase 选举模如何保证选举到的 Leader 副本是更好的选择？

OceanBase 的选举会比较副本的优先级，保证尽量选出来一个健康状况更好更优的机器作为 Leader 副本。目前 OceanBase 的优先级主要考虑了副本是否是 Leader 的合法候选人，副本健康分，副本成员列表版本号，以及副本日志同步状况四个维度。这也意味着通过 OceanBase 自动触发的选举最终会让更健康，版本推进最新的合法选举副本被选为主。OceanBase 的有主选举和无主选举因场景不同，在实现优先级比较方式会略有区别。除了手动切主指定主的目标端， OceanBase 的选主模块最终会将 Primary Zone 中设定的优先级更高的合法副本选为 Leader。选举的优先级也可以在系统虚表 __all_virtual_election_priority 中查到详情。

8.RootService 触发的自动切主是如何控制的，在什么情况下会有自动切主？

除了手工发起的切主命令，以及底层无主选举外，所有的自动切主操作都是由 RootService 端发起。 RootService 启动时，会开启一个 leader_coordinator 线程，定期轮询当前时刻的所有 Tenant，根据实际情况来决定是否生成对应的切主操作，常见的 RootService 发生切主的原因有：

• Primary Zone 发生变更。（RootService根据primary_zone的优先级进行切主）

• 发生 Stop Server/Zone 的操作。（RootService 会先将对应 Server 和 Zone 上的 Leader 切到其他的 Server上）

• 发生合并（打开轮转合并开关）。（当打开轮转合并开关时，会根据规则对不同的 Zone 进行合并，正在合并的 Zone，RS 会将其上的 Leader 切到其他的 Zone上）。

• 进行负载均衡操作时会将相关的 Partition 的 Leader 切走。（eg：进行 unit 迁移、remove_member、locality 变更等，会在进行负载均衡前，将待操作的分区的 Leader 切到其他的 Server 上）。

• RS 后台进行自动 Leader 均衡。根据各个均衡组，若均衡组不均衡，那么会发起自动的均衡任务。

9.OceanBase 选举是以分区为单位进行，如果分区数量极大，OceanBase 是如何保证选举（比如有主连任）性能且不造成系统过大负载的？

OceanBase 数据库 V2.0 版本开始，为了支持单机十万级分区，优化了选举的 CPU 开销，引入了虚拟组的概念。所谓虚拟组，就是把特定数量个特征相同的选举实例聚合为一组，以组为单位进行连任。

10.如何查看 RootService 自动发起的切主？如果 RootService 自动触发了切主，如何诊断分析切主原因？

RootService 自动发起的切主都会记录在 __all_rootservice_event_history 系统表里。在确定了在可疑的时间范围内发生了 RootServcie 自动发起的切主可以按照以下步骤分析切主的具体原因：

1. 查看对应租户的 Primary Zone 信息。

   obclient> SELECT primary_zone FROM oceanbase.__all_tenant WHERE tenant_id = xxx;
   

2. 查看该租户下的各级（database/tablegroup/table）信息的 primary_zone。（database 和 tenant 的级别相同，tablegroup 和 table 若不指定的话，向上继承 primary_zone。因此，需要将 database 和 tenant 的 primary_zone 尽量设置相同。）

   1. Database 级别。

      obclient> SELECT count(*) FROM oceanbase.__all_virtual_database WHERE tenant_id = xxx AND primary_zone != "";
      

   2. Table 级别。

      obclient> SELECT count(*) FROM oceanbase.__all_virtual_table WHERE tenant_id = xxx AND primary_zone != "";
      

   3. TableGroup 级别。

      obclient> SELECT count(*) FROM oceanbase.__all_virtual_tablegroup WHERE tenant_id = xxx AND primary_zone != ""；
      

3. 查看对应 Server 和 Zone 是否已经被停止 Stop。

   1. SELECT * FROM oceanbase.__all_server WHERE stop_time != 0;（此查询中的 Server 已经被 Stop，不能成为 Leader）

   2. select * from oceanbase.__all_zone where name = 'status' and info != 'ACTIVE';（此查询中的 Zone下的所有 Server 都不能成为 Leader）

4. 查看当前是否有补副本、副本迁移、副本 Locality 变更等操作。

   1. select count(*) from oceanbase.__all_virtual_rebalance_task_stat where tenant_id = xxx and task_type in ('ADD_REPLICA', 'MIGRATE_REPLICA', 'TYPE_TRANSFORM');（该租户下存在负载均衡任务，需要等待均衡完成，才能判断切主是否均衡）

   2. select count(*) from oceanbase.__all_virtual_replica_task where tenant_id = xxx and cmd_type in ('ADD_REPLICA', 'MIGRATE_REPLICA', 'TYPE_TRANSFORM');

5. 查看最近（例如，30 分钟内）是否有 Server 存在宕机的情况。

   1. SELECT * FROM oceanbase.__all_rootservice_event_history WHERE module = 'server' AND gmt_create > usec_to_time(time_to_usec(now())-1800000000) ORDER BY gmt_create desc;（若 Server 存在过宕机的情况，那么 clog 会将其放入到黑名单中，如果放入到黑名单中，那么在从黑名单中剔除之前，一直不能成为 Leader）

   2. 查看 Server 处在黑名单中的时间：show parameters like "%election_blacklist_interval%";（默认是半小时）

   3. 解决方法：alter system set election_blacklist_interval = '10s'; 通过调小剔除黑名单的时间，来尽快将该 Server 从黑名单中剔除，成为 Leader。调整后，根据需要将这个值再次调整到相应时间。

6. 查看当前是否正在执行轮转合并。

   select * from oceanbase.__all_zone where name = 'merge_status' and info = 'MERGING';（当该 Zone 处于合并之前，会将该 Zone 上的 Leader 切走，当合并完成后，会重新根据 primary_zone 来决定 Leader 的分布）

7. 在 rootservice.log 上查询 'choose leader info' 来获得。通过该日志就可分析出，RS 具体是根据哪个条件触发的切主。

11.如何查看租户/分区的 Leader，Follower 副本的位置信息？

在选举模块进行问题排查时，通常需要获取对应租户和分区的 Leader，Follower 位置信息。用下面的查询可以进行租户、分区的 Leader Follower 位置信息：

1. 确认租户和表的信息。

   obclient> SELECT tenant_id FROM oceanbase.__all_tenant WHERE tenant_name LIKE '%xxx%';
   obclient> SELECT table_id FROM oceanbase.__all_virtual_table WHERE table_name LIKE '%xxx%';
   

2. 获取租户 Leader 的位置信息。

   1. 查询 Leader 的整体分布，role=1 表示 Leader，role=2 表示 Follower。

      obclient> SELECT distinct svr_ip, role, replica_type FROM oceanbase.__all_virtual_meta_table where tenant_id=xxx ORDER BY replica_type;
      

   2. 也可以查询其他内部表，确认 Leader 和 Follower 的分布。

      -- 
      obclient> SELECT distinct svr_ip, role, replica_type FROM oceanbase.__all_virtual_clog_stat WHERE (table_id >> 40) = xxx ORDER BY replica_type;
      

      其中，xxx 为当前租户的 tenant_id。

   3. 查询某个分区的分区位置信息。

      obclient> SELECT svr_ip, table_id, partition_id, role, replica_type FROM oceanbase.__all_virtual_meta_table where table_id=xxx and partition_id=xxx ORDER BY replica_type;
      obclient> SELECT svr_ip, table_id, partition_idx, role, replica_type FROM oceanbase.__all_virtual_clog_stat where table_id=xxx and partition_idx=xxx ORDER BY replica_type;
      

12.如何查看无主选举？

目前 OceanBase 还没有直接的视图可以直接查看所有的无主选举事件，OceanBase 研发团队正在开发该视图。在该视图发布之前可以用下面的方法来查看无主选举事件。

• 查看最近（比如说 30 分钟内）是否有原主租约过期的情况。

  obclient>SELECT * FROM oceanbase.__all_rootservice_event_history WHERE module = 'server' AND event = 'lease_expire' AND gmt_create > usec_to_time(time_to_usec(now())-3600*1000000) ORDER BY gmt_create;
  

• 在新主的 observer.log 里，decentralized voting，leader take over sucess 标记无主选举成功。

13.OceanBase 报错 -4038、-7006 是什么含义？OceanBase 的副本是否出现无主的现象？如何排查无主根因？

OceanBase 在正常状况下不会出现副本无主的情况。如果副本多数派宕机，那么会直接造成无主。在运维过程中，如果直接将 OceanBase 的多数派副本所在的机器进行宕机，会造成副本无主，这是符合预期的行为，应当继续执行运维动作，无需干预。但是，如果在 OceanBase 正常运行的过程中，OceanBase 的数据副本产生了无主的情况，是需要当做问题来进行排查的。当副本出现了无主的现象，在 observer.log 中可以发现在调用时返回 -4038、-7006 的报错。在查询时，请注意匹配报错对应的时间。在做副本无主问题排查时需要执行下面的动作：

• 查询无主的分区。

  1. 执行以下 SQL 语句，统计当前 Election 模块无主的分区列表。

     obclient> (SELECT table_id, partition_idx FROM oceanbase.__all_virtual_election_info GROUP BY table_id, partition_idx) EXCEPT (SELECT table_id, partition_idx FROM oceanbase.__all_virtual_election_info WHERE role = 1);
     

  2. 执行以下 SQL 语句，统计当前 clog 层无主的分区列表。

     obclient> (SELECT table_id, partition_idx FROM oceanbase.__all_virtual_clog_stat GROUP BY table_id, partition_idx) EXCEPT (SELECT table_id, partition_idx FROM __all_virtual_clog_stat WHERE role = 'LEADER');
     

  3. 执行以下 SQL 语句，统计 RS 视角无主的分区列表（有 Schema、Meta 表无主）。

     obclient> SELECT tenant_id, table_id, partition_id FROM oceanbase.__all_virtual_partition_table GROUP BY 1,2,3 HAVING min(role) = 2;
     

• 当发现无主报错 -4038、-7006，如果上述步骤中的系统表不可查，可以在 observer.log 日志中查询对应时段的 ERROR 日志。如果副本节点的 observer.log 报错 "leader lease is expired"，则意味着原主的租约过期。通常情况下看到 reconfirm、leader_active_need_swtich 等关键词的 ERROR 日志也表示分区无主。这时候要初步排查一下是否有内存分配失败、磁盘满等明显报错。通常情况下，会引起无主问题的主要有以下场景：

  • 时钟偏差。

    OceanBase 的选举模块属于强依赖时钟同步的选举模型，当前 OceanBase 选举模块依赖任意两个 OBServer 之间的时钟偏差不超过 200ms，如果超过则可能导致无主。您可以通过以下命令检查 OBServer 之间的时钟是否同步。

    [root@hostname /]# sudo clockdiff $IP 
    

    如果结果显示的 delta 值超过 200ms，则需要继续检查 NTP 服务是否工作正常。

  • 多数派副本不可用：多数派副本宕机，或者多数派不可用副本中有正在replay的副本需等待：

    1. 发生无主时，在所有副本上用 "leader lease is expired" 去搜索 election.log ，对应的 tid（table_id 和 partition_id）是在查询的无主副本，从检索到的日志里找到该副本的 curr_candidates。从日志中检索到的 curr_candidates 就是该副本的 Leader 角色候选者。

    2. 从上步骤的 curr_candidates 中各个 Server 上检查当时是否处于宕机，如果 curr_candidates 中多数派 Server 已经宕机，副本无主是符合期望的。管理员需要解决和分析多数派无主的问题。当前如果不是多数派 Server 宕机，则需要进一步检查判断：

       1. OBServer 是否处于 CPU Load 偏高的资源瓶颈下导致无主。一方面可以用 top 等工具直接查看 OBServer 上的 CPU 使用率以及 Load 值。另一方面如果 election.log 日志中已经有关键字 'run time out of range'，那么可以执行进行下一步检查。

       2. OBServer 是否处于宕机重启扫盘阶段，可以在 observer.log 中搜索 "scan process bar" 相关日志，如果存在该日志则说明扫盘还未完成，副本处于 Replay 状态（Election 模块还未开始工作），该日志末尾的 estimated_rest_time 表示预计扫盘完成所需时间。

  • 网络问题。

    如果多数派副本进程都在，未发生宕机重启，且 Leader 上报 "leader lease is expired" 的 Lease 过期日志（包含对应无主副本的 table_id 和 partition_id），说明 Leader 连任（延长自己的 Lease）失败了，这种情况下有可能发生了网络故障（单向/双向网络隔离、RPC 请求积压）。具体可能的场景如下：

    • 不符合预期的网络隔离配置。

      首先执行以下命令，检查各个副本所在机器上的 Iptables 查看是否主动阻塞了网络。

      [root@hostname /]#sudo iptables -L
      

      如果 Follower 与 Leader 的网络被阻塞了，导致 Leader 与多数派（含自己）网络无法联通，那么无主也是符合预期的。

    • 请求积压，由于某种原因，这台机器所在的 RPC 处理产生积压，不能得到及时处理。这个时候需要进行进一步分析 observer.log 里 RPC 的状态和队列情况：

      • 某个副本上报 "leader lease is expired" 日志时，首先检查自己的 RPC 是否工作正常。

        • 在 observer.log 中搜索 RPC EASY STAT，查看 Request Doing 值是否过大，如果达到千级别，说明 RPC 消息有明显的积压，需要继续排查网络是否异常。

        • 在 observer.log 中搜索 dump tenant info 查看 id=500 的租户请求队列的 total_size 值是否过大，过大表示本机 500 租户请求积压了，可能是某些请求处理卡住，这会导致后面的 Election 请求得不到处理。

    • 如果本机的如上检查正常，那么需要到 Leader 所在机器上做相同检查，如果 Leader上 RPC 故障也会导致无主。

    • 如果本机、Leader 上的 RPC工作均正常，且 Leader 上也报了 Lease 过期，那么可能是集群中其他副本发生了异常，导致 Leader 连任无法收到多数派的投票，从而连任失败。

• 由于网络原因引起的 RPC 延迟或者重传。

  如果由于某种原因 RPC 延迟突然增大，导致 Leader 在预期时间内没有收到多数派的投票，会进一步导致连任失败，Lease 过期。如果在问题发生的时段，从 OceanBase 的 election.log 里面可以看到大量 'message not in time' 的报错，observer.log 里有大量 'packet fly cost too much'，那就进一步佐证了 RPC 表现出的网络问题。通常情况下需要对网络链路进行诊断查看造成网络重传的原因。从 OBServer 的节点上也可以利用操作系统的工具来看网络重传包的概率。如果发现了 RPC 目标端网络重传很高，但是节点间网络设备比较多，建议让网络团队一起用其他网络诊断手段或者 tcpdump 进行隔离排查。

• Clog Reconfirm 失败。

  OceanBase 的数据副本由选举模块进行选举，选举后 Election 模块工作正常，选出了 Leader，但在 clog 模块执行 Reconfirm 时失败了，此时 Leader 会主动卸任，这种场景可以通过在 Leader 所在机器的 election.log 中利用 table_id+partition_id 和关键词 "take the initiative leader revoke" 来搜索相关日志。clog reconfirm 类型的问题排查会在 FAQ: OceanBase clog 里详细说明。

• 机器 clog 盘满。

  如果机器的 clog 盘使用超过 95%，会强制停写，此时该机器上的副本无法当选为主，如果多数派副本所在机器都发生这种情况，那么集群会无主。在这种情况下，observer.log 里会报 ERROR日志 "clog disk is almost full"。

当执行了以上操作后仍然无法找到无主的原因时，请联系 OceanBase 数据库技术支持人员参与问题诊断分析。

14.clog 模块会影响副本选举么？是如何影响的？

OceanBase 以分区为单位的数据保存在数据库不同副本中，选举模块能够在多个全功能型副本中选举一个 Leader 作为主副本对外提供服务。OceanBase 通过 clog 作为核心模块提供数据的高可靠高可用的服务。在 OceanBase 的分布式架构实现中，clog 会主动地周期性地检查副本的状态以确保分区副本能够形成多数派且主副本能够正常对外提供服务；clog 的周期性检查会在副本状态异常，在还有多数派的情况下决定是否进行主动卸主动作（Leader Revoke），在发现主副本无法正常提供副本服务时，会打印一条 ERROR 日志并主动卸任，在能够形成多数派的副本中 Election 模块执行无主选举选择新主。

15.clog 发起的主动卸主的常见原因有哪些？在发生主动卸主后会重新选主么？

clog 模块后台线程会定期扫描 Leader 的状态，在发现主副本无法正常提供副本服务时，会打印一条 ERROR 日志并主动卸任，在能够形成多数派的副本中 Election 模块执行无主选举选择新主。在 observer.log 日志中执行以下搜索命令即可查询 clog 主动卸主的原因。

grep ERROR <election.log> | grep leader_revoke

其中卸主的直接原因在 reason= 后的字段中显示。更多更详细的原因诊断会在FAQ: OceanBase clog 中详细解释。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。