云数据库 GaussDB 故障案例库-3（1）
目 录
1、CN组件状态Normal-告警原因分析
- 故障现象
查询集群状态，CN组件状态为Normal，历史产生CN服务异常告警。
- 故障原因
可能原因有以下：
l 虚拟机重启产生CN服务异常告警。
l CN进程异常重启产生CN服务异常告警。
l 主动重启CN产生CN服务异常告警。
- 处理方法
步骤 1 登录告警的CN节点，切换至Ruby用户，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，集群状态正常，CN组件Normal。
步骤 2 当前节点，执行以下命令，查看操作系统是否发生过重启。
who -b
如上图表示操作系统于2022-10-20 16:47发生过重启。
如发生过操作系统重启，说明CN告警是由于操作系统重启导致，确认非人为重启后，联系华为技术支持排查操作系统重启原因。
若未重启继续向下执行。
步骤 3 当前节点，执行以下命令，查看CN进程启动时间，确认告警时段内CN是否重启。
ps ux | grep cn | grep -v grep
如上图表示，CN进程在16:03启动。
l 如果没有重启，则联系华为技术支持进一步定位。
l 若发生过重启，确认告警时间段非人为主动重启，则继续执行。
步骤 4 进入当前节点的日志路径，查看是否有ffic_gaussdb-*.log日志文件生成。
ll $GAUSSLOG/ffic_log
vim ffic_gaussdb-1669881799.log
date -d @1669881799
如上图，16:03产生了ffic_gaussdb-1669881799.log日志。
上图表明，ffic_gaussdb-1669881799.log中的时间与进程重启时间一致。
l 如告警时间点有ffic_gaussdb-*.log日志，说明CN进程发生异常重启。
打开ffic日志文件，查看ffic_gaussdb-*.log中记录的时间是否与进程重启时间对应，若时间一致，则获取ffic_gaussdb-*.log文件后，联系华为技术支持。
l 若以上时间不一致或者没有此日志，则继续向下执行。
步骤 5 查看当前CN节点的cm_agent日志。
打开对应时间点的cm_agent-***.log日志，如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志。
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log
步骤 6 在cm_agent日志中搜索关键词：restart msg。
l 如告警时间点存在此日志信息，则说明是由cm_server下发重启命令给cm_agent重启CN，详细原因，可继续在此条日志继续向上查看。
l 若不存在，继续向下执行。
步骤 7 当前节点查询集群状态，获取CMS主节点，并登录到CMS主节点。
cm_ctl query -Cvd
如上图，ecs-gaussdb-0003为CMS主节点。
步骤 8 查看cm_server日志，打开对应时间点的cm_server-***.log日志。
cd $GAUSSLOG/cm/cm_server
vim cm_server-*.log如对应时间点的日志已被压缩，则查看对应的cm_server-****.log.gz日志。
步骤 9 在cm_server日志中搜索关键词：send restart message。
l 如果存在，则说明是由cm_server主动重启CN。
l 若不存在，则联系华为技术支持。
步骤 10 若以上均不涉及，联系华为技术支持。
----结束
2、CN故障-状态Down
- 故障现象
查询集群状态，CN组件状态为Down，产生CN服务异常告警。
- 故障原因
可能原因有以下：
l 虚拟机故障产生CN服务异常告警。
l 磁盘故障导致CN组件Down，产生CN服务异常告警。
l 网卡故障导致CN组件Down，产生CN服务异常告警。
l 端口冲突导致CN组件Down，产生CN服务异常告警。
l 主动停止CN组件，产生CN服务异常告警。
- 处理方法
步骤 1 登录故障的CN节点，切换至Ruby用户，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，集群状态Degraded，CN组件Down。
l 若故障节点无法登录，则说明操作系统故障或网络等故障无法连接，需排查节点无法连接原因。
l 若可正常连接，继续向下执行。
步骤 2 当前节点，执行以下命令，查看操作系统是否发生过重启：
who -b
如上图表示操作系统于2022-10-20 16:47发生过重启。
l 如发生过操作系统重启，若非人为主动重启，需联系华为技术支持排查操作系统重启原因。
l 继续向下执行。
步骤 3 当前节点，执行以下命令，查看CN进程启动是否存在以及重启时间。
ps ux | grep cn | grep -v grep
如上图表示，CN进程在16:03启动。
l 如果进程存在，1min后再次查询集群状态，CN会恢复为Normal或者Deleted，若无变化，则联系华为技术支持进一步定位，若进程不断重启，则参考5 CN故障-启动失败章节定位。
l 若进程不存在，则继续步骤4。
步骤 4 当前节点，查看cm_agent日志，打开对应时间点的cm_agent-***.log日志。
如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志。
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log；
步骤 5 cm_agent日志中搜索关键词g_cnDiskDamage=1。
l 若存在，则原因为数据/日志磁盘损坏或磁盘满，参考步骤10。
l 若不存在，继续步骤6。
说明：
1.4(V005R001C20)版本及以前版本，搜索cn_disk_damage=1关键词，1.4(V005R001C20）以后版本搜索g_cnDiskDamage=1关键词。
步骤 6 cm_agent日志中搜索关键词port_conflict=1。
l 若存在，则原因为端口冲突，参考步骤11。
l 若不存在，继续步骤7。
步骤 7 cm_agent日志中搜索关键词g_cnNicDown=1。
l 若存在，则原因为网卡故障，参考步骤12。
l 若不存在，继续步骤8。
说明：
1.4(V005R001C20)版本及以前版本，搜索cn_nic_Down=1关键词，1.4(V005R001C20)以后版本搜索g_cnNicDown=1关键词。
步骤 8 cm_agent日志中搜索关键词cn_manual_stop=1。
l 若存在，则原因为手动停止，参考步骤13。
l 若不存在，则联系华为技术支持。
步骤 9 查看对应故障CN的磁盘是否有故障，数据目录是否存在以及权限是否正确，如无故障则检查是否磁盘满。
lsof -i:端口号
找到进程后重启进程。
kill -9 pid
须知：kill -9 pid为高危操作，执行前需联系华为技术支持确认。
步骤 12 查看是否有人手动停止，如非人为停止，则需要继续排查CMS日志，同时联系华为技术支持。
----结束
3、CN故障-状态Deleted
- 故障现象
查询集群状态，CN组件状态为Deleted，产生CN服务异常告警。
- 故障原因
可能原因有以下：
l 虚拟机重启，断网等故障导致CN被剔除，产生CN服务异常告警。
l CN与主DN断连导致CN被剔除，产生CN服务异常告警。
l CN组件Down导致CN被剔除，产生CN服务异常告警。
l CN组件频繁重启导致CN被剔除，产生CN服务异常告警。
l CN组件被主动剔除，产生CN服务异常告警。
- 处理方法
步骤 1 登录故障的CN节点，切换至Ruby用户，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，集群状态为Degraded，cn_5001被剔除，状态为Deleted。
步骤 2 当前节点，执行以下命令，查看操作系统是否发生过重启。
who -b
如上图表示操作系统于2022-10-20 16:47发生过重启。
l 如发生过操作系统重启，若非人为主动重启，需联系华为技术支持排查操作系统重启原因，故障处理后执行节点修复加回被剔除的CN。
l 继续步骤3。
步骤 3 确认主机是否发生断网等。
如有断网发生，排查断网原因，故障处理后执行节点修复加回被剔除的CN，如不涉及，继续步骤4。
步骤 4 登录到CMS主节点，查看cm_server日志。
可通过查询集群状态获取CMS主节点：
cm_ctl query -Cvd
如上图，ecs-gaussdb-0003为CMS主节点。
执行如下命令，查看日志：
cd $GAUSSLOG/cm/cm_server步骤 5 查看对应时间点的cm_server-***.log日志。
vim cm_server-*.log如对应时间点的日志已被压缩，则查看对应的cm_server-****.log.gz日志。
步骤 6 在cm_server日志中搜索有关键词cn_down_to_delete=1。
l 如对应时间点存在该信息，则原因为CN组件Down 导致，参考2 CN故障-状态Down排查详细原因，确认原因及故障解决之后，执行节点修复加回被剔除的CN。
l 如不涉及继续步骤7。
步骤 7 在cm_server日志中搜索有关键词：isCnDnDisconnected=1。
l 如对应时间点存在该信息，则原因为CN组件与主DN断连导致，此时需要排查CN与主DN之间的网络，待网络恢复后，执行节点修复加回被剔除的CN。
l 如不涉及继续步骤8。
步骤 8 在cm_server日志中搜索有关键词：cmd_disable_cn=1。
l 如对应时间点存在该信息，则原因为CN组件被主动剔除，确认剔除原因后，后执行节点修复加回被剔除的CN。
l 如不涉及继续步骤9。
步骤 9 在cm_server日志中搜索有关键词cn instance restarts within ten minutes is more than：
l 如对应时间点存在此信息，则原因为CN组件频繁重启导致，出现此种情况，参考1 CN组件状态Normal-告警原因分析进一步定位，故障处理后执行节点修复加回被剔除的CN。
l 若不存在，继续步骤10。
步骤 10 若以上均不涉及，则联系华为技术支持。
----结束
4、CN故障-状态ReadOnly
- 故障现象
查询集群状态，CN组件状态为ReadOnly状态，产生CN服务异常告警。
- 故障原因
可能原因有以下：
CN数据目录被占满。
- 处理方法
步骤 1 登录任意节点，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，集群状态为Degraded，cn_5001组件只读，状态为ReadOnly。因为多个CN之间对等，故CN只读只针对当前CN节点，因此可确定只读的CN节点。
步骤 2 登录只读的CN节点，查询磁盘使用情况。
df -h
如上图，CN所在目录的磁盘使用率为86%，超过默认85%的只读阈值。确认磁盘使用超过阈值之后，继续步骤3。
步骤 3 进入当前节点的CMS数据目录，查看修改磁盘检测参数值。
1. CMS数据目录可通过查询集群状态获取。
cm_ctl query -Cvd
如上图，/opt/gaussdb/engine/cm/cm_server CMS的数据目录。
2. 查询磁盘阈值。
cd /data/gaussdb/engine/cm/cm_server
grep 'datastorage_threshold_value_check' cm_server.conf
如上图，datastorage_threshold_value_check=85。
步骤 4 确认只读的CN节点以及参数阈值后，首先需要通过修改datastorage_threshold_value_check参数阈值，第一时间恢复业务。
gs_guc reload -Z cmserver -N all -I all -c "datastorage_threshold_value_check = 90"须知：
HCS场景执行gs_guc命令需要进入沙箱。
修改参数为高危操作，执行前需联系华为技术支持确认。
datastorage_threshold_value_check参数修改后的值需大于当前磁盘使用率，且该参数值不可设置过大，建议不超过90。
步骤 5 由于集群检测磁盘的周期默认为600s，若想要即可生效，可执行以下命令取消CN只读。
gs_guc reload -Z coordinator -N nodename -D dataPath -c 'default_transaction_read_only = off'
说明：
l HCS场景执行gs_guc命令需要进入沙箱。
l nodename为当前节点的hostname，可通过cm_ctl query -Cvd查询获取。
l dataPath为当前CN的数据目录，可通过cm_ctl query -Cvd查询获取。
步骤 6 进入到只读CN节点排查导致CN目录被占满的原因。
du - sh *l 如因数据量增长导致，则执行CN扩容或者扩磁盘。
l 如因人为上传的超大文件导致，需删除超大文件。
步骤 7 CN目录磁盘使用率恢复正常值以后，恢复datastorage_threshold_value_check参数值为85。
gs_guc reload -Z cmserver -N all -I all -c "datastorage_threshold_value_check = 85"说明：
HCS场景执行gs_guc命令需要进入沙箱。
步骤 8 若以上均不涉及，联系华为技术支持。
----结束
5、CN故障-启动失败
- 故障现象
启动集群时或者单独启动CN时，CN组件启动失败。
- 故障原因
可能原因有以下：
l 连接认证配置错误。
l CN目录权限错误或者磁盘故障。
l CN组件参数配置错误。
- 处理方法
步骤 1 登录启动失败的CN节点，执行以下命令，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，CN组件启动失败，查询状态为Down。
如上图，CN组件启动失败，查询状态为Unknown。
步骤 2 查看当前CN节点的cm_agent日志，打开对应时间点的cm_agent-***.log日志，搜索关键词ERROR或FATAL。
如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志，
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log
如上图，CN进程是运行的，但是连接失败。
l 若详细报错信息为：Invalid username/password,login denied，表明CN进程已启动，但是无法连接CMS和DN，此问题由于连接认证配置错误，需查看pg_hba.conf配置文件，此配置文件在CN数据目录下，CN数据目录可通过cm_ctl query -Cvd查询获取。
cm_ctl query -Cvd
如上图，/data/gaussdb/engine/cn为CN数据目录路径。
cd /data/gaussdb/engine/cn
vim pg_hba.conf
如上图，127.0.0.1应配置为trust认证。
说明：
/data/gaussdb/engine/cn为示例路径，需根据实际情况修改。
l 若以上都不涉及，继续步骤3。
须知：修改参数为高危操作，执行前需联系华为技术支持确认。
步骤 3 继续查看cm_agent-***.log日志，查看StartAndStop日志。
l 若详细报错信息为：g_cnDiskDamage=1，表明磁盘故障，CN无法启动，可排查CN数据目录磁盘是否正常，目录是否存在等，是否的正常读写等。
l 若以上都不涉及，继续步骤4。
如上图，无法向CN目录写数据，报错磁盘故障。
说明：
1.4(V005R001C20)版本及以前版本，搜索cn_disk_damage=1关键词，1.4(V005R001C20）以后版本搜索g_cnDiskDamage=1关键词。
步骤 4 继续查看当前目录下的system_call-current.log日志，搜索FATAL关键词。
l 若报错详细信息为：Permissions should be u=rwx(0700)，表明数据目录权限错误，可进入CN数据目录，修改权限为700。
l 若以上都不涉及，继续步骤5。
如上图，是由于CN目录的权限错误，导致CN无法启动。
修改权限命令为：chmod -R 700 /opt/gaussdb/engine/data/cn
须知：修改数据目录权限为高危操作，执行前需联系华为技术支持确认。
/opt/gaussdb/engine/data/cn为启动失败CN的数据目录。
步骤 5 继续查看当前目录下的system_call-current.log日志，搜索FATAL关键词。
l 若报错详细信息为：outside the valid range for parameter，则表明配置文件中的参数设置错误，可根据报错的参数，修改为正确的取值范围。
l 若以上都不涉及，则继续步骤6。
如上图，是由于cn_5001的recovery_time_target参数配置错误，导致CN启动失败。
gs_guc reload -Z coordinator -N all -I all -c "recovery_time_target=60"说明：
l HCS场景执行gs_guc命令需要进入沙箱。
l recovery_time_target参数为示例，实际需根据报错信息中的参数修改。
须知：修改参数为高危操作，执行前需联系华为技术支持确认。
步骤 6 继续查看cm_agent-***.log以及system_call-current.log日志，获取错误信息，联系华为技术支持。
----结束
6、DN组件状态Normal-告警原因分析
- 故障现象
查询集群状态，DN组件状态为Normal，历史产生DN服务异常告警。
- 故障原因
可能原因有以下：
l 虚拟机重启产生DN服务异常告警。
l DN进程重启产生DN服务异常告警。
l 主动重启DN产生DN服务异常告警。
- 处理方法
步骤 1 登录告警的DN节点，切换至Ruby用户，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，集群状态Normal，DN组件状态Normal。
步骤 2 当前节点，执行以下命令，查看操作系统是否发生过重启。
who -b
如上图表示操作系统于2022-10-20 16:47发生过重启。
l 如发生过操作系统重启，说明DN告警是由于操作系统重启导致，确认非人为重启后，联系华为技术支持排查操作系统重启原因。
l 若未重启继续步骤3。
步骤 3 当前节点执行以下命令查看DN进程启动时间，确认告警时段内DN是否重启。
l 如果没有重启，则联系华为技术支持进一步定位。
l 若发生过重启，确认告警时间段非人为主动重启，则继续步骤4。
ps ux|grep 'gaussdb --datanode' | grep -v grep
如上图，DN进程的启动时间为22:19。
步骤 4 进入当前节点的日志路径，查看是否有ffic_gaussdb-*.log日志文件生成。
l 如告警时间点有ffic_gaussdb-*.log日志，说明DN进程发生异常重启。
打开ffic日志文件，查看ffic_gaussdb-*.log中记录的时间是否与进程重启时间对应，若时间一致，则获取ffic_gaussdb-*.log文件，联系华为技术支持。
l 若时间不一致或者没有此日志，则继续步骤5。
ll $GAUSSLOG/ffic_log
vim ffic_gaussdb-1669904333.log
date -d @1669904333
如上图，22:18产生了ffic_gaussdb-1669904333.log日志。
上图表明，ffic_gaussdb-1669904333.log中的时间与进程重启时间一致。
步骤 5 当前节点查看cm_agent日志，打开对应时间点的cm_agent-***.log日志。
如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志。
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log步骤 6 在cm_agent日志中搜索如下关键字restart msg from cm_server。
l 如告警时间点存在此日志信息，则说明是由cm_server发送重启命令给cm_agent重启DN，详细原因，可继续在此条日志继续向上查看。
l 若不存在，继续步骤7。
步骤 7 当前节点查询获取CMS主节点，并登录到CMS主节点，查看cm_server日志。
su - Ruby
cm_ctl query -Cvd
如上图，ecs-gaussdb-0003为CMS主节点。
cd $GAUSSLOG/cm/cm_server步骤 8 查看cm_server日志，打开对应时间点的cm_server-***.log日志。
如对应时间点的日志已被压缩，则查看对应的cm_server-****.log.gz日志。
cd $GAUSSLOG/cm/cm_server
vim cm_server-*.log步骤 9 在cm_server日志中搜索关键词send restart message。
l 如果存在，则说明是由cm_server主动重启DN。
l 若不存在，则联系华为技术支持。
步骤 10 若以上均不涉及，联系华为技术支持。
----结束
7、DN故障-状态Down
- 故障现象
查询集群状态，DN组件状态为Down，产生DN服务异常告警。
- 故障原因
可能原因有以下：
l 虚拟机故障产生DN服务异常告警。
l 磁盘故障导致DN组件Down，产生DN服务异常告警。
l 网卡故障导致DN组件Down，产生DN服务异常告警。
l 端口冲突导致DN组件Down，产生DN服务异常告警。
l 主动停止DN组件，产生DN服务异常告警。
- 处理方法
步骤 1 登录故障DN节点，切换至Ruby用户，查询集群状态。
l 若故障节点无法登录，则说明操作系统故障或网络等故障无法连接，需排查节点无法连接原因。
l 若可正常连接，继续步骤2。
su - Ruby
cm_ctl query -Cvd
上图中dn_6001状态为Down。
步骤 2 当前节点，执行以下命令，查看操作系统是否发生过重启。
l 如发生过操作系统重启，若非人为主动重启，需联系华为技术支持排查操作系统重启原因。
l 若未重启，继续步骤3。
who -b
上图表明，操作系统于2022-10-20 16:47发生过重启。
步骤 3 在当前节点，查看DN进程是否存在以及进程重启时间：
l 如进程存在，则等1min后查询集群状态，DN状态会自动恢复，如未恢复，联系华为技术支持，若进程不断重启，则参考5 CN故障-启动失败章节排查。
l 如进程不存在，则继续步骤4。
ps ux | grep 'gaussdb --datanode'|grep -v grep
上图表明，dn_6001进程正常，且在16:58分启动。
步骤 4 查看故障DN节点的cm_agent日志，打开对应时间点的cm_agent-***.log日志。
如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志。
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log步骤 5 cm_agent日志中搜索关键词g_dnDiskDamage=1。
l 若存在，则原因为数据/日志磁盘损坏或磁盘满，需要查看对应故障DN的磁盘是否有故障，如无故障则检查是否磁盘满或者数据目录是否被删除，是否被重命名以及目录读写权限是否都正确。
l 如以上都不涉及，则继续步骤6。
如上图，dn_6001 dn_disk_damage=1。
说明：
1.4(V005R001C20)版本及以前版本，搜索dn_disk_damage=1关键词，1.4(V005R001C20)以后版本搜索g_dnDiskDamage=1关键词。
步骤 6 cm_agent日志中搜索关键词port_conflict=1。
l 若存在，则原因为端口冲突，参考步骤9。
l 若以上都不涉及则继续步骤7。
如上图，dn_6003 port_conflict=1。
步骤 7 cm_agent日志中搜索关键词g_nicDown=1。
l 若存在，则原因为网卡故障，参考步骤10。
l 若以上都不涉及则继续步骤8。
如上图，dn_6006 g_nicDown=1。
说明：
1.4(V005R001C20)版本及以前版本，搜索dn_nic_Down=1关键词，1.4(V005R001C20)以后版本搜索g_nicDown=1关键词。
步骤 8 cm_agent日志中搜索关键词dn_manual_stop=1。
l 若存在，则原因为主动停止，参考处步骤11。
l 若不存在，则联系华为技术支持。
如上图表明，dn_6001 dn_manual_stop=1。
lsof -i:端口号
找到进程后，强制结束进程。
kill -9 pid须知：kill -9 pid为高危操作，执行前需联系华为技术支持确认。
步骤 11 确认是否有人手动停止，如非人为停止，则联系华为技术支持，排查cms日志。
----结束
8、DN故障-状态Unknown
- 故障现象
查询集群状态，DN组件状态为Unknown，产生DN服务异常告警。
- 故障原因
可能原因有以下：
cm_agent无法连接DN。
- 处理方法
步骤 1 登录故障DN节点，切换至Ruby用户，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，dn_6008状态为Unknown。
步骤 2 如DN长时间处于Unknown状态，如需要快速恢复，则可使用以下命令处理，如需要先定位则跳过此步骤。
1. 查询故障DN的PID
ps ux | grep dn_6008 | grep -v grepdn_6008为示例，实际执行时需要更换为当前故障的DN。
2. 重启DN进程。
kill -9 pidpid为当前Unknown状态DN的进程的pid。
须知：kill -9为高危操作，执行前需联系华为技术支持确认。
步骤 3 查看当前节点的cm_agent日志，打开对应时间点的cm_agent-***.log日志。
如对应时间点的日志已被压缩，则查看对应的cm_agent-****.log.gz日志。
cd $GAUSSLOG/cm/cm_agent
vim cm_agent-*.log步骤 4 cm_agent日志中搜索关键词1 timeout expired。
l 如存在，表明cm_agent连接不到DN，继续步骤5。
l 如不存在，则联系华为技术支持。
步骤 5 当前节点执行以下命令，获取故障DN的堆栈信息，并联系华为技术支持。
gs_ctl stack -D datapath > /home/omm/dn_6008_stack.log
l 2.1(V500R002C10)以后版本，可使用gs_stack命令将堆栈信息重定向到指定文件。
l datapath为当前DN的数据目录，可通过cm_ctl query -Cvd获取。
l HCS场景，执行gs_stack需要进入沙箱。
步骤 6 若以上都不涉及，联系华为技术支持。
----结束
9、DN故障-状态ReadOnly
- 故障现象
查询集群状态，DN组件状态为ReadOnly，产生DN服务异常告警
- 故障原因
可能原因有以下：
DN数据目录磁盘使用超过阈值。
- 处理方法
步骤 1 登录任一节点，查询集群状态。
su - Ruby
cm_ctl query -Cvd
如上图，DN组件全部ReadOnly。
步骤 2 当前DN节点，查看磁盘空间分配情况，查看各DN节点DN数据目录所在磁盘空间使用率。
gs_ssh -c "df -h"
如上图为集群内所有节点的磁盘使用情况。
说明：
HCS场景，执行gs_ssh命令需要进入沙箱。
步骤 3 进入当前节点的CMS数据目录，查看修改磁盘检测参数值。
CMS数据目录可通过查询集群状态获取。
cm_ctl query -Cvd
如上图，/opt/gaussdb/engine/cm/cm_server CMS的数据目录。
cd /data/gaussdb/engine/cm/cm_server
grep 'datastorage_threshold_value_check' cm_server.conf
如上图，datastorage_threshold_value_check=85。
说明：
HCS场景，执行gs_ssh命令需要进入沙箱，或者数据目录前加/var/chroot。
步骤 4 确认磁盘使用率超过阈值的DN节点后，首先需要通过修改datastorage_threshold_value_check参数阈值，第一时间恢复业务。
gs_guc reload -Z cmserver -N all -I all -c "datastorage_threshold_value_check = 90"须知：
l HCS场景，执行gs_ssh命令需要进入沙箱。
l 修改参数为高危操作，执行前需联系华为技术支持确认。
l datastorage_threshold_value_check参数修改后的值需大于当前磁盘使用率，且该参数值不可设置过大，建议不超过90。
步骤 5 由于集群检测磁盘的周期默认为600s，若想要即可生效，可执行以下命令取消DN只读。
gs_guc reload -Z datanode -N nodename -D dataPath -c 'default_transaction_read_only=off'
说明：
l HCS场景，执行gs_ssh命令需要进入沙箱。
l nodename为当前节点的hostname，可通过cm_ctl query -Cvd查询获取。
l dataPath为当前CN的数据目录，可通过cm_ctl query -Cvd查询获取。
步骤 6 进入到只读DN节点排查导致DN目录被占满的原因。
du - sh *l 如因数据量增长导致，则执行DN扩容或者扩磁盘。
l 如因人为上传的超大文件导致，需删除超大文件。
步骤 7 DN目录磁盘使用率恢复正常值以后，恢复datastorage_threshold_value_check参数值为85。
gs_guc reload -Z cmserver -N all -I all -c "datastorage_threshold_value_check = 85"说明：
HCS场景，执行gs_ssh命令需要进入沙箱。
步骤 8 若以上均不涉及，联系华为技术支持。
----结束
10、DN故障-状态Need repair
- 故障现象
查询集群状态，DN组件状态为Need repair，产生DN服务异常告警。
- 故障原因
可能原因有以下：
l 主DN故障，备DN在redo过程中无法接收主机日志，出现Need repair状态。
l 网络异常，备DN无法与主DN正常连接，出现Need repair状态。
l 备DN进程故障重启，出现Need repair状态。
- 处理方法
步骤 1 登录故障DN节点，切换至Ruby用户，查询集群状态，确认分片是否满足多数派。
su - Ruby
cm_ctl query -Cvd
如上图，第一个DN分片不满足多数派。
l 查询集群状态，分片内无主，不满足多数派，联系华为技术支持。
l 查询集群状态，分片有主，分片内主+备DN数量小于分片内DN总数的一半，不满足多数派，参考12 DN故障-多数派故障章节处理。
l 查询集群状态，分片有主，分片内主+备DN数量大于分片内DN总数的一半，继续步骤2。
步骤 2 登录Need repair状态备DN节点，排查备DN进程是否重启。
ps ux | grep 'gaussdb --datanode'|grep -v grep
上图表明，dn_6008进程在10:30分启动。
l 若有过重启，参考6 DN组件状态Normal-告警原因分析章节，排查DN重启原因。
l 若无重启，继续步骤3。
步骤 3 当前节点查看DN日志，搜索terminating walreceiver due to heartbeat timeout关键词。
如能搜索到对应时间点的日志，表明备DN与主DN发生过断连，继续步骤4。
cd $GAUSSLOG/pg_log
grep 'terminating walreceiver due to heartbeat timeout' *
如上图，表明备DN无法正常接收主DN的日志。
步骤 4 登录当前分片的主DN节点，排查主DN 进程是否有重启。
ps ux | grep dn|grep -v grep
上图表明，dn_6008进程在10:30分启动。
l 若有过重启，参考6 DN组件状态Normal-告警原因分析章节，排查DN重启原因。
l 若无重启，继续步骤5。
步骤 5 排查当前DN分片是否有主备切换，可在新主DN的cm_agent日志中搜索关键词failover msg from cm_server。
l 若存在，表明是由cm_server仲裁主备切换。
l 若不存在，继续步骤6。
步骤 6 确认主DN节点和备DN节点之间网络是否正常，可分别在主备DN节点执行ping命令，注意需使用主备节点对等的IP。
ping -I 出口IP 目的IP说明：
IP通过cm_ctl query -Cvd查询获取，HCS及公有云环境也可通过DBS运维管理平台实例明细界面获取。
步骤 7 若以上均不涉及，联系华为技术支持。
因篇幅原因，前10小节在此处，更多内容请移步：云数据库 GaussDB 故障案例库-3（2）
- 点赞
- 收藏
- 关注作者
评论（0）