--- title: "物理备库同步过程中卡住 - OceanBase 数据库 V4.2.1 | OceanBase 文档中心" description: 物理备库同步过程中卡住 本文主要介绍物理备库在同步过程中出现日志同步卡住时问题的排查及定位方法。 问题一：未执行 RECOVER 命令、执行 RECOVER 命令恢复到指定终点或执行过 ALTER SYSTEM RECOVER xxx CANCEL 命令 问题现象 用户通过物理恢复的方式恢复出备租户后，未执行 REC… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.2.1 LTS # 物理备库同步过程中卡住 更新时间：2026-04-16 00:11:35 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.2.1/zh-CN/600.manage/1000.troubleshooting/800.physical-standby-database/100.physical-standby-database-synchrolock.md) 本文主要介绍物理备库在同步过程中出现日志同步卡住时问题的排查及定位方法。 ## 问题一：未执行 RECOVER 命令、执行 `RECOVER` 命令恢复到指定终点或执行过 `ALTER SYSTEM RECOVER xxx CANCEL` 命令 ### 问题现象 - 用户通过物理恢复的方式恢复出备租户后，未执行 `RECOVER` 命令更改新备租户的恢复终点，当日志流恢复到某个指定的终点，备租户的日志同步卡住。 - 用户通过物理恢复的方式恢复出备租户后，执行 `RECOVER` 命令到指定终点，当日志流恢复到某个指定的终点，备租户的日志同步卡住。 - 用户通过物理恢复的方式恢复出备租户，执行 `RECOVER` 命令后，又执行了 `ALTER SYSTEM RECOVER xxx CANCEL` 命令，当日志流恢复到某个指定的终点，备租户的日志同步卡住。 ### 问题原因 通常情况下，通过物理恢复的方式恢复出备租户后，如果不执行 `RECOVER` 命令或者执行 `RECOVER` 命令恢复到指定终点，备租户的日志同步就会停留在指定的恢复终点。此外，如果备租户执行 `RECOVER` 命令后，又执行了 `ALTER SYSTEM RECOVER xxx CANCEL` 命令，备租户的日志同步也会停留在某个恢复终点。 如下所示的示例中，租户 `restore_oracle_tenant` 的租户角色为 `STANDBY`，其同步进度卡在了某个固定时间点。造成该现象的原因是用户未执行 `RECOVER` 命令或执行 `RECOVER` 命令恢复到指定终点，又或者是执行 `RECOVER` 命令后又执行过 `ALTER SYSTEM RECOVER xxx CANCEL` 命令，当租户同步位点 `SYNC_SCN` 等于可恢复位点 `RECOVERY_UNTIL_SCN`，备租户无需再同步更多日志。 ```shell *************************** 1. row *************************** TENANT_ID: 1002 TENANT_NAME: restore_oracle_tenant TENANT_ROLE: STANDBY STATUS: NORMAL SWITCHOVER_STATUS: NORMAL SYNC_SCN: 1690425747241344851 REPLAYABLE_SCN: 1690425747241344851 READABLE_SCN: 1690425747241344851 RECOVERY_UNTIL_SCN: 1690425747241344851 1 row in set ``` ### 排查步骤 可以通过 `DBA_OB_TENANTS` 视图确认同步位点信息。 1. 租户管理员登录问题租户或问题租户所在集群的 `sys` 租户。 2. 根据租户的 `TENANT_ID` 或 `TENANT_NAME` 查询问题租户的基本状态信息，包括租户角色、同步位点等信息。 - 系统租户查看指定租户 ```sql SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS; ``` - 问题租户查询本租户 MySQL 模式 Oracle 模式 语句如下： ``` 语句如下： ```sql SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS; ``` 查询结果中，重点关注以下几列的值： - `TENANT_ROLE`：`STANDBY` 表示备租户；`PRIMARY` 表示主租户。 - `SYNC_SCN`：表示租户的同步位点。 - `REPLAYABLE_SCN`：表示租户的可回放位点，SCN 大于该位点的日志不能回放。 - `RECOVERY_UNTIL_SCN`：表示租户可恢复到的终点，如果值为 `4611686018427387903`，则表示恢复到无穷。 有关视图 `DBA_OB_TENANTS` 的更多说明，请参见 [DBA_OB_TENANTS](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220071)。 ## 问题二：租户未设置日志恢复源、日志恢复源为空或日志恢复源被损坏 ### 问题现象 - 使用 `BACKUP DATABASE PLUS ARCHIVELOG` 命令创建备租户后，未再设置日志恢复源或设置的日志恢复源为空，即 `ALTER SYSTEM SET log_restore_source = '';`。 - 备租户被清空过日志恢复源 - 主租户通过 Switchover 命令切换为备租户后，未设置日志恢复源 ### 问题原因 在 OceanBase 数据库中，备租户通过日志恢复源来拉取上游的日志。通过物理备份恢复（带日志）功能创建的备租户，用户在执行 `RECOVER` 命令后，默认会继续从恢复时指定的归档目录继续恢复日志；通过 `CREATE STANDBY TENANT` 命令创建的备租户，默认会通过网络直接从主租户处同步日志；而通过 `BACKUP DATABASE PLUS ARCHIVELOG` 命令创建的备租户未指定日志恢复源，无法直接开启日志持续同步。 此外，当备租户的日志恢复源为空，或者设置的日志恢复源被损坏时，同样会导致备租户卡住，例如，基于网络的物理备库其主租户被删除或者用于访问主租户的复制专用账号的密码被修改，基于归档的物理备库其用于恢复日志的归档目录被删除等。 ### 排查步骤 可以通过视图 `CDB_OB_LOG_RESTORE_SOURCE` 或 `DBA_OB_LOG_RESTORE_SOURCE` 来确认问题租户是否设置了日志恢复源。 1. 租户管理员登录问题租户或问题租户所在集群的 `sys` 租户。 2. 确认问题租户是否设置了日志恢复源。 ```sql SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE TENANT_ID=1xxx; ``` - 问题租户查看本租户 语句如下： ```sql SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE; ``` 语句如下： ```sql SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE; ``` - `TYPE`：如果值为 `LOCATION`，则表示当前租户通过归档日志从源端租户同步日志，即属于基于归档的物理备库；如果值为 `SERVICE`，则表示当前租户通过网络从主租户直接同步日志，即属于基于网络的物理备库。通过执行 `ALTER SYSTEM SET log_restore_source` 命令，可以切换备租户的日志同步源。 - `VALUE`：其值与 `TYPE` 的值对应，分别为源端租户的归档目录以及主租户的 Access Point。 如下所示的查询结果中，如果租户 `restore_oracle_tenant` 的日志恢复源查询结果为空，则表示该租户未设置日志恢复源，备租户的日志同步自然会卡住。如果查询结果的值为归档目录，则需要检查归档目录在主、备租户的所有机器上是否均可以访问；如果值为主租户的 Access Point，则需要确认 IP 列表、USER、PASSWORD 等是否均设置正确。 ```shell *************************** 1. row *************************** tenant_id: 1002 type: LOCATION value: file:///data/1 recovery_until_scn: 4611686018427387903 1 row in set ``` 有关视图 `CDB_OB_LOG_RESTORE_SOURCE` 和视图 `DBA_OB_LOG_RESTORE_SOURCE` 的更多说明，请参见 [CDB_OB_LOG_RESTORE_SOURCE](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219617) 和 [DBA_OB_LOG_RESTORE_SOURCE](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219411)。 ## 问题三：备库日志同步状态异常 ### 问题现象 在问题一和二都不存在的情况下，仍然出现备租户日志同步异常的情况。 ### 问题原因 日志同步过程中，可能由于主租户日志流回收、网络原因等造成备租户落后或者卡住的情况。 ### 排查步骤 视图 `V$OB_LS_LOG_RESTORE_STATUS` 汇总了所有日志流的同步状态，可以通过该视图来确认租户所有日志流的同步状态。 #### 注意 视图 `V$OB_LS_LOG_RESTORE_STATUS` 仅展示了日志流 Leader 的同步状态信息，因此，如果备租户出现日志流无主的情况，无法通过该视图查看，需要排查无主问题。 1. 租户管理员登录问题租户或问题租户所在集群的 `sys` 租户。 2. 查看问题租户所有日志流 Leader 的同步状态。 ```sql SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID=1xxx; 语句如下： ```sql SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS; ``` 语句如下： ```sql SELECT * FROM SYS.V$OB_LS_LOG_RESTORE_STATUS; ``` - `SYNC_SCN`：表示该日志流的同步位点。 - `SYNC_STATUS`：表示该日志流同步状态，其中，`NORMAL` 表示该日志流的日志同步状态正常，如果为其他状态则表示异常。日志同步状态及其含义如下表所示。 有关视图 `V$OB_LS_LOG_RESTORE_STATUS` 的更多说明，请参见 [V$OB_LS_LOG_RESTORE_STATUS](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219803)。 | 日志同步状态 | 含义 | | --- | --- | | NORMAL | 正常同步中 | | SOURCE HAS A GAP | 备租户与源端日志有 gap，主租户的日志未同步到备租户就已回收 | | STANDBY LOG NOT MATCH | 恢复日志与备租户冲突，可能是出现双 PRIMARY 或者日志恢复源设置错误 | | CHECK USER OR PASSWORD | 复制账户用户名或密码不对，无法访问原主租户 | | CHECK NETWORK | 主租户不可达，需要检查网络是否异常 | | RESTORE SUSPEND | 备租户已经恢复到指定位点 | | STANDBY NEED UPGRADE | 备租户的 Binary 版本落后，需要升级 | | PRIMARY TENANT DROPPED | 主租户已经被删除 | | FETCH LOG TIMEOUT | 同步日志超时，需要排查网络健康状况或者调大备租户日志同步超时的租户级配置项 `standby_db_fetch_log_rpc_timeout`，有关 standby_db_fetch_log_rpc_timeout 的详细说明请参见 [standby_db_fetch_log_rpc_timeout](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220360) | | STANDBY IN THROTTLING | 备租户写入限速中 | | STANDBY LOG DISK IS FULL | 备租户磁盘空间不足 | | WAIT LOG STREAM CREATED | 等待备租户创建日志流完成 | | NOT AVAILABLE | 其他异常导致的日志同步不可用 | ## 问题四：备租户同步位点推进卡住 ### 问题现象 当备租户未出现问题一、问题二、问题三等以上描述的所有问题，但是依然卡住，可以尝试分析是否是备租户同步位点推进卡住。 ### 问题原因 备租户在同步日志的过程中，遵循所有日志流齐步走的策略，因此每个日志流均会考虑租户的 `SYNC_SCN`，并且会基于一定的策略超前拉取日志。由于租户的 `SYNC_SCN` 不推进，会导致日志同步也停止，直到租户的 `SYNC_SCN` 恢复后才能重新开始日志同步。 ### 排查步骤 1. 租户管理员登录问题租户或问题租户所在集群的 `sys` 租户。 2. 通过视图 `DBA_OB_TENANTS` 查看租户的同步位点 `SYNC_SCN`。 可以根据租户的 `TENANT_ID` 或 `TENANT_NAME` 查询问题租户的 `SYNC_SCN`。 - 系统租户查看指定租户的 `SYNC_SCN` ``` - 问题租户查询本租户 `SYNC_SCN` 语句如下： ``` 语句如下： ``` - `TENANT_ROLE`：`STANDBY` 表示备租户；`PRIMARY` 表示主租户。 - `SYNC_SCN`：表示租户的同步位点。 3. 通过 `V$OB_LS_LOG_RESTORE_STATUS` 视图查询所有日志流 Leader 的 `SYNC_SCN`。 语句如下： ``` 语句如下： ``` 查询结果中，重点关注 `SYNC_SCN` 列，它表示日志流的同步位点。 根据两次的查询结果，比较所有日志流的 `SYNC_SCN` 与租户的 `SYNC_SCN`。如果所有日志流的 `SYNC_SCN` 均大于租户的 `SYNC_SCN` 并且没有变化，则表示租户的日志同步进度统计有问题，需要进一步排查租户日志同步进度统计的问题。 ## 问题五：备库有日志流无主 ### 问题现象 上述问题都排除后，备租户日志同步仍然卡住，可以尝试确认备租户的日志流是否发生无主。 ### 问题原因 备租户从主租户或者归档介质同步日志，都是由日志流 Leader 执行后，再同步给其他副本。如果备租户上有日志流无主，则该日志流无法同步日志，租户级 `SYNC_SCN` 的推进也会卡住，进而导致所有日志流的同步卡住。 ### 排查步骤 可以通过视图 `GV$OB_LOG_STAT` 来确认租户上是否有日志流无主。 1. 租户管理员登录问题租户或问题租户所在集群的 `sys` 租户。 2. 通过视图 `GV$OB_LOG_STAT` 查询租户的所有日志流的状态信息。 ```sql SELECT TENANT_ID, LS_ID, ROLE FROM oceanbase.GV$OB_LOG_STAT WHERE TENANT_ID=1xxx; 语句如下： ```sql SELECT TENANT_ID, LS_ID, ROLE FROM oceanbase.GV$OB_LOG_STAT; ``` 或者，也可以通过以下语句，直接查出所有无主的日志流。 ```sql SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE ROLE='LEADER'); ``` 语句如下： ```sql SELECT TENANT_ID, LS_ID, ROLE FROM SYS.GV$OB_LOG_STAT; ``` ```sql SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE ROLE='LEADER'); ``` 查询结果中： - `TENANT_ID`：表示租户 ID。 - `LS_ID`：表示日志流 ID。 - `ROLE`：表示日志流角色，`LEADER` 表示副本角色为主；`FOLLOWER` 表示副本角色为备。 如果日志流的所有副本均为 `FOLLOWER`，则表示该日志流无主。 或者，您也可以通过以下语句，直接查出所有无主的日志流。 语句如下： ``` 语句如下： ``` 有关视图 `GV$OB_LOG_STAT` 的更多说明，请参见 [GV$OB_LOG_STAT](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219870)。 根据查询结果，在确认备租户日志流均有主的情况下，可以使用相同的方法再确认主租户的日志流是否无主的问题，主租户的日志流无主也会间接导致备租户日志流同步卡住。 ## 问题六：主备租户的角色都是 `STANDBY` ### 问题现象 在无级联备库的场景中，主备关系的租户需要至少一个主租户（即租户角色为 `PRIMARY`），否则两个租户的日志同步进度会表现为不再推进。 ### 问题原因 在主租户上执行 Switchover 主切备后，原主备租户的角色都是 `STADNBY`，就会发生这种情况。 ### 排查步骤 可以通过 `DBA_OB_TENANTS` 视图分别查看主备租户的角色，确认主备租户的角色是否都是 `STANDBY`。 1. 租户管理员分别登录主备租户或主备租户所在集群的 `sys` 租户。 2. 分别执行以下语句，查询主备租户的角色。 - 系统租户查看主租户或备租户 ```sql SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM oceanbase.DBA_OB_TENANTS; ``` - 主租户或备租户查看本租户 语句如下： ``` 语句如下： ```sql SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM SYS.DBA_OB_TENANTS; ``` 查询结果中： - `TENANT_ID`：表示租户 ID。 - `TENANT_NAME`：表示租户名。 - `TENANT_ROLE`：表示租户角色。`PRIMARY` 表示主租户；`STANDBY` 表示备租户。 根据查询结果，确认是否出现主备租户的角色都是 `STANDBY` 的情况。 上一篇 下一篇 ![有帮助](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) 咨询热线