背景介绍

常用日志目录如下

加载环境变量：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile

查看build相关日志：$GAUSSLOG/bin/gs_ctl

查看是否kill实例等：$GAUSSLOG/cm

实例状态异常（down、starting、need repair）$GAUSSLOG/pg_log

HA 常用操作：

https://bbs.huaweicloud.com/forum/thread-78789-1-1.html

1、单个实例异常状态，集群处于降级状态

【处理思路】

对于单个实例故障问题从故障实例日志入手看报错原因，参考以下几个案例。

1.1查看该实例日志是否有报错或者不断重启：

1.1.1 磁盘坏道

【问题描述】

查看集群状态该实例处于down unknown状态，集群降级状态

【问题分析】

查看异常实例状态有以下报错：

FATAL:  could not read block 9363 in file "base/4207289/25155327": Input/output error

该报错一般由于磁盘坏道导致实例状态异常，按照以下方式进行修复即可

【修复方案】

前提：ls 该文件没有报错的话按照以下方案进行修复，会有集群短暂不可用情况，需要跟客户提前沟通清楚
1）停6113实例完再停6114实例
2）mv 6113实例报错文件至data1（不要删除）
3）从6114拷贝对应文件至6113实例
4）起6114待升主后，拉起6113实例做完catchup后做switchover

1.1.2 两阶段文件残留引起实例不断重启

【问题描述】

查看集群状态实例处于down starting状态，集群状态降级。

【问题分析】

查看该实例日志报错如下：

could not open file "pg_clog/0086": No such file or directory

 该报错由于 2PC commit与checkpoint并发导致两阶段文件残留，后续长时间运行CLOG文件被回收，实例重启时redo线程会督导残留的两阶段文件，此时clog文件已经被清理导致实例无法起来。

【修复方案】

手动删除2PC残留文件：140534361转为16进展为8606259，进入实例目录pg_twophase删除该文件即可

出现次数：2

1.2判断实例是否做redo

【问题描述】

实例长期处于need repair状态，kill实例没有效果，集群处于降级状态。判断实例是否做redo可按照以下方式进行判断

【问题分析】

方式一：查看该实例堆栈是否有redo线程存在：gstack $pid

方式二：连接该备DN产看redoLSN位置，select pg_last_xlog_replay_location()

重复查询该值如果有变化说明在做redo

方式三：查看该实例正在redo哪个xlog文件

lsof -p $pid | grep 00000*

附：

判断还有多少xlog需要redo

方式一：进入该备DN实例目录pg_xlog路径查看最新XLOG LSN位置，ll -thr|tailf -n 10

根据查询redo方式二查询到目前redo到8F5，通过ll命令查到最新xlog为8F9，差一个数xlog大小为4G，此时还有16G（4*4）的xlog未同步

方式二：查看正常实例同步及备机redo进度，gs_ctl query -D 实例目录

主机最新xlog为8EE，目前备机redo位置为8E8，目前还有24Gxlog未redo

【问题修复】等redo结束即可

1.3 kerbos认证不通过

【问题描述】

实例处于standby need repair(disconnect)状态，集群降级。

【问题分析】

查看该dn日志有gss相关报错：

经了解该局点进行过替换主板变更，替换主板后，加密TPM换成新主机相关信息，之前存的文件加载到内存后，解析有误造成实例建联认证失败。对于更换主机，但是没换硬盘的，要手动刷新下票据。

【问题修复】

1） crontab –l |grep krb

2） 重新刷新票据

/opt/huawei/Bigdata/FusionInsight_BASE_6.5.1/install/FusionInsight-kerberos-1.17/kerberos/bin/kinit -k -t /opt/huawei/Bigdata/mppdb/auth_config/mppdb.keytab mppdb/hadoop.hadoop.com@HADOOP.COM

 

附：

1） kerbos认证相关问题排查步骤

http://3ms.huawei.com/km/blogs/details/8697907?l=zh-cn

2）后台手动关闭kerbos

gs_ssh -c "gs_om -t kerberos -m uninstall -U omm"

从后台开启kerbos

gs_ssh -c "gs_om -t kerberos -m install -U omm"

注：正常关闭kerbos认证需要从前台页面进行关闭，需要重启集群；该方式从后台关闭kerbos不需要重启集群但是会有前后台不一致的问题，请衡量后使用。

1.4 IO异常

该案例仅供排查IO类问题参考

【问题描述】

单节点IO高，查看等待视图有waitIO情况出现。

select * from pgxc_thread_wait_status where query_id != 0 and wait_status != 'none';

【问题分析】

IO高问题可以从以下几个方面进行分析

1）数据倾斜；

查看视图：select table_skewness('表名');或者看实例路径数据大小

2）单实例下小文件太多，正常有几十万几百万，有上千万的情况就需要注意

连接该dn实例使用 select * from pg_relation_filenode('表名');查看

3）raid缓存策略问题：一般我们要求设置为write-back/write-back-BBU（有的可能会设置成write-through，这种会导致读写较慢不建议设置）————修改raid缓存策略

4）慢盘问题

查看两组实例所在节点IO状态发现IO比较繁忙，但是读写数据量不大IOPS较高

【修复方案】

读写策略问题联系硬件工程师修改读写策略即可；慢盘问题联系硬件工程师进行修复。 

2、集群不可用，实例分别处于 standby promoting、pending need repair

【处理思路】

查看standby promoting实例无法成功升主原因采取相应修复方式，具体参考以下案例。

2.1 复制槽满升主无法成功

【问题描述】

集群不可用，查看集群状态实例6045处于pending need repair 6046实例处于standby promoting

 

【问题分析】

查看standby promoting dn6046日志报错如下：

查看从备3024日志报错

FATAL:  number of requested standby connections exceeds max_wal_senders (currently 4)：

信号响应函数未生效，导致从备的datareceiver线程未退出，引起 failover 失败，后续备机升主继续连接从备请求同步数据引起从备实例复制槽满报错。

【修复方案】

常见于651版本

方案一：kill 从备让其升主

方案二：强制让原主实例升主

注意做强制升主操作时必须确定对应实例之前是主实例，请联系华为工程师进行操作

手动停止promoting实例后执行以下命令

kill -9 pid; sleep 5;gs_ctl notify -M primary -D 原主实例路径

2.2 连接故障从备导致升主未成功

【问题描述】

集群不用查看集群状态dn6027处于pending need repair状态，dn6028处于standby promoting状态

 

 【问题分析】

查看dn6028日志，升主过程中一直在连接从备，此时从备磁盘故障因此无法升主成功

【修复方案】

kill dn6028后自动连接dn6027升主成功

2.3 与从备同步xlog CRC校验不过升主失败

【问题描述】

集群状态不可用，dn6019处于down starting，dn6020处于 standby promoting状态

【问题分析】

查看dn6020日志提示与从备存在日志分叉：

FATAL:  invalid crc on secondary standby, has xlog, standby promote failed

【修复方案】

在从备实例目录下pg_xlog文件删除该xlog文件（将该文件移到其他路径）

注意该方式可能造成数据丢失，是一种有损恢复方式，操作前必须与客户达成一致。

 3 单个实例处于build failed状态

【问题描述】

实例处于build failed状态

【问题分析】

一般增量build失败查看gs_ctl日志报错提示，一般有以下几个原因：

1）xlog被回收

2）build过程中与主机网络断连（主机故障或者网络原因）

【修复方案】

通过全量build进行修复（全量build命令详见HA常见操作）

4、xlog积压引起磁盘满

4.1复制槽残留引起xlog积压

【问题描述】

实例路径下xlog文件有几百G未能及时回收

【问题分析】

一般情况下xlog会在checkpoint之后进行回收，对该问题分析如下：

1）     连接该dn查看复制槽情况

select * from pg_get_replication_slots();

xlog回收机制会回收restart_lsn之前的xlog（代表在此之前的xlog已经同步到备机），对应该案例中51之后的xlog都不会回收因此造成xlog积压。

dn_6393_3198为老实例产生的复制槽路径，可以通过当前主实力编号判断

【修复方案】

删除无效复制槽

select pg_drop_replication_slot('dn_6393_3198');

select pg_drop_replication_slot('dn_6393_6394');

以上步骤执行完等checkpoint后xlog回收即可

4.2逻辑复制槽引起xlog

【问题描述】

实例路径下xlog日志大小异常788G，并且在持续增长

【问题分析】

连接该dn查看复制槽使用情况：

客户创建逻辑复制槽未及时推进导致xlog没有及时回收，跟客户沟通后属于数据业务侧逻辑进行整改。

【修复方案】业务侧排查逻辑复制槽未及时推进原因

4.3 业务侧带索引导入等操作短时间内产生大量xlog

【问题描述】

业务语句反应较慢，查看集群状态有部分实例处于catchup状态

【问题分析】

1）产生catchup的场景一般都是由于业务业务压力较大主备需要同步数据或者xlog文件，使用ll -htr查看实例路径下xlog文件发现2min生成20+xlog文件

2）使用pg_xlogdump解析其中一个xlog文件，发现该xlog文件都为带索引导入业务

从xlog文件中可以看到该导入业务数据库OID与表OID分别为49233与927405

通过以下命令查到该表对应数据库、schema与表名

select * from pg_data where oid = 49233;

select * from pg_class where relfilenode = 927405;

select * from pg_namespace where oid = 50158

4）查看表定义未带索引导入表定义

【修复方案】

建议客户删除索引入库，完成入库后创建索引。如果频繁入库会导致IO等压力、影响事务提交、xlog积压等问题

4.4 checkpoint失败引起xlog堆积

【问题描述】

连接cn执行checkpoint操作不成功

【问题分析】

查看实例日志是否有invalid page或页损坏报错。

 

5、catchup长时间不结束

查看追赶视图长时间有日志或数据页追赶

select * from pgxc_get_senders_catchup_time();

5.1 BCM文件残留

【问题描述】

Catchup长时间未结束

【问题分析】

1）查看主节点日志catchup线程一直重启：

日志报错找对应的数据文件找不到/15681/50683520，此时怀疑是bcm文件残留，寻找不存在的relfilenode文件

2）查找pg_class中是否有relfilenode为图中的表以及数据目录是否有对应文件

发现确实不存在对应的表和文件，基本可以确定是bcm文件有残留

【修复方案】

1）通过以下命令排查残留BCM文件

for file in `find  .  -iname  "*_bcm" | awk -F '_' '{print $1}' | sed 's/\.//g'  | sed 's/\///g'` ;  do  if [ ! -e $file ]; then echo "$file"; fi   ; done > bcm.log

2）清除残留BCM文件

for bcmname in `cat res.log` 
do  
echo $bcmname
for filepath in ` find . -name "$bcmname"* | grep bcm ` 
do
echo "$filepath" ;
mv "$filepath" /home/omm/tmp ;
done
done

5.2 与DML语句抢锁

【问题描述】

查看追赶视图长时间有日志或数据页追赶

select * from pgxc_get_senders_catchup_time();

【问题分析】

catchup要加7级锁，update与insert加3级锁，3级锁和7级锁冲突，现网一直有大批量的update业务，导致catchup一直在等锁，查看主dn日志有锁超时日志：

Lock wait timeout

【修复方案】

1）查看活跃视图

select * from pg_stat_activity where state = 'active';

2）强制杀掉执行超过20分钟的语句（或与客户沟通停止业务等待catchup结束）

select pg_terminate_backend($pid); 

出现次数：4

6、主备切换长时间不成功

【问题描述】

执行主备切换后长时间未成功，查询集群状态原主一直处于primary demoting状态，原备处于standby wait promoting状态

【问题分析】

查看原主实例卡在停止业务线程

【修复方案】

Kill demoting实例进行回退待业务低峰期进行重新操作

 

7、实例异常分析

实例异常退出造成集群出现短暂不可用主要包括以下几个场景

7.1进程被os oom kill

gaussdb的进程使用过多内存资源被os kill，可以通过查看/var/log/messages日志进行排查（搜kill关键字），同时排查参数max_process_memory设置是否过大

7.2 进程主动退出

需要查看具体的pg_log，看看退出原因

7.3 进程core

【问题描述】

集群有某个dn不间断异常处于need repair状态

【问题分析】

通过观察该节点有core文件产生，解析core文件，打印堆栈如下：

【修复方案】根据core文件找出异常sql进行优化即可。

注意：需要配置os core，生产core文件进行定位。

 

7.4被CMA kill

【问题描述】

业务短暂中断，查看集群状态有实例处于build状态

【问题分析】

网络原因6491长时间未上报状态信息，对端实例6492上报对端状态实例未down状态（实际还在运行），CMS下发failover流程，对端升主成功之后，此时6491上报自己状态为主，对端实例角色为主，出现双主情况，CMS下发消息kill 6491实例（kill原则静态角色为备机），此时对应6491第一次被kill情况；6491被重新拉起后上报状态出现日志分叉，CMS触发增量build，此时对应查看集群6491为build状态。

【修复方案】自恢复

可以看对应时间点是否有CMA kill实例日志

 

8 、日志总结：

8.1 switchover

备机：

1）收到switchover信号：to do switchover

2）给主机发送switchover信号：send fast switchover request to primary

3）设置自身状态为waiting_state,等待主机降备：set db_state to WAITING_STATE in gaussdb state file

4）收到主机降备消息：received switchover response message from primary

5）设置自身状态为promoting_state，进行升主：set db_state to PROMOTING_STATE in gaussdb state file

 

主机：

1）收到备机switchover消息：received fast switchover request from standby

2）停止当前活跃事务：aborting any active transactions

3）停止连接：terminating connection due to administrator command

4）停止业务线程：could not fork new process for connection:postmaster is shutting down

5）给备机发送switchover响应消息：sending switchover response message

6）关闭所有线程，重新进行初始化：all server processes terminated; reinitializing

 

8.2 Failover

备机：

1）收到failover消息：received failover notification

2）向备机请求数据：request xlog stream at 0/4057290

3）设置自身状态为promoting状态：set db_state to PROMOTING_STATE in gaussdb state file

4）备机连接从备：data streaming replication successfully connected to primary

5）同步完从备日志：invalid crc on secondary standby, no xlog, standby will promoting primary

6）同步完从备数据后开始升主：sync Secondary Standby data done

8.3实例重启日志

正常情况下会切换日志文件

Initialize Communication Layer