Bootstrap

南大通用数据库-Gbase-8a-学习-44-DDLEVENT恢复

目录

一、环境信息

二、前景提要

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自我修复


一、环境信息

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

;