---
title: 未开启日志归档且 ls_gc_delay_time=0s 时手动 switchover 后新备租户会无法同步，日志打印 ls_fetch_log_ error(ret=-4233 的原因和解决办法-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 未开启日志归档且 ls_gc_delay_time=0s 时手动 switchover 后新备租户会无法同步，日志打印 ls_fetch_log_ error(ret=-4233 的原因和解决办法相关的常见问题和使用技巧，帮助您快速解决 未开启日志归档且 ls_gc_delay_time=0s 时手动 switchover 后新备租户会无法同步，日志打印 ls_fetch_log_ error(ret=-4233 的原因和解决办法的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

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

更新时间：2026-05-12 09:06

适用版本： V4.0.x、V4.1.x、V4.2.x 内容类型：Troubleshoot  

## 问题现象

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

![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/backup-and-restore/20241211lsgcdelaytime.png)

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

```shell
:[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。

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

      ```

      详情参见：[ls_gc_delay_time](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000035105)。

      #### 注意

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

上一篇

[OceanBase 数据库使用 NAS 作为备份介质，租户日志归档启动卡 BEGINNING 阶段，日志打印报错 -4009 Disk quota exceeded](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002998409)

下一篇

[日志归档异常导致日志流 GC 卡住的原因和解决办法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003271887) ![有帮助](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) 咨询热线