1. 适用场景
1) 长时间或者不正确使用的系统表会堆积大量的脏数据，造成系统表膨胀，影响数据库的性能，故需要定期清理系统表。
2. 前提条件
1) GaussDB A集群安装成功，且处于已启动状态。
2)集群状态正常，显示为normal。
3. 对系统影响
操作过程会关闭白名单，禁止业务接入。
4. 实施步骤
4.1准备工作
4.1.1检查集群状态
步骤1 以Ruby用户登录GaussDB A集群的第一个正常的cn节点
步骤2 执行以下命令，启用环境变量
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile |
步骤3 执行以下命令，查看GaussDB A集群当前状态
| cm_ctl query |
如下则为正常
| [ Cluster State ]
cluster_state : Normal redistributing : No balanced : Yes |
步骤4 如果不满足以上状态，则联系华为工程师处理
4.1.2排查老事务
参考以下链接：
https://bbs.huaweicloud.com/forum/thread-153148-1-1.html
4.2关闭集群通信白名单
步骤 1 现场实施人员知会并确认用户已完成数据库业务停止操作。
步骤 2 以Ruby用户登录第一个正常的CN节点，执行如下命令注释用户白名单
以默认CN实例目录/DWS/data1/coordinator为示例，现场需根据实际情况进行调整。
| gs_guc set -Z coordinator -Z datanode -N all -I all -h “host all all 0.0.0.0/0” |
步骤 3 以Ruby用户登录第一个正常的CN节点，关闭DWS实例节点下的后台访问连接和应用连接。具体操作如下：
| gs_ssh -c “ps ux |grep -w gsql |grep -v grep |awk ‘{print \$2}’ |xargs -r kill -9”
gs_ssh -c “ps ux |grep -w ap_agent |grep -v grep |awk ‘{print \$2}’ |xargs -r kill -9” |
步骤 4 以Ruby用户登录每一个CN节点，执行如下命令重启CN。
执行以下命令，获取到CN的进程Pid
| ps -ef | grep /DWS/data1/coordinator | grep -v grep |
执行以下命令，杀死CN进程
| kill -9 Pid |
执行以下命令，观察CN被重新拉起，并且Pid与之前获取的Pid不同
| ps -ef | grep /DWS/data1/coordinator | grep -v grep |
4.3清理pg_class
4.3.1查询内核版本
步骤1以Ruby用户登录任一CN节点，执行如下命令：
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile
gsql -V |
执行结果，示例如下：
| gsql (GaussDB 8.0.0 build e44e33ab) compiled at 2020-07-30 18:00:55 commit 7768 last mr 13325 |
8.0.0为内核版本
4.3.2查询表数量
步骤1以Ruby用户登录任一CN节点，分别连接所有数据库，执行如下命令，db_name为数据库名字
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile
gsql -d db_name -p 8000 -U dbadmin -W password -c “select count(1) from pg_tables;” |
执行结果，示例如下：
| count
——- 960 (1 row) |
960为表数量
4.3.3查询pg_class索引位置
步骤1以Ruby用户登录任一CN节点，连接所有数据库，执行如下命令，db_name为数据库名字
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile
gsql -d db_name -p 8000 -U dbadmin -W password -c “select xmin,xmax,ctid from pg_class where oid = 2662;” |
执行结果，示例如下：
| xmin | xmax | ctid
——+——+——– 2 | 0 | (21972,3) (1 row) |
21972为索引位置
4.3.4清理pg_class
清理pg_class需要满足以下2个条件中的1个
- >4.3.1查得数据库版本不低于8.0.0.9，且数据库版本不为8.1.0
- >4.3.2查得，表的数量小于10万；并且>4.3.3查得，pg_class的索引位置小于10万
| 说明
如果以上2个条件都不满足，则不用执行清理pg_class后续步骤，可以直接执行>4.4清理其他系统表。 |
步骤1以Ruby用户登录任一CN节点，连接所有数据库，执行如下命令，db_name为数据库名字
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile
gsql -d db_name -p 8000 -U dbadmin -W password -c “set synchronize_seqscans=off; VACUUM FULL FREEZE PG_CLASS;analyze PG_CLASS;” |
4.4清理其他系统表
步骤1以Ruby用户登录任一CN节点，连接所有数据库，执行如下命令，db_name为数据库名字
| source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile
gsql -d db_name -p 8000 -U dbadmin -W password -c “set synchronize_seqscans=off;VACUUM FULL FREEZE PG_ATTRIBUTE;VACUUM FULL FREEZE PG_DEPEND; VACUUM FULL FREEZE PG_PARTITION;VACUUM FULL FREEZE PG_PROC;VACUUM FULL FREEZE PG_STATISTIC;VACUUM FULL FREEZE pgxc_class;VACUUM FULL FREEZE pg_index;analyze PG_ATTRIBUTE;analyze PG_DEPEND; analyze PG_PARTITION;analyze PG_STATISTIC;analyze pgxc_class; “ |
4.5恢复集群通信白名单
步骤1 以Ruby用户登录第一个正常的CN节点，执行如下命令注释用户白名单
以默认CN实例目录/DWS/data1/coordinator为示例，现场需根据实际情况进行调整。
| gs_guc set -Z coordinator -N all -I all -h ‘host all all 0.0.0.0/0 sha256’ |
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/bigdata/316754.html