GBase 8a集群gbase.table_distribution is incomlete异常处理总结

课题概述

本文对GBase 8a集群“gbase.table_distribution is incomplete on localhost”异常进行分析并总结处理方法。

集群环境

集群版本：GBase 8a V862-Build33-R11

异常现象

在笔者的项目经历中，该异常在并发DDL任务较高（超过50）的集群容易出现，在磁盘空间及IO资源较紧张的情况下会加剧该异常出现的几率。异常现象为：集群的部分管理节点，在执行SQL时报错：gbase.table_distribution is incomplete on localhost。异常信息如下图所示：

同时，集群在该节点会出现gbase.table_distribution的dmlstorageevent。最严重的情况，所有coor节点的gbase.table_distribution都会出现异常，导致所有coor节点都无法正常执行SQL。

一般情况下，集群会及时处理该异常，及时恢复异常节点的gbase.table_distribution数据，此时该节点即可正常执行SQL。但在集群DDL并发任务较高的情况下，gbase.table_distribution可能会出现长时间无法恢复的情况，或者所有coor节点的gbase.table_distribution都出现该异常（无法自动恢复），这会导致问题的严重化。

问题分析

该异常出现的原因分析如下：

在集群并发任务较高的场景，磁盘IO接近瓶颈，集群下发的DDL任务连接节点或是执行SQL超时失败，导致gbase.table_distribution的数据写入/更新失败（不一定是文件损坏），集群在该节点记录gbase.table_distribution的dmlstorageevent。

此时，gclusterd层express.log中可能会出现类似如下异常信息:

2022-06-10 09:40:35.886 [CPOOL2][WARN ][S:5518576][Q:17327229]:Abnormal, can't create a connection. host:10.113.148.78,db:. Cause: Lost connection to GBase server at 'reading authorization packet', system error: 11

2022-06-10 09:40:36.487 [CPOOL2][WARN ][S:5518576][Q:17327229]:Abnormal, failed in creating a connection to some node.

2022-06-10 09:40:36.496 [DDL][ERROR][S:5518576][Q:17327229]:EXECUTE ERROR: (delete /*+ sub_step */ from gbase.table_distribution where dbname = 'em_cb' and tbname = 'my_myyzd390_ct_fee_leiji_201910') Delete one table from metadata

2022-06-10 09:40:38.358 [CPOOL2][WARN ][S:5978632][Q:17327235]:Abnormal, can't create a connection. host:10.113.148.78,db:. Cause: Lost connection to GBase server at 'reading authorization packet', system error: 11

集群的recover机制会处理gbase.table_distribution的dmlstorageevent，但是需要先对gbase.table_distribution加独占锁，此时如果集群并发DDL任务较多，集群上锁的争抢机制可能会导致gbase.table_distribution的恢复操作长时间抢不到锁从而无法恢复的情况。此时在gcluster的gc_recover.log日志中可观察到recover操作对gbase.table_distribution的lock failed异常信息。

另外一种极端情况，所有coor节点的gbase.table_distribution都出现该异常，此时由于没有正常的副本数据，也会导致无法自动恢复。

处理方法

部分coor节点出现上述异常的情况，建议的做法是暂时停止集群DDL业务，此时集群recover机制会迅速恢复gbase.table_distribution数据（从其他节点还原），一般耗时在几秒至几分钟左右。不太友好的方式是：暂时冻结所有普通用户并杀掉所有运行的DDL任务，等待异常恢复后，再解冻用户。

所有coor节点都出现上述异常的情况，此时无法自动恢复，只能人工介入处理。这种情况出现的几率较小，一般不会是gbase.table_distribution文件真的损坏，只是记录了dmlstorageevent。此时需要先检查所有coor节点的gbase.table_distribution数据，可通过select * from gbase.table_distribution导出数据检查确认，如果数据都能正常查询，一般可认为问题不大。

此时需要暂停集群业务进行手动恢复，如果集群各节点

gbase.table_distribution数据量一致，直接清理掉dmlstorageevent即可。如果各节点数据量存在差异，将数据文件时间戳最晚的一个节点文件复制到其他节点进行恢复,数据文件为：

$GCLUSER_HOME/userdata/gcluster/gbase/table_distribution.frm

$GCLUSER_HOME/userdata/gcluster/gbase/table_distribution.MYD

$GCLUSER_HOME/userdata/gcluster/gbase/table_distribution.MYI

然后在所有coor节点执行refresh table gbase.table_distribution，最后恢复集群业务。