跨集群恢复时一直卡住

OceanBase 技术问题
#1

【 使用环境 】 测试环境
【 OB or 其他组件 】observer
【 使用版本 】社区版3.1.4
【问题描述】利用备份执行跨集群恢复时，一直卡住
【复现路径】1.对集群所有机器进行挂载，2.创建资源单元，3.创建资源池，4.执行恢复，5.查看CDB_OB_RESTORE_PROGRESS表，status一直卡在RESTORE_SYS_REPLICA状态，FINISH_PARTITION_COUNT一直卡在22
备份集群基本没什么数据。恢复集群的资源单元是2c2g的。试了几次是必现的，这个问题应该怎么排查。

#3
#4

多谢，我安装确认下

#5

在目标集群上查询下面事件视图，不断变换条件过滤掉无关的记录，看有没有 跟 restore 有关的事件一直在报错（value3 或 value4 是负值）。

SELECT gmt_create ,module,event ,name1 ,value1 ,name2,value2,name3,value3,name4,value4 
FROM `__all_rootservice_event_history` 
WHERE 1=1
--  AND module IN ('daily_merge')
ORDER BY gmt_create DESC LIMIT 1000;
#6

image
image1920×821 33.6 KB

我找了下创建资源池后的部分事件，看着是第三条那里刚开始就报错了。这部分信息能排查到大概原因么

#7

需要发一下备集群的资源信息，跑下下面SQL：

select zone,concat(SVR_IP,':',SVR_PORT) observer,
	cpu_capacity_max cpu_total,cpu_assigned_max cpu_assigned,
	cpu_capacity-cpu_assigned_max as cpu_free,
	round(memory_limit/1024/1024/1024,2) as memory_total,
	round((memory_limit-mem_capacity)/1024/1024/1024,2) as system_memory,
	round(mem_assigned/1024/1024/1024,2) as mem_assigned,
	round((mem_capacity-mem_assigned)/1024/1024/1024,2) as memory_free,
	round(log_disk_capacity/1024/1024/1024,2) as log_disk_capacity,
	round(log_disk_assigned/1024/1024/1024,2) as log_disk_assigned,
	round((log_disk_capacity-log_disk_assigned)/1024/1024/1024,2) as log_disk_free,
	round((data_disk_capacity/1024/1024/1024),2) as data_disk,
	round((data_disk_in_use/1024/1024/1024),2) as data_disk_used,
	round((data_disk_capacity-data_disk_in_use)/1024/1024/1024,2) as data_disk_free
from gv$ob_servers;

select t1.name resource_pool_name, t2.`name` unit_config_name, 
	t2.max_cpu, t2.min_cpu, 
	round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
	round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops, 
	t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
	t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
	join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
	join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
	left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;

看看 还原的时候这个租户资源池还原出来么？

#8

再查一下，把 列 name5,value5 放出来。

SELECT gmt_create ,module,event ,name1 ,value1 ,name2,value2,name3,value3,name4,value4, name5,value5 
FROM `__all_rootservice_event_history` 
WHERE 1=1
--  AND module IN ('physical_restore','root_service')
ORDER BY gmt_create DESC LIMIT 10;
#9

image
image1898×660 27.6 KB

#10

image
image782×524 14.4 KB

有报错，我安装的版本是3.1.4，是不是版本的区别

#11

不好意思，给错版本了。

select a.zone,concat(a.svr_ip,':',a.svr_port) observer, cpu_total, (cpu_total-cpu_assigned) cpu_free
, round(mem_total/1024/1024/1024) mem_total_gb, round((mem_total-mem_assigned)/1024/1024/1024,2) mem_free_gb
, round(disk_total/1024/1024/1024) disk_total_gb, round((disk_total-disk_assigned)/1024/1024/1024) disk_free_gb
from __all_virtual_server_stat a join __all_server b on (a.svr_ip=b.svr_ip and a.svr_port=b.svr_port)
order by a.zone, a.svr_ip
;

select t1.name resource_pool_name,  t2.`name` unit_config_name, t2.max_cpu, t2.min_cpu
, round(t2.max_memory/1024/1024/1024) max_mem_gb, round(t2.min_memory/1024/1024/1024) min_mem_gb
, round(t2.max_disk_size/1024/1024/1024) max_disk_size , t4.tenant_name
from __all_resource_pool t1 join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
    join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
    left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id
;
#12

image
image1033×596 17.9 KB

磁盘空闲是负数，是这个原因么。但是我df -h看着是有空间的。

#13

disk 这个应该没啥关系。
我看整个集群的节点主机内存估计很小，8G 不到吧。 这么小规格的 OB 做 恢复演练我不确定能不能成功。
具体可能要用 obdiag 收集相关日志进行分析。这个会比较费精力，不建议做。

如果你能把集群节点内存扩容到 16G 再做这个实验，成功的概率会高很多。

#14

此外，看起来像是 zone1的节点内存用完了。
sys_unit_config的最小最大内存没有拉平，这个导致剩余内存的计算总不是那么直观。
你先执行下面SQL

alter resource unit sys_unit_config max_memory='2G',min_memory='2G';

然后再跑一下前面 2个 SQL。
看看 节点的剩余内存是不是负数。或者上面 alter 语句可能就直接失败了。

然后执行下面SQL

alter system set __min_full_resource_pool_memory=1073741824;
alter resource unit unit04_for_recover max_memory='1G',min_memory='1G';

然后再执行 前面那个 alter resource unit sys_unit_config max_memory='2G',min_memory='2G';
再重新执行前面2个查询语句，看剩余内存。
然后等一会再查看 __all_rootservice_event_History 看恢复事件是不是在成功推进。

#15

obdiag 支持按照场景来收集信息，比如恢复问题直接执行：
obdiag gather scene run --scene=observer.recovery

1 个赞
#16

obdiag gather scene list 可以查看所有支持的版本。用obdiag来排查问题/收集信息更高效，一键执行就行。

#17

这几步的sql执行都没报错。
这是最后的查询结果

image
image1063×600 18 KB

现在通过CDB_OB_RESTORE_PROGRESS查询，昨天的恢复进程还存在，但是进度看着没有变化，我加内存重新测一下。
多谢解答！

#18

我执行试试，谢谢

#19

问题是否已解决？

#20

内存暂时没加上，没继续往下测

#21

恢复不了的问题前面有同学确认是内存问题了。
建议后续使用4.x的OceanBase吧，3.1分支的版本已经很老了。

2 个赞