首批通过分布式安全可靠测评,为关键业务系统打造
OceanBase 数据库集群进行物理恢复时卡住,rootservice 日志出现 partition still restore clog or replica num is not enough,check it next round 异常的原因及解决方法
更新时间:2026-05-13 07:31
问题现象
OceanBase 数据库集群在进行物理恢复时,恢复副本的状态全部为 6,且各个节点副本数量不一致,部分节点的副本缺失,类似如下现象。
obclient[mysql]> select svr_ip,role, is_restore, count(*) from oceanbase.__all_virtual_meta_table as a, (select value from oceanbase.__all_restore_info where name='tenant_id') as b where a.tenant_id=b.value group by role, is_restore, svr_ip order by svr_ip, is_restore;
输出结果如下:
+---------------+------+------------+----------+
| svr_ip | role | is_restore | count(*) |
+---------------+------+------------+----------+
| xxx.x.xxx.166 | 2 | 6 | 10869 |
| xxx.x.xxx.167 | 4 | 6 | 16358 |
| xxx.x.xxx.228 | 2 | 6 | 16358 |
+---------------+------+------------+----------+
rootservice 日志伴随如下异常信息。
[2024-09-14 14:45:29.053861] WARN [RS.RESTORE] schedule_restore_task (ob_restore_scheduler.cpp:736) [70356][672][xxxxx-xxxxx-xxxxx-xxxxx] [lt=18] [dc=0] partition still restore clog or replica num is not enough, check it next round(ret=-4023, partition={schema_id:{value:1247945697605156, first:1135, second:79396}, partition_id:156, partition_cnt:0, schema_paxos_cnt:3, begin:44095, end:44097, table_cnt:1})
问题原因
OceanBase 数据库集群恢复的逻辑是先恢复数据再应用日志,数据恢复的逻辑是先恢复一个 Leader,然后由 Leader 通过副本复制的方式将副本复制到 Follower,出现该问题的原因一般是因为某些原因导致目标节点的副本复制无法正常进行。
问题的风险及影响
恢复作业长时间卡住。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
适用版本
OceanBase 数据库 V2.x、V3.x 版本。
解决方法及规避方式
需要排查副本复制是否存在异常,进行针对性解决。