OceanBase恢复常见问题

常见的恢复报错和问题
恢复失败排查
恢复长时间不结束
表级别恢复失败
数据恢复调优

使用备份恢复的场景:

常规的恢复数据，如果需要挪动备份文件，建议全备时加上PLUS ARCHIVELOG参数。
恢复备租户，做主备租户。
表数据误删，做表级别恢复。

常见的恢复报错和问题

恢复时报错-4018 No enough log for restor
- （1）日志归档期间有断流，导致日志不连续。这种情况只能重新做全备。
- （2）快速完成全备后关闭归档进行恢复，归档日志有延迟可能浅开始归档，建议全备时加上PLUS ARCHIVELOG参数。
- （3）通常是在执行恢复语句时所指定的恢复终点不正确导致。选取的恢复点位需要遵循以下要求:
  - 大于等于数据备份视图CDB_OB_BACKUP_SET_FILES中记录的数据备份的最小恢复位点MIN_RESTORE_SCN_DISPLAY。
  - 小于等于日志归档视图CDB_OB_ARCHIVELOG中的最大归档位点CHECKPOINT_SCN_DISPLAY。

sql 复制代码

select CHECKPOINT_SCN_DISPLAY from CDB_OB_ARCHIVELOG; >= restore_timestamp >= select MIN_RESTORE_SCN_DISPLAY from CDB_OB_BACKUP_SET_FILES;

恢复时报错-4012 timeout ：通常是备份介质性能问题导致，可以多尝试几次，或者调大ob_query_timeout超时参数。
恢复时报错-9099 restore failed：通常是参数问题，比如参数中的资源池已经被其他租户使用了。
恢复时报错-1210 Incorrect arguments to tenant compatible of back set：通常是使用了其他版本的备份，而恢复的OB版本不支持。
权限问题-4009 IO error：通常是恢复的集群无法访问备份文件目录，比如cp的备份文件权限被修改。
OCP表级别恢复无法选到表：新增过分区的表会无法选择，产品缺陷，修复版本未发布，可以黑屏方式恢复。
恢复过程中报错-4184 out of disk space
- 表级别恢复，实际是将原租户恢复到临时租户，再从临时租户恢复出表级别，原租户数据量大的情况下是可能磁盘不足问题。
- 恢复时系统是不会检查现有磁盘资源是否足够恢复，恢复逗过程磁盘达到阀值触发报错。
恢复过程中报错-4103 OB_CHECKSUM_ERROR ：数据校验失败，大概率是nfs挂载、或者挂载参数和官网要求没对齐、或者nfs服务端有异常、或者cp备份文件

传输时文件损坏等。建议检查挂载参数重新挂载，尝试重新备份恢复。
对象存储设置归档存储权限 ：归档存储权限无法被读取，恢复时会卡住，报错-9071 fail to read file。

恢复失败排查

视图CDB_OB_RESTORE_HISTORY恢复任务的状态为FAILED。

sql 复制代码

SELECT * FROM oceanbase.CDB_OB_RESTORE_HISTORY WHERE TENANT_ID=1002;

根据comment字段中获取到的trace_id和result等信息搜相应日志。

bash 复制代码

grep "Y411A64586BDB-00060548EBF6948A-0-0" observer.log

查看rs事件获取机器IP。

sql 复制代码

# result对应的值即报错的错误码
# RS_SVR_IP的值即Root Service所在机器的IP
# value1对应租户ID
select * from __all_rootservice_event_history where module like "%physical_restore%" and event like "%start_recover%" and value1=1002;

去对应Root Service所在机器过滤日志关键字。

bash 复制代码

# 去对应节点过滤错误码或者恢复线程 ob_restore_util 关键字
grep "\-4184" rootservice.log
grep "ob_restore_util" rootservice.log

恢复长时间不结束

Schema刷新问题

如果CDB_OB_RESTORE_PROGRESS中只有sys租户的记录，那么可能就是Schema刷新的问题。

排查思路如下。

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

sql 复制代码

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

⭐️ Schema刷新成功需要满足以下条件:

REFRESHED_SCHEMA_VERSION = RECEIVED_SCHEMA_VERSION
REFRESHED_SCHEMA_VERSION的值大于8
REFRESHED SCHEMA_VERSION / 8的值为整数

只要以上任意一个条件不满足，就表示Schema未刷新出来。

此时可以根据IP去对应节点过滤关键字SerScheQueue日志，一般是WDIAG级别日志会有异常信息。

bash 复制代码

[admin@observer log]$ grep "SerScheQueue" observer.log
WDIAG [RPC.OBRPC] rpc_call (ob_rpc_proxy.ipp:361)[192069] [SerScheQueue0] [T0] [YFA00BA2D905-0005E5DEE6SA2294E-0-0] [lt=8] execute rpc fail(ret=-4012, dst="x...

根据上文过滤的日志会包含trace_id和dst目的段的IP，去该IP过滤trace_id。

bash 复制代码

[admin@observer log]$ grep "YFA00BA2D905-0005E5DEE6SA2294E-0-0" observer.log

恢复状态卡住

确认租户的恢复状态：

CREATE_TENANT：创建恢复租户。
WAIT_TENANT_RESTORE_FINISH：系统租户等待恢复租户恢复完成。
RESTORE_CREATE_INIT_LS：恢复租户创建初始待恢复日志流。
PHYSICAL_RESTORE_WAIT_RESTORE_TO_CONSISTENT_SCN：等待所有日志流副本恢复到一致性SCN。
RESTORE_WAIT_LS：等待所有日志流恢复完成。
POST_CHECK或UPGRADE：无需关注。

sql 复制代码

SELECT * FROM oceanbase.__all_virtual_restore_job WHERE name = "status" AND tenant_id = 1002;

一般卡在RS调度相关状态时，去租户meta元租户1号日志流的leader过滤日志。

sql 复制代码

select svr_ip,svr_port from __all_virtual_ls_meta_table where tenant_id = 1001 and ls_id = 1 and role = 1;

# 过滤关键字"T1002_REST"
grep "T1002_REST" rootservice.log

如果恢复卡在RESTORE_WAIT_LS，先确认日志流副本的恢复状态。

restore_status=0表示日志流副本恢复正常；
restore_status值为6或8，表示主要进行日志和转储的恢复。通常卡在6状态。

sql 复制代码

select ls_id,svr_ip,svr_port,role,member_list,replica_status,restore_status,paxos_replica_number,learner_list from __all_virtual_ls_meta_table where tenant_id=1002 and restore_status != 0;

# 根据上述状态为6的日志流leader
select * from __all_virtual_log_stat where tenant_id = 1002 and ls_id = xxx;

过滤关键字信息，如果正常打印就继续下面的排查。

bash 复制代码

grep "restore log to_end succ" observer.log | grep T1002 | grep CLOG

end_scn：表示最大可消费位点。
recovery_until_scn：表示租户的恢复终点。

sql 复制代码

SELECT count(1) FROM oceanbase.GV$OB_LOG_STAT WHERE tenant_id = 1002 
AND end_scn < (SELECT recovery_until_scn FROM oceanbase.__all_virtual_tenant_info WHERE tenant_id = 1002);

如果查询为空，表示日志从归档目录恢复到租户中成功。
如果查询不为空，则表示有日志未从归档目录恢复到目标租户。

继续观察GV$OB_LOG_STAT视图中end_scn的值，如果end_scn仍然在推进，则继续等待。

确认是否有待回放的任务：

pending_cnt：表示正在等待回放的任务数量。如果该值不为零，则表示有待回放的任务。
unsubmitted_log_scn：表示未提交回放的位点。

sql 复制代码

SELECT * FROM oceanbase.__all_virtual_replay_stat WHERE tenant_id = 1002;

再查看虚拟表__all_virtual_tenant_info获取recovery_until_scn的值：

sql 复制代码

SELECT recovery_until_scn FROM oceanbase.__all_virtual_tenant_info WHERE tenant_id = 1002;

根据上面两次的查询结果：

如果pending_cnt的值为0，并且unsubmitted_log_scn的值大于recovery_until_scn的值，则表示日志回放完成。
否则，只要有任一条件未满足，则表示回放未完成。可以继续观察unsubmitted_log_scn是否在推进。

如果较长一段时间后，unsubmitted_log_scn仍然未推进，按照下述流程排查。

确认是否在执行迁移任务：

sql 复制代码

select * from __all_virtual_ls_info where tenant_id =1002 and ls_id = [ls_id];

如果存在迁移副本，副本leader会等迁移副本完成后再向前推进状态。

确认未回放完的日志流是否被transfer卡住。

去未回放完的日志流IP过滤日志，关注WDIAG和EDIAG级别日志信息。

bash 复制代码

grep "transfer_mds" observer.log

如果transfer有问题，可以参考官方文档《Transfer问题排查手册》。

日志流副本长时间处于其他状态。

是否有恢复相关的子任务失败：

sql 复制代码

select * from __all_virtual_dag_warning_history where tenant_id= 1002;

备份介质是否正常

磁盘性能差，比如机械磁盘、或者有延迟、负载高、或者异常报错等问题，参考《备份介质常见问题排查》。

表级别恢复失败

任务发起失败

查看失败原因，会返回trace_id和IP：

sql 复制代码

# value1对应租户ID
select * from __all_rootservice_event_history where event like "%start recover table%" and value1=1002;

过滤rootservice日志：

bash 复制代码

grep "$trace_id" rootservice.log

任务执行失败

利用comment字段确认失败原因，打印IP和trace_id：

sql 复制代码

select * from cdb_ob_recover_table_job_history where tenant_id = 1002;

过滤rootservice日志：

bash 复制代码

grep "$trace_id" rootservice.log

📖 COMMENT字段常见错误：

table test_table has been deleted by user：导入的表被用户删除。
import database not exist, test_database：需要导入的数据库在临时租户中不存在。
import table not exist, test_database.test_table：需要导入的表在临时租户中不存在。
import table test_database.test_table is not user table：需要导入的表不是用户表。
import table__recyclebin.test_table is in recyclebin：需要导入的表位于回收站中，不支持导入。
import table test_database.test_table hidden table：需要导入的表为隐藏表，不支持导入。
import table test_database.test_table exist：需要导入的表在目的租户中已存在同名表。
remap tablegroup test_tablegroup not exist：需要重命名的表组在目标租户中不存在。
remap tablespace test_tablespace not exist：需要重命名的表空间在目标租户中不存在。
aux tenant test_tenant has been dropped：临时租户被删除。
recover from different compatibility tenant is not supported：不支持目标租户和临时租户具有不同的mysql/oracle兼容性。
recover from different case sensitive compatibility tenant is not supported：不支持目标租户和临时租户具有不同的大小写敏感性。oceanbase租户的大小写敏感性为只读变量不可更改，用户需要选择相同敏感性的租户执行恢复。
target database test_database not exist：需要导入表的数据库在目标租户中不存在。

表恢复长时间不结束

确认导入没有推进的状态：

RESTORE_AUX_TENANT：表示在恢复临时租户。
IMPORTING：表示正在导入需要恢复的表。

sql 复制代码

# 查询status字段,确认当前任务的状态
select * from cdb_ob_recover_table_jobs where tenant_id = 1002;

# initiator_job_id 为 cdb_ob_recover_table_jobs 的 job_id
select * from cdb_ob_import_table_jobs where initiator_job_id = 123 and tenant_id = 1002;

# status状态: INIT(待调度), DOING(正在执行), FINISH(已完成)
select * from cdb_ob_import_table_tasks where job_id = 123;

检查DDL任务状态：

DOING状态是对应表的导入ddl任务没有完成。
INIT状态表示对应表的ddl导入任务无法正确生成。

sql 复制代码

# ddl任务是否完成, task_id 为 cdb_ob_import_table_tasks 的task_id,会打印 trace_id
select * from __all_virtual_ddl_task_status where tenant_id = 1002 and task_id = 12345;

根据返回的trace_id过滤日志：

bash 复制代码

grep "$trace_id" rootservice.log
grep "$trace_id" observer.log

确认当前租户的meta元租户的leader节点所在位置：

sql 复制代码

select svr_ip,svr_port from __all_virtual_ls_meta_table where tenant_id = 1001 and ls_id = 1 and role = 1;

过滤关键字ob_import_table_job_scheduler，关注WDIAG级别日志。

bash 复制代码

grep "ob_import_table_job_scheduler" rootservice.log

数据恢复调优

⭐️租户恢复性能调优：

log_restore_concurrency：控制日志恢复的并发数，该参数增大会增加内存资源开销。V4.2.0开始默认值为0，**设置为0表示取租户的max_cpu**设置为并发数。
ha_high_thread_score：控制数据恢复的并发度，默认值0，表示并发度为8。可以翻倍方式逐步增大观察对业务的影响进行适当控制。

⭐️表级别恢复性能调优：

ddl_thread_score：控制ddl任务使用线程，默认是2 。租户cpu<=4时，建议设置为4；大规格租户可以先设置8 ，观察性能，翻倍调整。恢复完成后建议还原参数。
recover_table_concurrency：多表恢复 场景使用，默认是1，一般建议设置8或16进行观察。
recover_table_dop：单表恢复 的并行度，默认是1，一般建议设置8或16进行观察。

Referennces

【1】备份恢复性能调优，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002517603

【2】备份目录结构，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001500556

【3】部署NFS，https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003577389

【4】Transfer问题排查手册，https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001017357

【5】OceanBase V4.x中的常用备份恢复SQL总结，https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000340642

【6】ob_admin安装，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000003379568