GBase 8a集群tableid过大引起gbased宕机问题及处理方法

一、问题概述

笔者所在项目的部分集群出现过由于用户表ID(tableid)过大引起多个节点gbased组件宕机的问题，最终通过绕行方案解决，本文记录该问题的场景、分析过程及处理方法。

二、问题场景及分析

集群版本：GBase8a_MPP_Cluster-NoLicense-8.6.2_build33-R11-redhat7.3-x86_64。

集群上线运行时间较长，并发任务量大，DDL任务多，删除新建表的操作频繁，表数量异常大，部分集群表数量超过50万张的规模。

集群出现多个节点gbased组将同时宕机的现象，宕机堆栈不固定且通过宕机SQL无法稳定复现。

怀疑方向有二：

1. 磁盘硬件异常，但多个节点gbased同时宕机，不太复合逻辑，检查系统日志messages也未发现相关异常。

2. Tableid过大。V862Build43以下版本，正式表tableid取值范围为1~2147483647（约21.4亿），临时表tableid取值范围1073741823（约10.7亿）~ 2147483647（约21.4亿），如果正式表数量过大，tableid超过10.7亿，可能会出现中间临时表tableid与gnode层表tableid的冲突，导致gbased宕机，冲突的条件需要正式表、临时表同时打开。V862Build43及以上版本，正式表tableid取值范围为1~9223372034707292160，9223372034707292161~9223372036854775806，几乎可认为是无限量，存在冲突的可能性极低。

检查gnode层tableid与临时表id，取值分别为1172365799/1171491700，正式表ID已经超过了可使用区间的一半，与临时表ID存在冲突的可能，故可能是由于这个原因引起宕机。

两个ID的检查方法如下：

正式表ID：

python -c "import sys; import gcware; print gcware.gettableid()"

临时表ID: 

cat /${gbase_data_dir}/gnode/userdata/gbase/express.seq

可选处理方法：

1. 观察正式表id与临时表id的增长趋势，如果两个ID交叉后，差值逐渐拉大，则问题不会再出现，可以暂时不用处理。

2. 定期检查正式表ID、临时表ID，如果用户表ID接近10.7亿或是与临时表ID差值较小，存在冲突可能，则对临时表ID进行手动重置（设置为10.7亿至21.4亿中的某个值，拉大与正式表ID的间隔）。

三、处理方法

本项目现场采用定期检查正式表ID与临时表ID差距，并手动重置临时表ID的方法规避此类问题。

使用下列指令获取正式表ID、临时表ID:

正式表ID：

python -c "import sys; import gcware; print gcware.gettableid()"

临时表ID: 

cat /${gbase_data_dir}/gnode/userdata/gbase/express.seq

当两者差值超过阈值（比如：1000万）时，进行临时表ID的手动重置，将临时表ID重置为10.7亿至21.4亿之间的某个值（比如：15亿），将两个ID的差距拉大。

重置临时表ID的方法如下：

暂停业务，将各节点临时表ID当前值修改为新的值，不许执行新的SQL（否则新值会失效），重启gbased，执行SQL，验证新值是否生效。

1)停止业务执行

停止系统定时任务，包括监控/统计等任务。

2)备份中间层临时表ID(express.seq)：

cexec data: 'cat /gbase/gnode/userdata/gbase/express.seq'

cexec data: 'cp /gbase/gnode/userdata/gbase/express.seq /gbase/gnode/userdata/gbase/express.seq.bak'

cexec data: 'cat /gbase/gnode/userdata/gbase/express.seq.bak'

3)更新中间层临时表ID(express.seq)：

-- 更新临时表ID为初始值10.7亿

cexec data: 'echo 1073741823 > /gbase/gnode/userdata/gbase/express.seq'

cexec data: 'cat /gbase/gnode/userdata/gbase/express.seq'

-- 更新临时表ID为10.7亿至21亿的中间值

cexec data: 'echo 1573741906 > /gbase/gnode/userdata/gbase/express.seq'

cexec data: 'cat /gbase/gnode/userdata/gbase/express.seq'

3)重启集群gbased

cexec data: 'gcluster_services gbase restart'

4)验证SQL(更新临时表ID):

use ssbm;

select c_name,sum(lo_revenue) from customer a 

inner join lineorder b on a.c_custkey=b.lo_custkey 

group by a.c_name order by sum(lo_revenue) desc 

limit 10;

4)检查确认中间层临时表ID正常更新：

cexec data: 'cat /gbase/gnode/userdata/gbase/express.seq'

5)检查集群运行情况

6)恢复应用业务执行

7)恢复系统定时任务调度

回退临时表id方法：

1)停止业务执行

2)恢复中间层临时表ID(express.seq)：

cexec data: 'cp /gbase/gnode/userdata/gbase/express.seq.bak /gbase/gnode/userdata/gbase/express.seq'

3)重启集群gbased

cexec data: 'gcluster_services gbase restart'