物理恢复过程中 OBServer 重启不成功

问题现象

物理恢复过程中 OBServer 重启不成功。 在 OBServer 的日志中有如下报错，表示在同一个日志流 1001 上看到了 2 个正在进行的 transfer 任务，不符合预期，导致 slog 回放卡住。

[2023-11-16 18:57:59.756993] WDIAG [STORAGE] record_ls_transfer_info (ob_tenant_checkpoint_slog_handler.cpp:704) [959][SvrStartupHandl][T1006][Y0-0000000000000000-0-0] [lt=18][errcode=-4016] The transfer_info of different tablet records on the same ls is different(ret=-4016, ls_id={id:1001}, tablet_id={id:274977}, tablet_transfer_info={ls_id:{id:1003}, transfer_start_scn:{val:1699972263981975314, v:0}, transfer_seq:1, has_transfer_table:true}, ls_startup_transfer_info={ls_id:{id:1003}, transfer_start_scn:{val:1699972084910548450, v:0

问题原因

物理恢复过程中，日志的恢复分成 2 个阶段，例如，指定恢复到 12:00，那么所有的日志流先将日志恢复到 10:00，等所有日志流的日志都恢复到 10:00 后，再恢复日志到 12:00。阶段 2 中，一个日志流上的多个 transfer 任务会严格保证顺序串行回放，而阶段 1 中，是没有这个限制，即允许多个 transfer 任务并行回放。在日志恢复处于阶段 1，但源端日志流副本已经完成阶段 1 的日志恢复后发生迁移，迁移过程中日志恢复进入阶段 2，但迁移目标端日志流在迁移结束时还误认为自己处于阶段 1，造成目标端日志流上存在多个正在进行的 transfer 任务。然后在重启过程中，目标端日志流被检查到存在这种异常情况，导致重启不成功。

问题的风险及影响

OBServer 重启不成功，该节点无法提供服务。

影响版本

OceanBase 数据库 V4.2.1 BP2 之前版本。

解决方法及规避方式

• 迁移完成后，若发现处于 WAIT_RESTORE_TO_CONSISTENT_SCN 阶段，不能跳过 transfer table 检查。

  若发生该错误，只能踢掉该节点，再重新加进来。若发生多数派错误，需要联系 OceanBase 技术支持进行处理。

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V4.2.1 BP2、V4.2.2、V4.3.0 及之后版本。