首批通过分布式安全可靠测评,为关键业务系统打造
OceanBase 数据库 V2.x/V3.x 版本因为冻结版本号信息被回收导致合并超时失败
更新时间:2026-06-12 08:51
问题现象
在 1F-1F-1F 三副本 OceanBase 集群中,将其中一台很久没上线的 OBServer 服务器拉起启动后,集群的每日合并超时失败了,如下图所示:

问题排查
Step 1)首先通过下面的 SQL 找到当前 RootService leader 所在的节点。
MySQL [oceanbase]> select * from __all_server where with_rootserver=1;Step 2)在 RootService Leader 节点上搜索合并失败的相关日志。
[root@ob3_04 log]# grep "replica not merged to version" rootservice.log | tail -1 [2025-09-12 15:02:39.823108] INFO [RS] ob_partition_table_util.cpp:276 [82844][0][xxxxx-xxxxx-xxxxx-xxxxx-xxxxx] [lt=35] [dc=0] replica not merged to version(version=130, replica={table_id:{value:1100611139454812, first:1001, second:51036}, partition_id:0, partition_cnt:0, zone:"zone3", server:"xxx.xxx.xxx.7:2882", sql_port:2881, unit_id:1002, role:1, member_list:[{server:"xxx.xxx.xxx.7:2882", timestamp:1748344123013156}, {server:"xxx.xxx.xxx.147:2882", timestamp:1751597174314771}, {server:"xxx.xxx.xxx.190:2882", timestamp:1752476331400138}], row_count:0, data_size:0, data_version:92, data_checksum:0, row_checksum:row:[0], modify_time_us:1757578646656979, create_time_us:1748344123019356, member_time_us:1748344123013156, is_original_leader:false, in_member_list:true, rebuild:false, to_leader_time:1757578646647740, replica_status:"REPLICA_STATUS_NORMAL", replica_type:0, required_size:0, status:"REPLICA_STATUS_NORMAL", is_restore:0, partition_checksum:0, quorum:3, recovery_timestamp:0, fail_list:"", property:{memstore_percent_:100}, data_file_id:1746772635009349})Step 3)使用对应的 table_id 去合并版本号未能成功推上去的 svr_ip 上搜索相关的日志。
[root@ob3_02 log]# grep 1100611139454812 observer.log [2025-09-12 15:00:00.948956] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=7] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658593801826, snapshot_gc_ts_=1757660393801826, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:00:26.596501] WDIAG [STORAGE.COMPACTION] ob_partition_scheduler.cpp:2117 [52894][0][Y0-0000000000000000-0-0] [lt=10] [dc=0][errcode=0] Fail to schedule partition major merge(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, frozen_version="130-0-0", tmp_ret=-4018) [2025-09-12 15:00:30.950324] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=6] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658623961302, snapshot_gc_ts_=1757660423961302, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:01:00.951853] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=5] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658654122563, snapshot_gc_ts_=1757660454122563, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:01:27.020441] WDIAG [STORAGE.COMPACTION] ob_partition_scheduler.cpp:2117 [52894][0][Y0-0000000000000000-0-0] [lt=5] [dc=0][errcode=0] Fail to schedule partition major merge(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, frozen_version="130-0-0", tmp_ret=-4018) [2025-09-12 15:01:30.950081] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=5] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658684289858, snapshot_gc_ts_=1757660484289858, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:01:57.225291] WDIAG [STORAGE.COMPACTION] ob_partition_scheduler.cpp:2117 [52894][0][Y0-0000000000000000-0-0] [lt=6] [dc=0][errcode=0] Fail to schedule partition major merge(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, frozen_version="130-0-0", tmp_ret=-4018) [2025-09-12 15:02:00.953876] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=5] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658714440653, snapshot_gc_ts_=1757660514440653, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:02:30.951421] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=2] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658744595076, snapshot_gc_ts_=1757660544595076, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:03:00.952703] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=5] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658774754977, snapshot_gc_ts_=1757660574754977, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0}) [2025-09-12 15:03:30.951628] INFO [STORAGE] ob_freeze_info_snapshot_mgr.cpp:578 [53788][0][Y0-0000000000000000-0-0] [lt=22] [dc=0] min reserved snapshot(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, snapshot_version=1757658804911717, snapshot_gc_ts_=1757660604911717, duration=1800, merged_version=92, freeze_info={freeze_version:-1, freeze_ts:9223372036854775807, cluster_version:0})这边的 -4018 报错含义如下:
OceanBase Error Code: OB_ENTRY_NOT_EXIST(-4018) Message: Entry not exist Cause: Internal Error Solution: Contact OceanBase Support 错误原因:对应的对象不存在/找不到/没找到根据报错信息初步怀疑相关版本的
freeze info是不是已经找不到了。Step 4)使用下面的 SQL 查询 OceanBase 数据库 V2.x/V3.x 版本合并时需要的冻结版本号信息。
按租户 id、已经合并完成的数据版本号统计当前集群所有租户的所有分区副本的数据版本信息:
MySQL [oceanbase]> select count(*),tenant_id,data_version from __all_virtual_meta_table where zone='zone3' group by tenant_id,data_version; +----------+-----------+--------------+ | count(*) | tenant_id | data_version | +----------+-----------+--------------+ | 941 | 1001 | 92 | | 3267 | 1001 | 130 | | 1099 | 1002 | 92 | | 3218 | 1002 | 130 | +----------+-----------+--------------+ 4 rows in set (0.09 sec)查看冻结版本号元数据信息:
MySQL [oceanbase]> select * from __all_virtual_freeze_info; +----------------+------------------+----------------+ | frozen_version | frozen_timestamp | schema_version | +----------------+------------------+----------------+ | 94 | 1754676010665921 | NULL | | 95 | 1754762410671614 | NULL | | 96 | 1754848810690499 | NULL | | 97 | 1754935210829161 | NULL | | 98 | 1755021610061386 | NULL | | 99 | 1755108010553212 | NULL | | 100 | 1755194410167582 | NULL | | 101 | 1755280810797976 | NULL | | 102 | 1755367210288149 | NULL | | 103 | 1755453610894292 | NULL | | 104 | 1755540010417340 | NULL | | 105 | 1755626410951948 | NULL | | 106 | 1755712810572920 | NULL | | 107 | 1755799210398925 | NULL | | 108 | 1755885610317027 | NULL | | 109 | 1755972010888362 | NULL | | 110 | 1756058410338275 | NULL | | 111 | 1756144810926604 | NULL | | 112 | 1756231210556253 | NULL | | 113 | 1756317610111890 | NULL | | 114 | 1756404010887129 | NULL | | 115 | 1756490410794382 | NULL | | 116 | 1756576810597144 | NULL | | 117 | 1756663210214050 | NULL | | 118 | 1756749610982840 | NULL | | 119 | 1756836010609200 | NULL | | 120 | 1756922410203806 | NULL | | 121 | 1757008810048568 | NULL | | 122 | 1757095210924023 | NULL | | 123 | 1757181610696301 | NULL | | 124 | 1757268010384061 | NULL | | 125 | 1757354410250405 | NULL | | 126 | 1757383041003001 | NULL | | 127 | 1757399027257322 | NULL | | 128 | 1757409764204867 | NULL | | 129 | 1757495582830755 | NULL | | 130 | 1757578649876874 | NULL | +----------------+------------------+----------------+ 37 rows in set (0.00 sec)OceanBase 数据库 V2.x/V3.x 版本的合并依赖于
__all_virtual_freeze_info中的冻结版本号信息(OceanBase 数据库 V4.x 版本不再依赖这个__all_virtual_freeze_info内部表了),Zone 里面的副本做合并时冻结版本号只能一个版本一个版本地推高。这边因为frozen_version=93版本的freeze info已经被回收掉了,所以导致这些frozen_version=92版本的分区无法继续往上合并了,会遇到报错Fail to schedule partition major merge(pkey={tid:1100611139454812, partition_id:0, part_cnt:0}, frozen_version="130-0-0", tmp_ret=-4018)。
问题的风险及影响
集群每日合并失败,导致执行 alter table xxx drop column xxx; 失败报错 ORA-00600: internal error code, arguments: -4694, check drop column failed(报错原因:OceanBase 数据库 V2.x/V3.x 版本的集群在合并期间,不允许删除任何表的列)。
适用版本
OceanBase 数据库 V2.x/V3.x 版本。
解决方法
参考 OCP 官网文档,为该集群所有的业务租户及 sys 租户删除合并失败的 zone3 副本,然后再将 zone3 副本添加回去:
删除副本,详情参见:删除 Zone 中的租户副本。
添加副本,详情参见:新增副本。