首批通过分布式安全可靠测评,为关键业务系统打造
Transfer 导致物理恢复完成后某些副本不可读
更新时间:2025-06-23 08:41
问题现象
物理恢复成功,但部分表读超时,报错如下:
obclient> select * from t2;
Timeout, query has reached the maximum query timeout: 10000000(us), maybe you can adjust the session variable ob_query_timeout or query_timeout hint, and try again.
在 OBServer 日志中可以看到如下报错:
[2023-11-10 06:44:53.432244] WDIAG [STORAGE] get_read_tables (ob_tablet.cpp:2417) [85516][T1004_L0_G0][T1004][Y13880BA1CCEC-000609BFCEAD8F2A-0-0] [lt=30][errcode=-6231] not allowed to read(ret=-6231, tablet_meta_={version:1, ls_id:{id:1004}, tablet_id:{id:200005}, data_tablet_id:{id:200005}, ref_tablet_id:{id:0}, has_next_tablet:false, create_scn:{val:18446744073709551615, v:3}, start_scn:{val:1, v:0}, clog_checkpoint_scn:{val:1699569534779141421, v:0}, ddl_checkpoint_scn:{val:1699569534779141421, v:0}, snapshot_version:1, multi_version_start:1, compat_mode:1, ha_status:{restore_status:4, data_status:0, expected_status:1, reserved:0}, report_status:{merge_snapshot_version:0, cur_report_version:0, data_checksum:0, row_count:0}, table_store_flag:{with_major_sstable:1}, ddl_start_scn:{val:0, v:0}, ddl_snapshot_version:0, max_sync_storage_schema_version:1699569409989760, max_serialized_medium_scn:0, ddl_execution_id:-1, ddl_data_format_version:0, ddl_commit_scn:{val:0, v:0}, mds_checkpoint_scn:{val:1699569535856867512, v:0}, transfer_info:{ls_id:{id:1001}, transfer_start_scn:{val:1699569534779141421, v:0}, transfer_seq:5, has_transfer_table:false}, create_schema_version:1699569409989760})
根据上面的日志可以得到出错 tablet 的 2 个重要信息:
data_tablet_id为 200005 的物理恢复状态restore_status是UNDEFINED,即 4。data_tablet_id为 200005 没有 major,所以无法提供读服务。
问题原因
后建日志流没有比较该日志流创建时间和 consistent scn 之间的大小关系,而是直接设置日志流的恢复状态是RESTORE_TO_CONSISTENT_SCN,而对 RESTORE_TO_CONSISTENT_SCN 阶段的 transfer 操作做了特殊处理。当物理恢复后才发现该日志流是 consistent scn 之后创建的,误将 transfer 的 tablet 标记成了需要从备份恢复转储。
问题的风险及影响
物理恢复成功,但部分副本没有 major,无法提供读服务。
影响版本
OceanBase 数据库 V4.2.1 BP2 之前版本。
解决方法及规避方式
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V4.2.1 BP2、V4.2.2、V4.3.0 及之后版本。