--- title: OceanBase 数据库无主状态的排查方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于OceanBase 数据库无主状态的排查方法相关的常见问题和使用技巧，帮助您快速解决OceanBase 数据库无主状态的排查方法的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # OceanBase 数据库无主状态的排查方法 更新时间：2026-06-12 04:01 适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot 介绍如何确认无主，以及造成无主的原因的排查方法。 ## 适用版本 OceanBase 数据库所有版本 ## 确认无主状态 对于容灾场景的测试过程中，经常会出现无主的情况，Election 模块的正常工作依赖于集群多数派副本进程正常且多数派与 Leader 间的网络连通。可以搜索 `election.log` 日志查看当前是否有副本无主。 ```unknow [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` 为空，也表示无主。 ```unknow 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` 等关键词，也表示有分区无主。 ```unknow [admin@hostname log]$ grep '{tid:xxxxxxxxxxxxxxx, partition_id:x, part_cnt:x}' observer.log ``` - 通过 `partition_key` 搜索 `election.log` 日志，如果出现 ERROR 级别的 `leader_revoke` 信息，表示有 Leader 卸任，此时有分区无主。 ```unknow [admin@hostname log]$ grep '{tid:xxxxxxxxxxxxxxxx, partition_id:x, part_cnt:x}' election.log ``` ## 无主问题排查步骤 如果通过上述步骤发现存在分区无主，则按以下步骤排查无主的原因。 1. 查询 `observer.log` 日志，检索 `ERROR` 信息是否包含内存分配失败、磁盘已满等明显错误。 ```unknow [admin@hostname log]$ grep ERROR observer.log ``` 2. 检查时钟偏差。 如果环境中没有 NTP 服务器或 NTP 服务器不稳定，可能导致 OceanBase 数据库出现无主的情况。通过以下命令检查是否存在时钟偏差，其中 `$IP` 表示各 OBServer 的 IP 地址。 如果结果显示的 `delta` 值超过 `200 ms`，则需要检查 NTP 服务器是否正常。 ```unknow [root@hostname home]# clockdiff $IP ``` 3. 检查是否有租户、表或分区被删除。 租户被删除时，多个副本的删除时机可能不一致，如果 Leader 副本最后被删除，则会由于收不到投票而连任失败，进而在租约过期时会出现无主的错误。 这种情况的典型日志如下所示。 ```unknow 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` 检查该分区对应的表的状态，如果表已被删除，则可以忽略该错误。 ```unknow 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` 日志，典型日志如下所示。 ```unknow 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 完成后再检查是否仍存在无主的情况。 ```unknow [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`，查看是否主动阻塞了网络。 ```unknow [admin@hostname ~]$ sudo iptables -L ``` 如果 Follower 与 Leader 间的网络被阻塞，导致 Leader 与多数派（包含自身）网络无法联通，则无主也是符合预期的，此时需要调整网络状况。 2. 检查是否存在请求积压。 选举模块需要利用 RPC 收发消息来执行选主、连任，如果 RPC 层出现异常导致选举消息无法按时送达/处理，那么也可能引起无主，通过如下步骤可以排查是否发生了该问题： 1. 某个副本日志中存在 `leader lease is expired` 信息时，首先检查该副本的 RPC 是否工作正常： - 通过以下命令搜索 `observer.log`，查看 `request doing` 值是否过大，如果达到千级别说明 RPC 消息有明显的积压，需要继续排查网络是否异常。 ```unknow [admin@hostname log]$ grep 'RPC EASY STAT' observer.log ``` - 通过以下命令搜索 `observer.log`，查看 500 租户请求队列的 `total_size` 值是否过大（通常如果该值为几千则认为过大）。如果 `total_size` 的值过大，则表示 500 租户存在请求积压，导致 Clog 模块发出的请求得不到处理。 ```unknow [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` 命令执行结果如下图所示。 ![tsar](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/7812712261/p278218.png) 2. 如果 `tsar` 执行结果无明显异常，通过以下命令 `election.log` 日志，如果存在内容也说明选举的消息存在延迟。 ```unknow [admin@hostname log]$ grep 'message not in time' election.log ``` 如果上述日志具有内容，继续搜索 `observer.log` 日志，检查是否存在 RPC 相关的异常。 如果以下命令也存在内容，请联系 OceanBase 技术支持。 ```unknow [admin@hostname log]$ grep 'packet fly cost too much' observer.log ``` 6. 检查是否存在 Clog 再确认失败。 如果选举模块工作正常，并已经通过选举协议选出了 Leader，但 Clog 模块在再确认阶段失败，会导致选举出的 Leader 卸任。 这种情况可以通过搜索 `election.log` 日志中是否包含 `take the initiative leader revoke` 信息进行排查，典型日志如下所示。 ```unknow [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 模块无主。 ```unknow [root@hostname home]# tsar -i1 ``` 也可以通过以下命令搜索 `election.log` 日志判断 Load 值是否过高从而引起无主。 ```unknow [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` 设置的阈值，则需要进行处理。 ```unknow [root@hostname /]# df -h ... /dev/mapper/vglog-ob_log 196G 177G 9G 95% /observer/clog ... ``` 有关 Clog 盘满的解决方式，请参见 [Clog 盘满问题运维处理方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000129)。 上一篇 [OBServer 日志中关于分区无主的信息](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207762) 下一篇 [clog 上任超时导致无主](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207763) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线