OceanBase 数据库无主状态的排查方法

介绍如何确认无主，以及造成无主的原因的排查方法。

适用版本

OceanBase 数据库所有版本

确认无主状态

对于容灾场景的测试过程中，经常会出现无主的情况，Election 模块的正常工作依赖于集群多数派副本进程正常且多数派与 Leader 间的网络连通。可以搜索 election.log 日志查看当前是否有副本无主。

[admin@hostname log]$ grep 'lease is expire' election.log

如果上述日志具有内容，则表示当前存在副本无主。 此外，还可以通过以下方式确认是否有副本处于无主状态。

• 通过 table_id、partition_idx 查询 __all_meta_table（对于 OceanBase 数据库 V2.X 及后续版本，查询

  __all_virtual_meta_table）、__all_virtual_clog_stat、__all_virtual_election_info 表，查看 role 或 leader 列的情况。 如果所有分区的 role 均为 2，则表示该分区无主；如果 leader 为空，也表示无主。

  obclient> SELECT * FROM __all_meta_table WHERE table_id=xxx;
  obclient> SELECT * FROM __all_virtual_meta_table WHERE table_id=xxx;
  obclient> SELECT * FROM __all_virtual_clog_stat WHERE table_id=xxx AND partition_idx=xxxx;
  obclient> SELECT * FROM __all_virtual_election_info WHERE table_id=xxx AND partition_idx=xxxx;
  

• 如果无法查询内部表，可以通过 partition_key 搜索 observer.log 日志，如果有 Clog 日志打印的 ERROR 日志中包含 reconfirm、leader_active_need_swtich 等关键词，也表示有分区无主。

  [admin@hostname log]$ grep '{tid:xxxxxxxxxxxxxxx, partition_id:x, part_cnt:x}' observer.log
  

• 通过 partition_key 搜索 election.log 日志，如果出现 ERROR 级别的 leader_revoke 信息，表示有 Leader 卸任，此时有分区无主。

  [admin@hostname log]$ grep '{tid:xxxxxxxxxxxxxxxx, partition_id:x, part_cnt:x}' election.log
  

无主问题排查步骤

如果通过上述步骤发现存在分区无主，则按以下步骤排查无主的原因。

1. 查询 observer.log 日志，检索 ERROR 信息是否包含内存分配失败、磁盘已满等明显错误。

   [admin@hostname log]$ grep ERROR observer.log
   

2. 检查时钟偏差。

   如果环境中没有 NTP 服务器或 NTP 服务器不稳定，可能导致 OceanBase 数据库出现无主的情况。通过以下命令检查是否存在时钟偏差，其中 $IP 表示各 OBServer 的 IP 地址。

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

   [root@hostname home]# clockdiff $IP
   

3. 检查是否有租户、表或分区被删除。

   租户被删除时，多个副本的删除时机可能不一致，如果 Leader 副本最后被删除，则会由于收不到投票而连任失败，进而在租约过期时会出现无主的错误。 这种情况的典型日志如下所示。

   ipayus001-[  election.log  [2019-03-05 00:13:28.061153] ERROR [ELECT] run_gt1_task (ob_election.cpp:1477) [1870][Y0-0000000000000000] [log=50]leader_revoke, please attention!(election={partition:{tid:1111606255681671, partition_id:0, part_cnt:0}, is_running:true, is_offline:false, is_changing_leader:false, self:"xxx.xxx.xxx.xxx:2882", proposal_leader:"xxx.xxx.xxx.xxx", cur_leader:"xxx.xxx.xxx.xxx", curr_candidates:3{server:"xxx.xxx.xxx.xxx:2882", timestamp:1550489755142437, flag:0}{server:"xxx.xxx.xxx.xxx:2882", timestamp:1550489755142437, flag:0}{server:"xxx.xxx.xxx.xxx:2882", timestamp:1550489755142437, flag:0}, curr_membership_version:1551693618713066, leader_lease:[0, 0], election_time_offset:60000, active_timestamp:1551275100257609, T1_timestamp:1551773608000000, leader_epoch:1551693701600000, state:0, role:0, stage:1, type:-1, replica_num:3, unconfirmed_leader:"xxx.xxx.xxx.xxx:2882", takeover_t1_timestamp:1551773596800000, is_need_query:false, valid_candidates:0, cluster_version:4295229513, change_leader_timestamp:0, ignore_log:false, leader_revoke_timestamp:1551773608001085, vote_period:4, lease_time:9800000})
   

   这种情况下，可以通过日志中的 table_id 检查该分区对应的表的状态，如果表已被删除，则可以忽略该错误。

   obclient> SELECT * FROM __all_meta_table WHERE table_id=xxx;
   obclient> SELECT * FROM __all_virtual_meta_table WHERE table_id=xxx;
   

   说明

   删除租户、表或分区导致的无主错误仅出现在 OceanBase 数据库 V2.1.x 及以前的版本。

4. 排查多数派副本是否宕机。

   如果有副本宕机，正常副本无法凑够多数派，就会导致无主。

   可以在所有副本上通过 partition_key 与 leader lease is expired 搜索 election.log 日志，典型日志如下所示。

   election.log  [2018-09-27 23:09:04.950617] ERROR [ELECT] run_gt1_task (ob_election.cpp:1425) [38589][Y0-0000000000000000] [log=25]leader lease is expired(election={partition:{tid:1100611139458321, partition_id:710, part_cnt:0}, is_running:true, is_offline:false, is_changing_leader:false, self:"xxx.xxx.xxx.xxx:2882", proposal_leader:"xxx.xxx.xxx.xxx", cur_leader:"xxx.xxx.xxx.xxx", curr_candidates:3{server:"xxx.xxx.xxx.xxx:2882", timestamp:1538050146803352, flag:0}{server:"xxx.xxx.xxx.xxx:2882", timestamp:1538050146803352, flag:0}{server:"xxx.xxx.xxx.xxx:2882", timestamp:1538050146803352, flag:0}, curr_membership_version:0, leader_lease:[0, 0], election_time_offset:350000, active_timestamp:1538050146456812, T1_timestamp:1538069944600000, leader_epoch:1538050145800000, state:0, role:0, stage:1, type:-1, replica_num:3, unconfirmed_leader:"xxx.xxx.xxx.xxx:2882", takeover_t1_timestamp:1538069933400000, is_need_query:false, valid_candidates:0, cluster_version:4295229511, change_leader_timestamp:0, ignore_log:false, leader_revoke_timestamp:1538069944600553, vote_period:4, lease_time:9800000}, old_leader="xxx.xxx.xxx.xxx:2882")
   

   检查各 curr_candidates 中的各个 OBServer 是否宕机，如果处于正常状态的副本不满足多数派，则无主的情况是符合预期的。但此时需要判断 observer 进程是否处于宕机重启扫盘阶段，可以通过以下方式搜索 observer.log 日志，如果存在该日志说明扫盘还未完成，副本处于 REPLAY 状态（即选举模块还未开始工作）。

   其中 estimated_rest_time 表示预计扫盘完成所需时间，可以等待 REPLAY 完成后再检查是否仍存在无主的情况。

   [2018-08-21 16:46:00.595078] INFO  [CLOG] ob_log_scanner_v1.cpp:733 [119159][Y0-0000000000000000] [lt=16] [dc=0] scan process bar(clog)(param={file_id:57968, offset:48, partition_key:{tid:18446744073709551615, partition_id:-1, part_idx:268435455, subpart_idx:268435455}, log_id:18446744073709551615, read_len:0, timeout:10000000}, header={magic:17746, version:1, type:201, partition_key:{tid:1110506744103794, partition_id:0, part_cnt:0}, log_id:686524944, data_len:459, generation_timestamp:1534820857671385, epoch_id:1534819616115213, proposal_id:{time_to_usec:1534819616115213, server:"xxx.xxx.xxx.xxx:44433"}, submit_timestamp:1534820857670904, is_batch_committed:false, data_checksum:1992526323, active_memstore_version:"0-0-0", header_checksum:2540895702}, total_clog_file_cnt=4615, rest_clog_file_cnt=1648, estimated_rest_time(second)=455)
   

5. 判断是否存在网络问题。

   如果多数派副本进程都在，未发生宕机重启，且 election.log 日志中存在 leader lease is expired 信息，说明 Leader 连任失败，这种情况可能是由于发生网络故障（单向或双向网络隔离、RPC请求积压等）。

   1. 检查是否存在网络隔离。

      首先利用如下命令检查各个副本所在机器上的 iptables，查看是否主动阻塞了网络。

      [admin@hostname ~]$ sudo iptables -L
      

      如果 Follower 与 Leader 间的网络被阻塞，导致 Leader 与多数派（包含自身）网络无法联通，则无主也是符合预期的，此时需要调整网络状况。

   2. 检查是否存在请求积压。

      选举模块需要利用 RPC 收发消息来执行选主、连任，如果 RPC 层出现异常导致选举消息无法按时送达/处理，那么也可能引起无主，通过如下步骤可以排查是否发生了该问题：

      1. 某个副本日志中存在 leader lease is expired 信息时，首先检查该副本的 RPC 是否工作正常：

         • 通过以下命令搜索 observer.log，查看 request doing 值是否过大，如果达到千级别说明 RPC 消息有明显的积压，需要继续排查网络是否异常。

           [admin@hostname log]$ grep 'RPC EASY STAT' observer.log
           

         • 通过以下命令搜索 observer.log，查看 500 租户请求队列的 total_size 值是否过大（通常如果该值为几千则认为过大）。如果 total_size 的值过大，则表示 500 租户存在请求积压，导致 Clog 模块发出的请求得不到处理。

           [admin@hostname log]$ grep 'dump tenant info' observer.log
           

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

      3. 如果本机与 Leader 的 RPC 均正常，且 Leader 所在的 OBServer 的 election.log 日志中存在 leader lease is expired 信息 ，则可能是集群中其他副本发生了异常，导致 Leader 连任无法收到多数派的投票，从而连任失败。

   3. 检查 RPC 延迟。

      1. 通过 tsar 或 vsar 命令确认 Leader 所在机器的网络在卸任时间附近是否有异常，观察重传率、带宽值。典型的网络重传率高的 tsar 命令执行结果如下图所示。

         

      2. 如果 tsar 执行结果无明显异常，通过以下命令 election.log 日志，如果存在内容也说明选举的消息存在延迟。

         [admin@hostname log]$ grep 'message not in time' election.log
         

         如果上述日志具有内容，继续搜索 observer.log 日志，检查是否存在 RPC 相关的异常。

         如果以下命令也存在内容，请联系 OceanBase 技术支持。

          [admin@hostname log]$ grep 'packet fly cost too much'  observer.log
         

6. 检查是否存在 Clog 再确认失败。

   如果选举模块工作正常，并已经通过选举协议选出了 Leader，但 Clog 模块在再确认阶段失败，会导致选举出的 Leader 卸任。 这种情况可以通过搜索 election.log 日志中是否包含 take the initiative leader revoke 信息进行排查，典型日志如下所示。

   [2018-09-20 04:09:46.236304] INFO  [ELECT] leader_revoke (ob_election_mgr.cpp:296) [39144][Y0-0000000000000000] [log=25]take the initiative leader revoke(partition={tid:1101710651081570, partition_id:0, part_cnt:0})
   

7. 判断是否为 Load 值过高引起的无主。 可以通过 tsar -i1 检查对应时间点的 Load 值是否正常，如果该值非常高，可能导致 election 模块无主。

   [root@hostname home]# tsar -i1
   

   也可以通过以下命令搜索 election.log 日志判断 Load 值是否过高从而引起无主。

   [admin@hostname log]$ grep 'run time out of range' election.log
   

8. 判断是否为 Clog 盘满。 对于分区数多、写入压力大的数据库集群，如果转储慢、或者租户 Unit 规格异构，那么可能导致部分副本的 Clog 回收不及时，从而导致盘空间达到 95%，此时 observer 进程会自动停止写 Clog，从而导致这台机器上有大量副本不同步，从而导致无主。 您可以通过在服务器上执行 df -h 查看当前 Clog 盘的空间使用占比，如果 Use% 列达到了 clog_disk_usage_limit_percentage 设置的阈值，则需要进行处理。

   [root@hostname /]# df -h
   ...
   /dev/mapper/vglog-ob_log       196G   177G  9G  95% /observer/clog
   ...
   

   有关 Clog 盘满的解决方式，请参见 Clog 盘满问题运维处理方法。