--- title: "物理恢复失败 - OceanBase 数据库 V4.2.1 | OceanBase 文档中心" description: 物理恢复失败 本节主要介绍物理恢复失败时问题的排查及定位方法。 物理恢复功能对数据备份和日志归档功能具有强依赖，即发起物理恢复前，需要保证至少存在一个可用的备份集，且日志归档连续。 注意 OceanBase 数据库当前仅支持将低版本的备份数据恢复到同版本或高版本中，但不支持将 V3.x 或 V2.x 版本的备份数据恢… image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - 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/900.backup-and-recovery/200.physical-restore-failed.md) 本节主要介绍物理恢复失败时问题的排查及定位方法。 物理恢复功能对数据备份和日志归档功能具有强依赖，即发起物理恢复前，需要保证至少存在一个可用的备份集，且日志归档连续。 #### 注意 - OceanBase 数据库当前仅支持将低版本的备份数据恢复到同版本或高版本中，但不支持将 V3.x 或 V2.x 版本的备份数据恢复到 V4.x 版本中。 - 对于 OceanBase 数据库 V4.1.0 版本，不支持恢复 OceanBase 数据库 V4.1.0 之前版本的数据。例如，OceanBase 数据库 V4.0.x 版本的备份数据不能恢复到 OceanBase 数据库 V4.1.0 版本中。 本文档中以 OceanBase 数据库的安装目录为 `/home/admin/oceanbase` 为例提供排查指导，文档中涉及的日志的实际存放路径请以实际环境为主。 ## 问题一：执行恢复命令失败 执行 `ALTER SYSTEM RESTORE` 语句发起物理恢复时，命令执行失败，您可以通过以下步骤进行排查处理。 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 执行以下语句，确认报错的错误码。 ```sql SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module='physical_restore'; ``` 查询结果中，重点关注以下信息： - `result` 对应的值，即报错的错误码。 - `RS_SVR_IP` 的值，即 Root Service 所在机器的 IP。 3. 根据上一步获取到的 `RS_SVR_IP`，登录 Root Service 所在的机器，搜索 `rootservice.log` 日志，确认报错点。 1. 登录 Root Service 所在的机器。 2. 进入日志所在的目录。 ```shell cd /home/admin/oceanbase/log ``` 3. 执行以下命令，根据查询到的错误码搜索日志，找到报错点。 以上一步视图中查询到的 `result` 信息中的错误码为 `-4016` 为例，命令如下。 ```shell grep "ob_restore_util" rootservice.log | grep "ret=\-4016" ``` #### 注意 如果在 `rootservice.log` 中 `grep` 不到相关日志，可能是因为 `rootservice.log` 切了文件，可以执行 `grep "ob_restore_util" rootservice.log.* | grep "ret=\-4016"`。 此外，常见命令执行失败的报错信息为 `-4018 no enough log for restore.`。该问题通常是由于用户在执行 `ALTER SYSTEM RESTORE` 语句时所指定的恢复终点不正确导致，需要确认在该恢复终点之前是否存在可用的备份集和日志归档，即所选的恢复终点可能未在可恢复区间内，有关可恢复区间的详细说明，请参见 [物理恢复相关参数介绍](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000218386) 中的 **timestamp 与 scn 选取约束**。 4. 获取搜索到的日志报错信息后，联系技术支持人员协助处理。 ## 问题二：租户的恢复状态一直卡在 RESTORE_WAIT_LS 状态 执行 `ALTER SYSTEM RESTORE` 语句发起物理恢复后，查看视图 `CDB_OB_RESTORE_PROGRESS`，发现恢复任务的状态一直处在 `RESTORING` 状态。 您可以通过以下方法进行进一步的排查。 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 执行以下命令，查询恢复任务的具体状态。 ```sql SELECT * FROM oceanbase.__all_virtual_restore_job WHERE name = 'status' AND tenant_id = xxxx; ``` 根据查询结果，如果 `status` 的值为 `RESTORE_WAIT_LS`，则需要执行下一步，确认待恢复租户的日志流副本的恢复状态。 如果 `status` 的值不为 `RESTORE_WAIT_LS`，请参考本文档中 **问题三：Schema 刷新问题** 进行进一步的排查。 3. 执行以下语句，确认待恢复租户的日志流副本的恢复状态。 ```sql SELECT ls_id,svr_ip,svr_port,role,restore_status,zone FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id = xxxx; ``` 例如，查询示例如下： ```shell +-------+----------------+----------+------+----------------+------+ | ls_id | svr_ip | svr_port | role | restore_status | zone | +-------+----------------+----------+------+----------------+------+ | 1 | 100.xx.xx.xx | 5003 | 1 | 0 | z1 | | 1001 | 100.xx.xx.xx | 5003 | 1 | 0 | z1 | | 1002 | 100.xx.xx.xx | 5003 | 1 | 6 | z1 | +-------+----------------+----------+------+----------------+------+ 3 rows in set ``` 查询结果中，主要关注以下几列信息： - `role`：副本角色。`1` 表示 Leader 副本，负责从外部介质恢复数据；`2` 表示 Follower 副本，负责从 Leader 副本拉取恢复数据。 - `restore_status`：日志流副本的恢复状态，`0` 表示日志流副本恢复正常。 4. 如果查询到的日志流副本的 `restore_status` 值为 `6` 或者 `8`，由于处于 `6`或 `8` 状态的日志流主要进行日志和转储的恢复，该阶段优先考虑是日志的恢复问题。 #### 注意 由于从 V4.1.0 版本开始，OceanBase 数据库遵循所有恢复日志齐步走的策略，如果有日志流卡在 `6` 或者 `8`之前的状态，则可能会导致其他日志流的状态都卡在 `6` 不动。 1. 执行以下命令，确认日志是否已从归档目录恢复到目标租户。 ```sql SELECT count(1) FROM oceanbase.GV$OB_LOG_STAT WHERE tenant_id = xxxx AND end_scn < (SELECT recovery_until_scn FROM oceanbase.__all_virtual_tenant_info WHERE tenant_id = xxxx); ``` 语句中： - `end_scn`：表示最大可消费位点。 - `recovery_until_scn`：表示租户的恢复终点。 如果查询不为空，则表示有日志未从归档目录恢复到目标租户，您可以继续观察 `GV$OB_LOG_STAT` 视图中 `end_scn` 的值，如果 `end_scn` 仍然在推进，则继续等待；如果较长时间不再推进，请联系技术支持进行下一步处理。 #### 说明 日志从归档目录中恢复到租户的整个过程可能会耗费较长时间，该过程持续的时间长短主要取决于待恢复的日志量、归档介质的读取性能以及 OceanBase 数据库的压力等因素。 如果查询结果为空，则表示 `end_scn` 的值大于或等于 `recovery_until_scn` 的值，表示日志从归档目录恢复到租户中成功，需要进一步确认日志是否回放完成。 2. 确认日志是否回放完成。 首先，查看虚拟表 `__all_virtual_replay_stat`，确认是否有待回放的任务。 ```sql SELECT * FROM oceanbase.__all_virtual_replay_stat WHERE tenant_id = xxxx; ``` 查询结果中，重点关注以下几列的值： - `pending_cnt`：表示正在等待回放的任务数量。如果该值不为零，则表示有待回放的任务。 - `unsubmitted_log_scn`：表示未提交回放的位点。 再查看虚拟表 `__all_virtual_tenant_info` 获取 `recovery_until_scn` 的值。 ```sql SELECT recovery_until_scn FROM oceanbase.__all_virtual_tenant_info WHERE tenant_id = xxxx; ``` 根据两次的查询结果，如果 `pending_cnt` 的值为 `0`，并且 `unsubmitted_log_scn` 的值大于 `recovery_until_scn` 的值，则表示日志回放完成，需要进一步确认 1 号日志流是否恢复完成。 否则，只要有任一条件未满足，则表示回放未完成，可以继续观察 `unsubmitted_log_scn` 是否在推进。如果较长一段时间后，`unsubmitted_log_scn` 仍然未推进，请联系技术支持进行下一步处理。 3. 确认 1 号日志流是否恢复完成。 ```sql SELECT * FROM oceanbase.__all_ls_recovery_stat WHERE tenant_id = xxxx; ``` 查询结果中，比较 `sync_scn` 与 `recovery_until_scn` 的值，如果 1 号日志流中 `sync_scn` 的值等于 `recovery_until_scn`，则表示 1 号日志流恢复完成，否则，1 号日志流未恢复完成，联系技术支持进行下一步处理。 4. 如果确认整个日志恢复过程均已完成，`restore_status` 的值仍为 `6` 或 `8`，请联系技术支持进行下一步的处理。 ## 问题三：Schema 刷新问题 执行 `ALTER SYSTEM RESTORE` 语句发起物理恢复后，通过 **问题二：租户的恢复状态一直卡在 RESTORE_WAIT_LS 状态** 中的方法排查虚拟表 `__all_virtual_restore_job`，发现存在待恢复租户残留的记录，且该租户的恢复状态不处于 `RESTORE_WAIT_LS` 状态而是卡在其他状态，考虑可能是待恢复租户的 Schema 未刷新出来，导致系统修改租户状态为 Normal 失败。 您可以通过以下方法进行排查处理： 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 查询视图 `GV$OB_SERVER_SCHEMA_INFO`，确认 Schema 的刷新进度。 ```sql SELECT * FROM oceanbase.GV$OB_SERVER_SCHEMA_INFO WHERE tenant_id=xxxx; ``` 查询示例如下： ```shell +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+ | SVR_IP | SVR_PORT | TENANT_ID | REFRESHED_SCHEMA_VERSION | RECEIVED_SCHEMA_VERSION | SCHEMA_COUNT | SCHEMA_SIZE | MIN_SSTABLE_SCHEMA_VERSION | +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+ | xx.xx.xx.5 | 4000 | 1002 | 1 | 1 | 4 | 1086 | -1 | | xx.xx.xx.9 | 4002 | 1002 | 1 | 1 | 4 | 1086 | -1 | | xx.xx.xx.9 | 4001 | 1002 | 1 | 1 | 4 | 1086 | -1 | | xx.xx.xx.5 | 4005 | 1002 | 1 | 1 | 4 | 1086 | -1 | | xx.xx.xx.11 | 4004 | 1002 | 1 | 1 | 4 | 1086 | -1 | | xx.xx.xx.11 | 4003 | 1002 | 1 | 1 | 4 | 1086 | -1 | +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+ 6 rows in set ``` Schema 刷新成功需要满足以下条件： - `REFRESHED_SCHEMA_VERSION` = `RECEIVED_SCHEMA_VERSION` - `REFRESHED_SCHEMA_VERSION` 的值大于 8 - `REFRESHED_SCHEMA_VERSION/8` 的值为整数 只要以上任意一个条件不满足，就表示 Schema 未刷新出来，需要搜索日志继续排查。 3. 根据上一步视图中获取到的信息，选择任意一台 Schema 未刷新出来的机器登录后，搜索日志。 1. 进入日志所在目录。 ``` 2. 搜索日志以获取相关信息。 搜索日志时，直接按照线程名搜索即可。由于 Schema 刷新是后台线程，系统会一直重试，故只需查看最新的日志即可。 ```shell grep "SerScheQueue" observer.log ``` 搜索到的日志示例如下： ```javascript observer.log.20220811114045:[2022-08-11 11:39:54.382533] WARN [RPC.OBRPC] rpc_call (ob_rpc_proxy.ipp:361) [192069][SerScheQueue0][T0][YFA00BA2D905-0005E5DEE6A2294E-0-0] [lt=8] execute rpc fail(ret=-4012, dst="11.xx.xx.9:4001") observer.log.20220811114045:[2022-08-11 11:39:54.382552] WARN log_user_error_and_warn (ob_rpc_proxy.cpp:315) [192069][SerScheQueue0][T0][YFA00BA2D905-0005E5DEE6A2294E-0-0] [lt=20] ``` 根据搜索到的日志，找到对应的 trace 信息和执行失败的机器信息。例如，示例中的 trace 信息为 `YFA00BA2D905-0005E5DEE6A2294E-0-0`，执行失败的机器的 IP 地址为 `xx.xx.xx.9`。 4. 登录执行失败的机器，再根据获取到的 trace 信息，进入日志所在目录后，进一步搜索日志确认报错信息。 ```shell grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log ``` #### 注意 如果在 `observer.log` 中 `grep` 不到相关日志，可能是因为 `observer.log` 切了文件，可以执行 `grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log.*`。 5. 获取到日志报错信息后，联系技术支持人员协助处理。 ## 问题四：视图中恢复任务的状态为 FAILED 执行 `ALTER SYSTEM RESTORE` 语句发起物理恢复后，查看视图 `CDB_OB_RESTORE_HISTORY`，发现恢复任务的状态为 `FAILED`。 您可以参考以下步骤进行排查处理： 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 再次查询视图 `CDB_OB_RESTORE_HISTORY`，获取 `comment` 列的信息。 ```sql SELECT * FROM oceanbase.CDB_OB_RESTORE_HISTORY WHERE TENANT_ID=xxxx; ``` `comment` 列中展示了恢复任务相关的一些信息，包括 OBServer 节点的 IP、日志流 id、出错模块类型以及对应的 `trace_id`。 有关视图 `CDB_OB_RESTORE_HISTORY` 的详细介绍，请参见 [CDB_OB_RESTORE_HISTORY](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000219528)。 3. 根据获取到的错误码信息及 `trace_id`，搜索相应的日志。 1. 登录到 `comment` 信息中所指示的机器。 2. 进入日志所在目录。 ``` 3. 执行以下命令，搜索恢复任务失败时间点附近的日志。 - 如果执行该任务的机器类型是 OBServer 节点（`comment` 信息中显示为 `(server)`），则执行以下命令搜索恢复任务失败时间点附近的日志。 ```shell grep "trace_id" observer.log | grep "WARN\|ERROR" ``` 其中，`trace_id` 需要替换成 `comment` 列中的 `trace_id` 信息。 #### 注意 如果在 `observer.log` 中 `grep` 不到相关日志，可能是因为 `observer.log` 切了文件，可以 `grep "trace_id" observer.log.* | grep "WARN\|ERROR"`。 - 如果执行该任务的机器类型是 ROOT Service（`comment` 信息中显示为 `(rootservice)`），则执行以下命令搜索恢复任务失败时间点附近的日志。 ```shell grep "ob_restore_scheduler" rootservice.log | grep "WARN\|ERROR" ``` #### 注意 如果在 `rootservice.log` 中 `grep` 不到相关日志，可能是因为 `rootservice.log` 切了文件，可以 `grep "ob_restore_scheduler" rootservice.log.* | grep "WARN\|ERROR"`。 4. 获取到日志报错信息后，联系技术支持人员协助处理。 上一篇 下一篇 ![有帮助](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) 咨询热线