物理恢复失败

物理恢复失败

更新时间：2026-04-16 00:11:35

编辑

本节主要介绍物理恢复失败时问题的排查及定位方法。

物理恢复功能对数据备份和日志归档功能具有强依赖，即发起物理恢复前，需要保证至少存在一个可用的备份集，且日志归档连续。

注意

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 语句发起物理恢复时，命令执行失败，您可以通过以下步骤进行排查处理。

使用 root 用户登录集群的 sys 租户。
执行以下语句，确认报错的错误码。
```
SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module='physical_restore';
```
查询结果中，重点关注以下信息：
- result 对应的值，即报错的错误码。
- RS_SVR_IP 的值，即 Root Service 所在机器的 IP。
根据上一步获取到的 RS_SVR_IP，登录 Root Service 所在的机器，搜索 rootservice.log 日志，确认报错点。
1. 登录 Root Service 所在的机器。
2. 进入日志所在的目录。
```
cd /home/admin/oceanbase/log
```
3. 执行以下命令，根据查询到的错误码搜索日志，找到报错点。
  
  以上一步视图中查询到的 result 信息中的错误码为 -4016 为例，命令如下。
```
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 语句时所指定的恢复终点不正确导致，需要确认在该恢复终点之前是否存在可用的备份集和日志归档，即所选的恢复终点可能未在可恢复区间内，有关可恢复区间的详细说明，请参见物理恢复相关参数介绍中的 timestamp 与 scn 选取约束。
获取搜索到的日志报错信息后，联系技术支持人员协助处理。

问题二：租户的恢复状态一直卡在 RESTORE_WAIT_LS 状态

执行 ALTER SYSTEM RESTORE 语句发起物理恢复后，查看视图 CDB_OB_RESTORE_PROGRESS，发现恢复任务的状态一直处在 RESTORING 状态。

您可以通过以下方法进行进一步的排查。

使用 root 用户登录集群的 sys 租户。
执行以下命令，查询恢复任务的具体状态。
```
SELECT * FROM oceanbase.__all_virtual_restore_job WHERE name = 'status' AND tenant_id = xxxx;
```
根据查询结果，如果 status 的值为 RESTORE_WAIT_LS，则需要执行下一步，确认待恢复租户的日志流副本的恢复状态。

如果 status 的值不为 RESTORE_WAIT_LS，请参考本文档中 问题三：Schema 刷新问题 进行进一步的排查。

执行以下语句，确认待恢复租户的日志流副本的恢复状态。

SELECT ls_id,svr_ip,svr_port,role,restore_status,zone FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id = xxxx;

例如，查询示例如下：

+-------+----------------+----------+------+----------------+------+
| 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 表示日志流副本恢复正常。

如果查询到的日志流副本的 restore_status 值为 6 或者 8，由于处于 6或 8 状态的日志流主要进行日志和转储的恢复，该阶段优先考虑是日志的恢复问题。

注意

由于从 V4.1.0 版本开始，OceanBase 数据库遵循所有恢复日志齐步走的策略，如果有日志流卡在 6 或者 8之前的状态，则可能会导致其他日志流的状态都卡在 6 不动。
1. 执行以下命令，确认日志是否已从归档目录恢复到目标租户。
```
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，确认是否有待回放的任务。
```
SELECT * FROM oceanbase.__all_virtual_replay_stat WHERE tenant_id = xxxx;
```
  查询结果中，重点关注以下几列的值：
  - pending_cnt：表示正在等待回放的任务数量。如果该值不为零，则表示有待回放的任务。
  - unsubmitted_log_scn：表示未提交回放的位点。
  再查看虚拟表 __all_virtual_tenant_info 获取 recovery_until_scn 的值。
```
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 号日志流是否恢复完成。
```
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 失败。

您可以通过以下方法进行排查处理：

使用 root 用户登录集群的 sys 租户。

查询视图 GV$OB_SERVER_SCHEMA_INFO，确认 Schema 的刷新进度。

SELECT * FROM oceanbase.GV$OB_SERVER_SCHEMA_INFO WHERE tenant_id=xxxx;

查询示例如下：

+----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+
| 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 未刷新出来，需要搜索日志继续排查。

根据上一步视图中获取到的信息，选择任意一台 Schema 未刷新出来的机器登录后，搜索日志。
1. 进入日志所在目录。
```
cd /home/admin/oceanbase/log
```
2. 搜索日志以获取相关信息。
  
  搜索日志时，直接按照线程名搜索即可。由于 Schema 刷新是后台线程，系统会一直重试，故只需查看最新的日志即可。
```
grep "SerScheQueue" observer.log
```
  搜索到的日志示例如下：
```
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。
登录执行失败的机器，再根据获取到的 trace 信息，进入日志所在目录后，进一步搜索日志确认报错信息。
```
grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log
```
注意

如果在 observer.log 中 grep 不到相关日志，可能是因为 observer.log 切了文件，可以执行 grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log.*。
获取到日志报错信息后，联系技术支持人员协助处理。

问题四：视图中恢复任务的状态为 FAILED

执行 ALTER SYSTEM RESTORE 语句发起物理恢复后，查看视图 CDB_OB_RESTORE_HISTORY，发现恢复任务的状态为 FAILED。

您可以参考以下步骤进行排查处理：

使用 root 用户登录集群的 sys 租户。
再次查询视图 CDB_OB_RESTORE_HISTORY，获取 comment 列的信息。
```
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。
根据获取到的错误码信息及 trace_id，搜索相应的日志。
1. 登录到 comment 信息中所指示的机器。
2. 进入日志所在目录。
```
cd /home/admin/oceanbase/log
```
3. 执行以下命令，搜索恢复任务失败时间点附近的日志。
  - 如果执行该任务的机器类型是 OBServer 节点（comment 信息中显示为 (server)），则执行以下命令搜索恢复任务失败时间点附近的日志。
```
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)），则执行以下命令搜索恢复任务失败时间点附近的日志。
```
grep "ob_restore_scheduler" rootservice.log | grep "WARN\|ERROR" 
```
    注意
    
    如果在 rootservice.log 中 grep 不到相关日志，可能是因为 rootservice.log 切了文件，可以 grep "ob_restore_scheduler" rootservice.log.* | grep "WARN\|ERROR"。
获取到日志报错信息后，联系技术支持人员协助处理。

注意

问题一：执行恢复命令失败

注意

问题二：租户的恢复状态一直卡在 RESTORE_WAIT_LS 状态

注意

说明

问题三：Schema 刷新问题

注意

问题四：视图中恢复任务的状态为 FAILED

注意

注意