目录
一、环境信息
|-----------|-------------------------------------------|
| 名称 | 值 |
| CPU | Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz |
| 操作系统 | CentOS Linux release 7.9.2009 (Core) |
| 内存 | 3G |
| 逻辑核数 | 2 |
| Gbase8a版本 | 8.6.2-R43 |
二、前景提要
1、情况描述
4号管理节点内存告警，配合更换厂家硬件后，出现DDLEVENT，DDLEVENT一直没有下降，3号节点拿到了恢复4号节点的任务，一直在后台恢复，但恢复报错，导致4号管理节点置1，数据节点正常。
2、3号节点gc_recover日志截图
3、3号节点express日志截图
4、ddlevent截图
5、报错赋权语句分别在1节点和4节点执行
6、gcadmin
三、解决方法
1、描述
4节点的系统user表损坏，导致自动回复失败，DDLEVENT一共分为两个大类一个是视图，一个是系统user表的。我们只手动恢复user表，视图让其自动恢复。
2、清理系统user表DDLEVENT
任意管理节点执行此Python脚本
python
#encoding:utf-8
import gcware
def G8aCleanDDlEvent():
AllDDlEvent = gcware.getddlfevents()
for i in AllDDlEvent:
if '.user..' in i['tablename']:
CleanNums = gcware.clearddlfevent(i['tablename'])
print("TabName : %s , CleanNums : %d" % (i['tablename'],CleanNums))
if __name__ == '__main__':
G8aCleanDDlEvent()3、拷贝系统user表数据
（1）停止4节点服务
bash
service gcware stop（2）切换到4节点gcluster层目录
bash
cd /安装目录/gcluster/userdata/gcluster/gbase（3）备份user表的相关三个文件
bash
cp user.* /home/gbase/BakFile/（4）切换到1节点
（5）拷贝user表的相关三个文件
bash
scp /安装目录/gcluster/userdata/gcluster/gbase/user.* gbase@4节点IP:/安装目录/gcluster/userdata/gcluster/gbase/（6）启动4节点服务
bash
service gcware start4、等待视图相关DDLEVENT自我修复
我这边视图相关DDLEVENT只有5个，差不多10分钟完成自我修复。如果大家发现其长时间没有自我修复，可以仿照user表的方法进行修复，这种方法为非常规修复方法，建议大家在原厂支持的情况下进行操作，毕竟生产环境还是要小心小心再小心的。