目录
一、环境信息
名称 | 值 |
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 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节点服务
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表的方法进行修复,这种方法为非常规修复方法,建议大家在原厂支持的情况下进行操作,毕竟生产环境还是要小心小心再小心的。