目录
一、环境信息
|-----------|-------------------------------------------|
| 名称 | 值 |
| 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 start
4、等待视图相关DDLEVENT自我修复
我这边视图相关DDLEVENT只有5个,差不多10分钟完成自我修复。如果大家发现其长时间没有自我修复,可以仿照user表的方法进行修复,这种方法为非常规修复方法,建议大家在原厂支持的情况下进行操作,毕竟生产环境还是要小心小心再小心的。