OCP备份可以备份,不能恢复

在OCP对租户进行了备份,已经备份成功到nfs或者cos,恢复的时候不能选择恢复源租户是怎么回事呢
OCP版本:4.2.1
OceanBase版本:4.2.1


你的问题我们已经收到,稍后会有相关同学回复

因为没有安装utils,或者安装了utils,但是对应的可执行文件不在家目录的bin目录下,需要在每个observer节点安装。

下载utils的rpm,在机器上解压,或使用rpm直接安装,指定目录,注意:需要下载对应版本的utils包。https://www.oceanbase.com/softwarecenter

rpm -ivh --prefix=/home/admin/myoceanbase/oceanbase-utils-xxx.rpm

rpm2cpio oceanbase-ce-utils-xxx.rpm | cpio -id

ob_admin → /home/admin/myoceanbase/oceanbase/bin/ob_admin — 根据实际目录填写

授权,将ob_amdin文件授权给observer进程的相关用户权限。

有安装utils,并且也在家目录的bin目录下。

有没有可能是存储配置检测失败的原因,我换了nfs和cos都是检测失败,但是又可以备份

我看上图的提示的版本写的是3.2.2企业版本号,咱们OCP和OB是企业版版本吗,如果是企业版本建议联系企业支持确认下,社区和企业版本是有些细节出入的。

社区版的

麻烦提供下observer的 bin目录下的文件信息截图,确认下文件信息。
ps -ef|grep obs 可以看到目录信息

咱们这个OB是怎么安装的呢。我使用obd部署的ob复现了这个问题,并安装上utils运维包后,恢复时显示了源租户信息。

还有个可能,备份文件可能有损坏。

ob是通过ocp部署的

使用OCP部署OB未复现该问题。

麻烦手动调用下看下返回结果:
observer bin目录下,按实际目录如下格式

./ob_admin dump_backup -dfile:////home/admin/back/ocp_ob/1701328138/tenant_incarnation_1/1002/data/backup_set_1_full/tenant_backup_set_infos.obbak
./ob_admin dump_backup -dfile:////home/admin/back/ocp_ob/1701328138/tenant_incarnation_1/1002/data/backup_set_1_full/infos/diagnose_info.obbak

如果有报错:
./ob_admin: error while loading shared libraries: libmariadb.so.3: cannot open shared object file: No such file or directory

解决方式,按现场实际目录:
echo ‘export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/admin/oceanbase/lib’ >> ~/.bash_profile
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/admin/oceanbase/lib

麻烦了提供 这2个命令完整的输出信息。

diagnose_info.zip (20.2 KB)

咱们的备份介质使用的是nfs吗,失败的原因是无法找到备份文件信息。
[2023-12-07 10:08:42.321365] ERROR issue_dba_error (ob_log.cpp:1866) [27075][][T500][Y0-0000000000000000-0-0] [lt=0][errcode=-4388] Unexpected internal error happen, please checkout the internal errcode(errcode=-9026, file=“ob_storage.cpp”, line_no=80, info=“invlaid backup uri”)
[2023-12-07 10:08:42.321403] EDIAG [STORAGE] get_storage_type_from_path (ob_storage.cpp:80) [27075][][T500][Y0-0000000000000000-0-0] [lt=37][errcode=-9026] invlaid backup uri(ret=-9026, uri=) BACKTRACE:0xfa13582 0x63451c0 0x6344d8f 0x6344a5e 0x6344868 0xf8f59f6 0xf8f591b 0xeefa59f 0x663359b 0x6350102 0x7f15a211f555 0x47c5ba0

之前使用的nfs是这种现象,现在使用的cos,也是这种现象


和这个失败有没有关系?我用什么介质这边都是失败的。

麻烦手动黑屏触发下数据恢复。

设置下trace:
系统租户执行:alter system set enable_rich_error_msg=true;

执行恢复命令,应该会直接报错,设置trace后,报错命令会返回trace信息,去对应节点的rootservice.log 和observer.log 过滤trace信息。看下具体日志报错什么。

YB420A3C0035-00060C0576EFFE28-0-0.log (87.0 KB)