--- title: 备集群合并超时的原因和解决方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于备集群合并超时的原因和解决方法相关的常见问题和使用技巧，帮助您快速解决备集群合并超时的原因和解决方法的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # 备集群合并超时的原因和解决方法 更新时间：2026-06-12 08:51 适用版本： V3.1.x、V3.2.x 内容类型：Troubleshoot ## 问题现象 当集群有一主多备时，有的备集群可能会合并超时，`__all_zone` 里字段 INFO 显示 TIMEOUT。 关键日志信息。 ```shell [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` 即可。 Previous [OceanBase 数据库 V4.2.1 BP7 版本转储报错 -4018 导致 clog 无法回收的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001939898) Next [OceanBase 数据库 V3.2.4 版本合并超时 OBServer 日志报错 -4024 advance buffer failed](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002345058) ![有帮助](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) 咨询热线