一个阳光明媚的午后，XX客户反馈，有套MySQL数据库连不上了！经详细了解，确认了客户生产系统正常运行，只是某个客户端连接异常。局部的连接问题，处理起来比较简单和轻松。不过该客户的问题有点“妖”、有点意思，一般还真想不到！！
我们先来看下客户那边具体的报错：
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人、OCM 10余人、数十名Oracle OCP、MySQL OCP、红帽RHCA、中间件weblogic、tuxedo认证、达梦工程师 ，著有《Oracle DBA实战攻略》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》等多本数据运维优化书籍。目前运维各类数据库合计2000余套，精通Oracle、MySQL、SQLServer、DB2、PostgreSQL、达梦等主流商业和开源数据库。并成为首批国内达梦战略合作伙伴之一，拥有海量经验和完善的人员培养体系。并同时提供超融合，私有云整体解决方案。
来源：freebuf.com 2020-06-10 09:56:59 by: database
请登录后发表评论
注册