GBase8a集群v953扩容案例问题分享

概述 

某个项目的GBase8a集群v953版本计划在多vc其中的vc1扩容3节点双实例，分享如何回退重分布，及无法取消重分布如何手工介入解决。

问题分析及处理 

集群总体环境如下： 

集群版本：GBase8a_MPP_Cluster-953.27.20-patch6.2 

集群操作系统：kylin v10 

1.回退重分布  

参照v95扩容步骤在重分布过程中采用rebalance database dbname的方式以库为单位扩容，期间观察扩容节点的空间变化，发现重分布完成后空间没有变化，查询gbase.table_distribution发现大部分都是随机表，当前版本的gcluster_rebalancing_random_table_quick_mode参数默认值是1开启的状态， 

关于该参数的说明参考如下： 

因为随机分布表的特性，数据在任何节点都不影响查询结果，而且大部分随机分布表都是大表，也就是不适合选择某个列做Hash分布表。而这种表因为磁盘占用大，如果参与重分布，则需要大量的时间，所以数据库提供了参数，默认随机分布表做快速重分布，不重新分散数据，而是保留现有数据状态。 

• 调整随机表参数 

Set global gcluster_rebalancing_random_table_quick_mode = 0; 

此时需要回退重分布的随机表 

• 获取切片id

查看gcadmin showdistribution vc vc1 查看对应的切片信息， State: old获取对应的 Distribution ID: 1 

• 清理重分布任务表

delete from gclusterdb.rebalancing_status;  

• 回退重分布

命令

 rebalance {instance|database dbname|table tbname} [to distributionID] 

说明 

该重分布命令，默认是将老的分布策略(distributionid 较小的)，重分布到新的(较大的)，在某些情况下，也存在要回退的可能性，比如随机分布表默认是快速重分布，但现场因为磁盘空间问题做的扩容，参数忘记设置了，而此时只有部分表做了重分布操作。清理现有任务，避免后续的重分布 delete from rebalancing_status; 回退到老的分布策略 通过rebalance table to 方法，将表回退到1，注意其中的gclusterdb.rebalancing_status不能手工回退。 

gbase.table_distribution查找对应db的随机表名称并拼接sql批量执行 : rebalance table tablename to 1; 

• 再次清理重分布任务表 

delete from gclusterdb.rebalancing_status;  

• 重新开始重分布 

参考重分布方案，不再重复。 

2.手动介入取消重分布 

由于大表重分布过程中遇到跑批锁表情况，需要取消重分布释放锁。 

cancel reablance table tablename 指定表名的方式取消重分布 

正常情况下会回滚取消，现场取消等待接近一个小时还未回滚完成，检查数据节点空间也没有任何释放。

通过查询所有vc1的数据节点执行：

gncli -ugbase -pxxxxxx -e”show processlist”|grep -iv sleep

查看任务存在：

select * from db.tablename limit 0,1000000000 target into server字样的任务正在rollback回滚的状态

gncli执行 kill 对应会话id后释放任务 

再观察gclusterdb.rebalacing_status的状态已经取消了。