目录

一、环境信息

二、前景提要

1、情况描述

2、3号节点gc_recover日志截图

3、3号节点express日志截图

4、ddlevent截图

5、报错赋权语句分别在1节点和4节点执行

6、gcadmin

三、解决方法

1、描述

2、清理系统user表DDLEVENT

3、拷贝系统user表数据

（1）停止4节点服务

（2）切换到4节点gcluster层目录

（3）备份user表的相关三个文件

（4）切换到1节点

（5）拷贝user表的相关三个文件

（6）启动4节点服务

4、等待视图相关DDLEVENT自我修复

---

一、环境信息

名称	值
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脚本

#encoding:utf-8
import gcwaredef 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节点服务

service gcware stop

（2）切换到4节点gcluster层目录

cd /安装目录/gcluster/userdata/gcluster/gbase

（3）备份user表的相关三个文件

cp user.* /home/gbase/BakFile/

（4）切换到1节点

（5）拷贝user表的相关三个文件

scp /安装目录/gcluster/userdata/gcluster/gbase/user.* gbase@4节点IP:/安装目录/gcluster/userdata/gcluster/gbase/

（6）启动4节点服务

service gcware start

4、等待视图相关DDLEVENT自我修复

我这边视图相关DDLEVENT只有5个，差不多10分钟完成自我修复。如果大家发现其长时间没有自我修复，可以仿照user表的方法进行修复，这种方法为非常规修复方法，建议大家在原厂支持的情况下进行操作，毕竟生产环境还是要小心小心再小心的。