数据库连接异常问题排查
问题描述
客户反馈应用端连接数据库异常，报错截图如下：“已超过了锁请求超时时段”。
问题排查
1、测试端口联通性
从应用侧服务器上分别测试数据库服务端口联通性，检测服务正常监听
2、数据库服务器重启
同客户沟通优先恢复业务，反馈先对数据库服务器重启 
重启后连接数据库仍然异常
3、查询活跃/阻塞会话
根据报错提示查询活跃及阻塞会话，看下是否有事物没有提交。查询无阻塞会话
查询活跃会话：
SELECT s.name, DES.program_name, r.session_id, r.status, qt.text, qt.dbid , qt.objectid, r.cpu_time, r.total_elapsed_time, r.reads, r.writes , r.logical_reads, r.scheduler_id FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(sql_handle) qt JOIN master.dbo.sysdatabases s ON r.database_id = s.dbid JOIN sys.dm_exec_sessions DES ON r.session_id = DES.session_id ORDER BY r.scheduler_id, r.status, r.session_id;
查询阻塞会话，用activity monitor，查看会话信息，是否有未提交事务
SELECT Blocking.session_id as BlockingSessionId, Sess.login_name AS BlockingUser, BlockingSQL.text AS BlockingSQL, Waits.wait_type WhyBlocked, Waits.wait_duration_ms, Blocked.session_id AS BlockedSessionId, USER_NAME(Blocked.user_id) AS BlockedUser, BlockedSQL.text AS BlockedSQL, DB_NAME(Blocked.database_id) AS DatabaseName FROM sys.dm_exec_connections AS Blocking INNER JOIN sys.dm_exec_requests AS Blocked ON Blocking.session_id = Blocked.blocking_session_id INNER JOIN sys.dm_os_waiting_tasks AS Waits ON Blocked.session_id = Waits.session_id RIGHT OUTER JOIN sys.dm_exec_sessions Sess ON Blocking.session_id = sess.session_id CROSS APPLY sys.dm_exec_sql_text(Blocking.most_recent_sql_handle) AS BlockingSQL CROSS APPLY sys.dm_exec_sql_text(Blocked.sql_handle) AS BlockedSQL ORDER BY BlockingSessionId, BlockedSessionId
查看没有活跃会话（由于已经重启了数据库服务器，建议在重启数据库服务器前执行SQL查询）
4、核实云安全中心告警
云安全中心在2023-02-21 20:18时刻服务器 Prod-Samsonite-Baison-APP01-Linux（ 192.168.40.103） 的可疑蠕虫脚本行为告警，创建隐藏目录。该行为已被云安全中心拦截成功。执行命令 mkdir /tmp/.baisonagent ,同业务方核实是否是正常业务操作。登录到服务器上，检查目录没有创建成功
5、查看系统日志
在 Linux 系统中，日志文件记录了系统中包括内核、服务和其它应用程序等在内的运行信息。 查询/var/log/messages日志信息，日志文件大小为0
journalctl -xe -l 查询到有实时日志输出
journalctl -xe -l
查看应用服务器版本为 CentOS 7.9
在 CentOS 7中，日志是使用rsyslogd守护进程进行管理的，该进程是之前版本的系统中syslogd的升级版，对原有的日志系统进行了功能的扩展，提供了诸如过滤器，日志加密保护，各种配置选项，输入输出模块，支持通过 TCP 或者 UDP 协议进行传输等。
rsyslog的配置文件为 /etc/rsyslog.conf , 日志文件都位于 /var/log/ 目录中, 系统默认有设置对messages日志做切割。
登录到 192.168.40.103 服务器上 查看 /etc/rsyslog.conf 文件内容 ，对比同系统的另外一台服务器中 /etc/rsyslog.conf内容 ，对比发现没有输出messages日志的上注释掉了参数
$ModLoad imjournal 、$IMJournalStateFile imjournal.state
备注说明：
$ModLoad imjournal # imjournal为模块名，支持对系统日志的访问。 $IMJournalStateFile imjournal.state #将日志存储在文件中 |
将相关参数注释取消后重启服务日志正常记录,messages系统日志没有打印是因为修改了 /etc/rsyslog.conf 部分参数
systemctl restart rsyslog.service
日志内容实时输出
查看192.168.40.104 服务器上/etc/rsyslog.conf 文件修改时间为 2022-10-13 15:15
查看192.168.40.105服务器上/etc/rsyslog.conf 文件修改时间为 2022-10-13 13:54
核实三台服务器均有操作注释参数 $ModLoad imjournal 、$IMJournalStateFile imjournal.state
6、查看堡垒机历史执行记录
查询 /etc/rsyslog.conf 修改当天（2022-10-13）的审计会话信息， 在三台服务器上有执行安装k8s_install.sh脚本操作
总结建议
1、复现数据库死锁问题时，先不执行重启服务器操作，登录数据库查询活跃/阻塞会话，查看是否存在阻塞
2、应用程序侧输出打印日志信息，协助问题定位
3、开启messages日志记录，并且做好超过文件大小定期自动清理，k8s组件日志调整级别，输出重要日志，避免日志量过大导致磁盘可用空间不足
4、问题复现时候配合抓包分析
