【 使用环境 】生产环境
【 OB or 其他组件 】oceanbase
【 使用版本 】4.2.2.0CE
【问题描述】
恢复到一半。
查询恢复结果，comment显示异常如下：
(SERVER)ls_id: 1007, addr: 172.26.49.126:2882, module: RESTORE_DATA, result: -9003(OSS error), trace_id: YB42AC1A317E-00061FE0C2AE637F-0-0;(SERVER)ls_id: 1008, addr: 172.30.224.164:2882, module: RESTORE_DATA, result: -9003(OSS error), trace_id: YB42AC1EE0A4-00061FE0C15C683B-0-0;
找到具体服务器打印日志：
3-3-3集群。如图，仅164这台服务器数据不增长了。其他服务器的数据仍然还在增长
或者有没有办法恢复164服务器的【物理备份恢复】任务。
本次恢复目的仅是为了获取这个副本的表结构。数据不重要
恢复到一半就是没恢复完，这个时候租户都不能正常访问。。
如果只要表结构那不如从源租户中用obdumper把表结构导出来
可以看看能不能直接从 物理备份里恢复出表？
参考： 执行按表恢复-V4.2.2-OceanBase 数据库文档-分布式数据库使用文档
ALTER SYSTEM
RECOVER TABLE infodb.tbl1,infodb.tbl2
TO TENANT oracle001
FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive'
UNTIL TIME='2023-09-30 00:00:00'
WITH 'pool_list=restore_pool'
REMAP TABLE infodb.tbl1:newtbl
REMAP TABLEGROUP tg1:newtg1
REMAP TABLESPACE ts1:newts1;
原租户、集群都删掉了
需要所有的表结构数据··
recover和restore有什么不一样吗
我执行的这个命令。直接从oss备份数据恢复租户
ALTER SYSTEM RESTORE dest_tenant_name FROM uri WITH ‘restore_option’ [WITH KEY FROM ‘backup_key_path’ ENCRYPTED BY ‘password’] [DESCRIPTION description];
这个恢复速度也太慢了。写入速度才2M。
4T的数据不知道得花多久时间。。
并发度也不敢设置得太高，容易引起oss限流异常。。。
是我哪里参数调整的不对吗。
要花这么长时间
2024-08-18 15:13:07.862945重新执行了一遍恢复
命令如下：
ALTER SYSTEM RESTORE mysql FROM ‘oss://oceanbase-test-bucket/backup/data/?host=.aliyun-inc.com&access_id=&access_key=,oss://oceanbase-test-bucket/backup/archive/?host=.aliyun-inc.com&access_id=&access_key=’ UNTIL TIME=‘2024-08-16 00:30:00’ WITH ‘pool_list=restore_pool’
查看恢复进度。一直显示。文档里面的很多字段都是没有的。
查询结果如下
文档中显示，存在恢复分片数量等等都没有。而且恢复字节数一直都是0···
恢复任务很容易就失败了。都不敢开太多线程。
设置ha_high_thread_score:90。出现一次9003：oss error错误就整个任务都失败了。
这次试用了50.
结果发现oss那边的qps才102。 这个也太折磨人了吧···
result: -9003(OSS error)
恢复失败了是不能读取表结构的，可清理恢复失败租户，调整 参数 ha_high_thread_score后再次尝试恢复，参考
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000340640?back=kb
之前几次失败就是这么干的。
这次重试了将ha_high_thread_score改为50.
然后查看恢复进度。 显示完成的字节数一直为0。
而集群资源显示试用的数据盘大小一直在涨。 目前每台机器都350G左右了。
可能恢复进度比较慢，你间隔多久查的是0，再次查看试试
SELECT * FROM oceanbase.CDB_OB_RESTORE_PROGRESS WHERE RESTORE_TENANT_NAME=‘xxx’ AND TENANT_ID=xxx\G
这几个字段的数据都是0吗？麻烦发下rootservice.log
搞了3天了。。。 放弃了~~唉。。心累
oss限流太严重了，看能否调整下
rootservice.log麻烦发下吧，我们分析下看是否有其它问题。
