未开启日志归档且 ls_gc_delay_time=0s 时手动 switchover 后新备租户会无法同步，日志打印 ls_fetch_log_ error(ret=-4233 的原因和解决办法

问题现象

手动使用命令行 switchover 后，新备租户一直无法同步（DBA_OB_TENANTS 的 SYNC_SCN 字段无变化），通过新备租户的 V$OB_LS_LOG_RESTORE_STATUS 表看到 ERR_CODE 字段报错 -4233，新主租户 observer.log 日志内打印 ls_fetch_log_ error(ret=-4233。

关键日志包含 ls_fetch_log_ error(ret=-4233 信息的完整日志如下。

:[2024-11-07 13:21:49.283847] WDIAG [CLOG.EXTLOG] do_fetch_log_ (ob_cdc_fetcher.cpp:308) [279867][T1074_L0_G13][T1074][xxxxx-xxxxx-xxxxx-xxxxx] [lt=19][errcode=-4233] ls_fetch_log_ error(ret=-4233, ret="OB_ERR_OUT_OF_LOWER_BOUND", ls_id={id:1005}, frt={rpc_id_:1730956909283693, rpc_start_tstamp_:1730956909283693, upper_limit_ts_:9223372036854775806, rpc_deadline_:1730956924283509, is_stopped_:false, stop_reason_:"NONE", fetch_status_:{is_reach_max_lsn:false, is_reach_upper_limit_ts:false, scan_round_count:0, l2s_net_time:0, svr_queue_time:0, log_fetch_time:0, ext_process_time:0}})

触发条件

网络备库没有开归档且没有设置 ls_gc_delay_time 且有缩容、transfer 等操作导致日志流删除。

问题原因

网络备库没有开归档且设置项 ls_gc_delay_time=0s 时，可能发生新主租户日志流回收导致新备租户无法拉取到日志，进而无法同步。当主备租户预期的日志流数量不同时，且手动执行 switchover，此问题会必定发生。

详细原因： 主备租户预期的日志流数量不同时，例如主租户是 3 副本 unit_num=1，备租户是单副本 unit_num=1，且主备租户 primary zone 的设置都是 random，此时主租户日志流数量是 1 * 3 = 3条，备租户预期的日志流数量是 1 * 1 = 1 条。 但实际上备租户的日志流数量等于主租户的日志流数量，所以备租户的日志流数量也是 3 条。switchover 后，新主租户日志流数量需要从实际上的 3 条调整为预期的 1 条，会尝试将多余的两条日志流删除回收，因为配置项 ls_gc_delay_time=0，所以会立即回收日志流。

手动设置新备租户的日志恢复源后，发现新主租户的日志流已经回收了，所需要的 clog 已经被删除，所以会尝试从归档中拉取 clog，但新备租户并没有开启归档，所以再也无法拉取到 clog，同步卡住。

使用 OCP 切换时不易发生此问题，是因为 OCP 设置新备租户的日志恢复源比手动设置更快，设置成功时新主租户的日志流还未回收，所以不会断流；而手动 switchover 时设置新备租户的日志恢复源比较慢，设置好后新主租户的日志流已经被回收，所以会有问题。

问题的风险及影响

备租户无法再同步，只能删除重新搭建。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 数据库 V4.x 版本。

解决方法及规避方式

• 解决方法：

  重建备租户。

• 规避方式：

  • 开启日志归档。

  • 设置 ls_gc_delay_time=3600s，默认值为 0s。

    ##-- 设置 ls_gc_delay_time 日志流延迟删除时间。
    ALTER SYSTEM SET ls_gc_delay_time='3600s';
    

    详情参见：ls_gc_delay_time。

    注意

    OceanBase 数据库 从 V4.2.1 BP1 版本开始默认值由 3600s 调整为 0s。