OceanBase 数据库 V4.0 版本中无主问题排查手册

OceanBase 数据库中无主的表现为 ls 没有 Leader，在 V4.0 版本中是低耦合的分层。

ls 是否有主取决于三个基础模块，自底向上分别介绍：

• Election 模块：基于 OceanBase 数据库特有的选举算法，保证 Leader 的唯一性，称其为 election leader。

• Clog 模块：基于 Election leader，先执行 reconfrim 流程，保证 Clog Leader 具有全量日志，然后执行 Clog 的上任流程，对于 Clog Leader 而言，其上任流程为异步的通知 RoleChangeService 模块，此后 `Clog Leader 有效。

• RoleChangeService 模块：当感知到 Clog Leader 需要执行上任流程后，会负责执行具体的上任逻辑。在 OceanBase 数据库 V4.0 版本中，需要感知主备切换的模块均以组件的方式接入 RoleChangeService，详细参见：OceanBase 数据库 V4.0 版本容灾问题排查（RS 相关），其中 GTS 也做为了感知主备切换的组件接入了 RoleChangeService 。

因此，当 ls 没有 Leader 时，我们需要自底向上的排查，具体的，分别采用以下步骤：

1. 第一步：确定 Election 是否有主。

   排查参见：选举层面无主问题排查指南。

2. 第二步：确定 Clog 是否有主。

   Election leader 有效的前提下，排查 Clog 是否有主。

   • 如果集群可用（SQL 客户端可连接），可以通过指定日志流 ID 以及租户 ID，查询 __all_virtual_log_stat 表。

     obclient> select * from oceanbase.__all_virtual_log_stat where tenant_id=xxx and ls_id=xxx and role="LEADER";
     

   • 如果虚拟表查询结果中 server 个数少于 memberlist 中的副本数，则说明某些副本的状态已经出现了异常，没有回复查询虚拟表的 RPC 。

   • 如果 Clog 无主，联系 OceanBase 技术支持并提供相应的日志信息。

   • 如果有主，转 第三步：确定 RoleChangeService 工作是否正常， 排查 RoleChangeService 是否异常。

   • 如果集群不可用，此时需要搜索日志来判断 Clog 是否有主。

     基于 第一步：确定 Election 是否有主 中获取的 `Election Leader，去该机器上执行以下命令。

     # 其中 Txxx 为 tenant_id，例如 T1001 为搜索 1001 租户的日志；
     # palf_id 为日志流 id，例如 palf_id=1001 为搜索 1001 日志流的日志
     grep 'Txxx_.*PALF_DUMP.*palf_id=xxxx,' observer.log.* | less
     

   • 如果发现 role 是 follower，联系 OceanBase 技术支持并提供相应的日志信息，反之如果是 role 是 Leader，接着 第三步：确定 RoleChangeService 工作是否正常 进行排查。

3. 第三步：确定 RoleChangeService 工作是否正常

   当 Clog 层发生角色切换时，会投递一个异步任务交由 RoleChangeService 的任务队列，RoleChangeService 会有后台线程负责执行主备切换动作，目前 RoleChangeService 没有虚拟表或者视图，因此需要根据日志排查：

   grep 'Txxx_RCS' observer.log.xxxx rootservice.log.xxxx -h | sort | less
   

   在日志不限流的情况下：

   • 查看最后一条日志是否是：end handle_role_change_event_，如果不是，说明执行切主动作卡住，查看最后一条日志中打印的堆栈可以确定问题，联系 OceanBase 技术支持并提供相应的日志信息。

   • 如果最后一条日志是 end handle_role_change_event_，同时 Clog 有主，那说明 RoleChangeService 有 BUG，联系 OceanBase 技术支持并提供相应的日志信息。

适用版本

OceanBase 数据库 V4.0 版本。