首批通过分布式安全可靠测评，为关键业务系统打造
划线反馈
备集群合并超时的原因和解决方法
更新时间：2026-06-12 08:51
分享
适用版本：V3.1.x、V3.2.x内容类型：Troubleshoot
问题现象
当集群有一主多备时，有的备集群可能会合并超时，__all_zone 里字段 INFO 显示 TIMEOUT。
关键日志信息。
[2024-08-09 12:31:20.479969] WARN [STORAGE] build_merge_ctx (ob_partition_storage.cpp:4957) [1231068][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=15] [dc=0] Fail to get schemas to merge, (ret=-5627, pkey={tid:1113805278937234, partition_id:0, part_cnt:0}, ctx={param:{merge_type:2, merge_version:"0-0-0", pkey:{tid:1113805278937234, partition_id:0, part_cnt:0}, index_id:1113805278937234, schedule_merge_type:2, pg_key:{tid:1113805278937234, partition_id:0, part_cnt:0}}, sstable_version_range:{multi_version_start:1723035610916353, base_version:1723018584334367, snapshot_version:1723035616403405}, create_snapshot_version:0, base_schema_version:1710961371452680, schema_version:1710961371452680, dump_memtable_timestamp:1723023204887261, table_schema:null, is_full_merge:false, stat_sampling_ratio:0, merge_level:0, progressive_merge_num:0, progressive_merge_start_version:0, parallel_merge_ctx:{parallel_type:4, range_array:[], first_sstable:null, concurrent_cnt:0, is_inited:false}, checksum_method:0, result_code:0, data_table_schema:null, mv_dep_table_schema:null, index_stats:[], tables_handle count:1, index_stats:[], is_in_progressive_new_checksum:false, store_column_checksum_in_micro:false, progressive_merge_round:0, progressive_merge_step:0, use_new_progressive:false, tables_handle:{table_count:1, [{i:0, table_key:{table_type:0, pkey:{tid:1113805278937234, partition_id:0, part_cnt:0}, table_id:1113805278937234, trans_version_range:{multi_version_start:1723018584334367, base_version:1723018584334367, snapshot_version:1723035616403405}, log_ts_range:{start_log_ts:1723018584334367, end_log_ts:1723035616403405, max_log_ts:1723035616403405}, version:"0-0-0"}, ref:3}]}, base_table_handle:{table_:null, table_:null}, create_sstable_for_large_snapshot:false, logical_data_version:0, log_ts_range:{start_log_ts:1723018584334367, end_log_ts:1723035616403405, max_log_ts:1723035616403405}, merge_log_ts:2147483647, trans_table_end_log_ts:1723122019248680, trans_table_timestamp:1723122035887420, pg_last_replay_log_ts:1723018584334367, read_base_version:0})
问题原因
备库合并指定系统租户的 schema_version > 本备库系统租户的 schema_version > 主库系统租户的 schema_version。
备库合并指定的 schema_version 对应的 schema 获取不到导致备库合并卡住。
备库合并指定系统租户的 schema_version 较大的原因是集群里有一主两备。
假设主库为 A，一个备库为 B，合并被卡住备库为 C。对应每个集群系统租户的 schema_version分别是 S1、S2、S3，已知 S2 大于 S1，S3 小于 S2，S1 和 S3 的大小没有关系。
备集群 C 在构建的时候，创建副本完成的时候需要同步 clog，这个 clog 有可能是从 A 集群同步过来的，也有可能是从 B 集群同步过来的。从不同的集群同步过来，就带来了不同集群的 schema_version，这个 C 集群应该是从 B 集群同步的 clog，导致底层在合并的时候指定了一个大于本集群的 schema_version。
问题的风险及影响
备集群合并超时。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
适用版本
OceanBase 数据库 V3.x 版本。
解决方法
在主库系统租户上执行一个不影响业务性能的 DDL，将主库 SYS 租户的 schema version 推高。等备库同步到这个 schema_version 即可。
