提问：作为DBA运维的你，是否有过这些烦恼

作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难

说了这么多理论，想必实战更让你心动。那我们就拿一个真实项目案例进行分析---某运营商客户业务系统测试环境下，项目开发人员某日早上发现GreatDB数据库高可用集群无法连接，该如何快速分析处理：

1、故障发生场景

在项目现场兢兢业业进行项目开发的你，正在为某个客户部署安全数据库GreatDB数据库集群，却在应用测试阶段，发现GreatDB高可用集群无法连接，对现场情况和原因不太清楚。

2、故障排查

通过SSH工具远程登录shell，查看数据库集群所有服务状态，如下：

项目开发人员连接192.*.*.1节点3307端口，该端口对应的router进程异常，导致该IP无法提供数据库服务。虽然数据库整体服务正常，但是应用连接的节点不可用，导致服务中断。

3、故障分析0

1）获取错误日志

从主机192.*.*.1的/greatdb/routerdata/logs获取router日志

2）分析错误日志

查看错误日志，发现router服务每5分钟重启一次

3）查询router服务重启原因

主机192.*.*.1节点的dbscale_daemon.py程序，调用GreatDB命令检测router状态，代码如下：

查看dbscale_daemon.py脚本内容

脚本中直接调用GreatDB命令，而GreatDB命令不在PATH环境变量中，无法直接执行

由于GreatDB命令无法直接执行，192.*.*.1节点的dbscale_daemon.py程序返回状态错误，误认为router不在线，因此自动执行重启router。

4）查看其他两个节点的router状态

由于192.*.*.1节点与其他节点启动router的方式不一样，导致进程也不一致。

4、故障处理

遇到这类故障，小编给大家提供2种解决思路：一种是遇到故障后的紧急处理方案，可以让节点实现快速连接，解决当下燃眉之急。但从长远看，大家更需要常规处理方案，从根源上解决故障问题发生。

1）紧急处理方案

操作：使用dbscale-service.sh脚本重启router进程，优先恢复router服务。

问题分析：在诊断192.*.*.1节点router进程异常的情况下，我们发现问题的根源在于节点的启动方法不统一。其中一个是由【dbscale_daemon.py】启动的，而其他节点则使用【dbscale-service.sh】启动。

2）常规处理方案及改进措施

常规处理方案：

1、192.*.*.1节点使用dbscale-service.sh脚本启动router服务

su - greatdb
cd /greatdb/routerdata/
./dbscale-service.sh start

2、安装GreatDB数据库客户端

3、添加主机PATH环境变量等

遇到这种数据库连接中断的线上故障，紧急处理方案可以帮助大家暂时解决问题，只有常规处理方案才能从根源上解决故障问题发生。