读取配置文件失败_运维日记|这都能失败？我太“南”了！

各位新朋友～记得先点蓝字关注我哦～

一个阳光明媚的午后，笔者正惬意的午休着。突然，一个电话镖进来了！接着，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等各项数据库技术，拥有丰富的处理实战经验。