安全研究 >> 安全研究详情

运维日记|这都能失败?我太“南”了!

作者: 美创运维中心数据库服务团队发布日期: 10月25日


一个阳光明媚的午后,笔者正惬意的午休着。突然,一个电话镖进来了!接着,XX客户反馈,有套MySQL数据库连不上了!!笔者一听,心里瞬间一紧,靠,不会是生产库又出什么幺蛾子了吧?!这大白天的,7*24系统,“玩不起”啊……



没事,稳住!天塌不下来。



经详细了解,确认了客户生产系统正常运行,只是某个客户端连接异常。局部的连接问题(小事!),处理起来比较简单和轻松。不过该客户的问题有点“妖”、有点意思,一般还真想不到!!

我们先来看下客户那边具体的报错:

shell> mysql57

ERROR 1045 (28000): Access denied for user 'backup'@'192.168.238.174' (using password: YES)

乍一看,怎么用这种方式连接,有点奇怪?!回头一想,估计是客户为了方便,把登录的操作用shell脚本封装过了,我们把这个shell打开看看:

shell> cat /usr/bin/mysql57

#!/bin/bash

source /etc/profile

export MYSQL_HISTFILE=$HOME/.mysql57_history

export MYSQL_HOST=192.168.239.51

export MYSQL_PWD=backup

export MYSQL_TCP_PORT=3307

mysql -ubackup

果不其然讷,在该shell中定义了目标主机、密码和访问端口。一般命中MySQL 1045错误的场景,原因无非是以下几类:

一、用户问题

二、密码问题

三、端口问题

四、网络问题

简单吧,在troubleshooting时,可以尽量往这几个大方向靠拢,问题应该不难定位。行吧,话不多说,脚本不行,那就手工调试一把:

shell> mysql -h192.168.239.51 -ubackup -pbackup -P3307 --silent

mysql: [Warning] Using a password on the command line interface can be insecure.

mysql>

呀,没问题啊!可以连的哇!以上给出的四大可能原因基本可以排除。难道shell脚本中环境变量名称和值没写对?!那就再检查个三遍!三遍!三遍!重要的配置起码要检查3次嘛,确定shell本身配置无误。到底是什么问题呢?头大。。。



难道是shell中的环境变量没生效,赶紧再来调试一波:

shell> env|grep -i "mysql"

MYSQL_PWD=backup

MYSQL_HISTFILE=/root/.mysql57_history

MYSQL_TCP_PORT=3307

MYSQL_HOST=192.168.239.51

shell> mysql -ubackup

ERROR 1045 (28000): Access denied for user 'backup'@'192.168.238.174' (using password: YES)

相关变量都已经生效了啊!!!问题出在哪里呢??



客户端就这么点报错信息,以此来定位根因,信息量严重不够!那MySQL服务端,会不会审计到更多连接异常的信息?

分享一个知识点,用于MySQL运维主要有三类日志:

错误日志(Error Log)

慢查询日志(Slow query Log)

通用日志(General Log)

错误日志主要记录MySQL服务启停及告警和报错信息;慢查询日志主要记录一些慢SQL及未使用索引的SQL语句;而通用日志会将和MySQL主服务交互的行为都记录下来,审计的范围是最广的。那么接下来,瞧瞧通用日志中是否存在定位根因的关键信息呢!

非常遗憾,日志中的信息非常少,对我们的问题帮助不大。常规手段都不行,看样子得动用“核武器”,希望这个大招能奏效,至少要给我们一点关键信息或者思路吧。这个“核武器”是啥呢?

Strace

Linux自带、功能强大的调试分析诊断工具。

下面,我们就用strace来跟踪一把mysql客户端连接:

shell> export MYSQL_HOST=192.168.239.51

shell> export MYSQL_PWD=backup

shell> export MYSQL_TCP_PORT=3307

shell> strace -T -tt -s 100 -o /tmp/strace_login.log mysql -ubackup

ERROR 1045 (28000): Access denied for user 'backup'@'192.168.238.174' (using password: YES)

“核武器”威力够不够,就看这一把了,希望能给我们的排查指个方向!具体Strace工具使用,有兴趣的朋友可以去查阅官网资料和帮助信息,本文不具体展开。

很庆幸,只跟踪一把,就让笔者抓到一些非常有价值的突破点。MySQL客户端工具在发起连接时,读取了/etc/my.cnf配置文件并修改了变量值。难道my.cnf文件是导致连接失败的“元凶”,迫不及待地赶紧打开看看:

哇塞,这波“伤害”非常猛啊!!赶紧把password这行注释掉,再验证一下:

shell> sed -i 's/^password/#password/' /etc/my.cnf

shell> mysql -ubackup --silent

mysql>

接着,继续验证mysql57这个shell脚本:


可以了!顺利登录!问题根因已经定位并且成功处理掉了。


总结来看,就是客户端的/etc/my.cnf参数文件中的[cilent]模块的password选项配置引起客户端连接异常。事后,在和客户的沟通中了解到,该客户端其实也是一台Server,只是平时用的相对较少,配置my.cnf [cilent]主要是方便本地登录。

补充一个知识点

使用mysql客户端工具连接时,默认会依次读取/etc/my.cnf、 /etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf这4个选项文件。在命令行中未明确指定主机、用户、密码和端口的情况下,且my.cnf [cilent]和[mysql]模块配置了相关选项和值。那么可能会命中覆盖行为,进而会导致连接报错。这个问题,可能对于某些MySQL老司机,估计也就一眼的事情;但笔者还是希望能给阅读此文的朋友带来一些收获和体验。

  参考文档:

✦https://dev.mysql.com/doc/refman/5.7/en/server-error-reference.html

✦https://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html

✦https://dev.mysql.com/doc/refman/5.7/en/option-files.html

✦https://dev.mysql.com/doc/refman/5.7/en/environment-variables.html

美创运维中心数据库服务团队拥有Oracle ACE 1人、Oracle OCM 10余人、Oracle OCP 40余人。著有《Oracle数据库性能优化方法论和最佳实践》、《Oracle DBA实战攻略》等书籍。目前运维数据库2000余套,精通Oracle、DB2、MYSQL等各项数据库技术,拥有丰富的处理实战经验。


服务热线:400-711-8011
Copyright ©2005-2018 杭州美创科技有限公司. All Rights Reserved. 浙ICP备12021012号-1