通过拷贝出来的备份进行租户物理恢复时恢复进度一直卡在“恢复中”状态的原因和解决方法

问题现象

参考官网 部署 NFS 正确配置了 NFS 服务器端和 NFS 客户端后，对业务租户 mysqlt 进行了如下的物理备份和物理恢复操作。具体步骤如下。

1. 设置业务租户 mysqlt 日志归档目录为：/obbackup/log/mysqlt。

2. 设置业务租户 mysqlt 数据归档目录为：/obbackup/data/mysqlt。

3. 为业务租户 mysqlt 启动日志归档，并一直等到日志归档状态处于 DOING 状态。

4. 发起全量备份命令：ALTER SYSTEM BACKUP TENANT=mysqlt; 等待全量备份完成后，把日志归档的目录 /obbackup/log/mysqlt 拷贝了一份，记作拷贝 A。

5. 恢复前手工停止了日志归档。、

6. 删除了 /obbackup/log/mysqlt 目录下的所有日志归档文件，然后把第 4 步的拷贝 A 的日志归档文件复制过来了。

7. 恢复全量备份中的业务租户到最新位点：ALTER SYSTEM RESTORE mysqlt_restore FROM 'file:///obbackup/data/mysqlt,file:///xxxxxxxxx/log/mysqlt' WITH 'pool_list=mysqlt_restore_pool';。

最后一步恢复操作正常情况下不到 20 分钟就可以完成，但是经常会出现租户恢复状态持续停留在恢复中状态，一直无法变成已完成的状态，如下图所示。

问题原因

自查了 NFS 文件系统挂载正确且没有 hang 住的情况、OceanBase 数据库集群的所有 OBServer 节点之间本地时钟均正确同步且无任何时间跳变发生。 经过排查后发现，问题的根因在于操作为非标准操作：由于在不停日志归档的情况下 copy 了整个日志归档目录（即这边的 /obbackup/log/mysqlt），并且选择恢复到最新的时间位点（如果不指定 UNTIL 子句，则默认恢复到最新的时间位点），但是在磁盘文件系统上日志归档文件及其元信息文件分别对应不同的物理文件，Linux 在拷贝整个日志归档目录的过程中无法保证日志归档文件及其元信息文件这两个文件能完全匹配上。一旦遇到拷贝出来的日志归档元信息文件比日志归档文件时间点更新的情况，在恢复时就会出现找不到对应时间点的日志归档文件的情况，导致整个恢复进度一直处于“恢复中”。

关于更详细的备份目录结构介绍，可以参见：备份目录结构。

问题的风险及影响

业务租户恢复进度一直处于非预期的恢复中状态。

适用版本

OceanBase 数据库 V2.x、V3.x、V4.x 所有版本。

解决方法

重新选择稍旧一些的时间位点进行恢复或者直接挂载原始的备份介质进行恢复。

规避方式

在通过物理备份 NAS 介质进行租户恢复时，客户需要严格按照标准化挂载整个物理备份 NAS 文件系统的方式进行恢复，不要使用拷贝出来的目录进行恢复的方式。否则无法保证日志归档/数据备份的备份文件和元信息完全一一匹配。如果实在需要使用拷贝出来的目录进行恢复，请务必先正确停下日志归档后再进行文件系统的拷贝操作。