作者：余振兴

爱可生 DBA 团队成员，热衷技术分享、编写技术文档。

本文起源：原创投稿

*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

咱们都晓得应用 mysql 客户端去拜访 MySQL 数据库时，会以肯定的程序去读取不同地位的配置文件，但在一次做测试时，发现除了依照程序读取默认的配置文件门路外，mysql 还有额定的读取配置文件的行为，以下是在我本地测试环境做测试时遇到的一个有意思的小知识点

一、场景景象

在本地做测试时，发现一个奇怪的景象，当我应用 socket 打算登录数据库，发现不指定用户时，默认并不是用的 root 用户登录，而是被批改为了 zhenxing 用户

[root@10-186-61-162 ~]# mysql -S /data/mysql/3306/data/mysqld.sock -pEnter password:ERROR 1045 (28000): Access denied for user 'zhenxing'@'127.0.0.1' (using password: NO)

通过观测以后mysql客户端的默认参数行为,能够看到与报错统一,默认用户的确是变为了zhenxing

[root@10-186-61-162 ~]# mysql --help|egrep "user|host|port"  -h, --host=name     Connect to host.  -P, --port=#        Port number to use for connection or 0 for default to, in  -u, --user=name     User for login if not current user.host                              127.0.0.1port                              3306user                              zhenxing

在这里作为 DBA ，咱们的第一反馈是必定是查看 /etc/my.cnf 文件中是否对默认用户做了配置，于是查看该配置文件的客户端配置参数，如下

[client]host            = 127.0.0.1user            = rootport            = 3306[mysql]host            = 127.0.0.1user            = rootport            = 3306prompt          = '\U[\d]> '

发现配置文件中的反而配置值是 root 用户，并没有对 zhenxing 用户做配置，看来读取的还不是这个配置文件，那是不是读取了其余配置文件呢，持续排查其余的配置文件

二、排查思路

1、获取配置文件读取程序

咱们先打印出所有可能读取的配置文件及其读取的程序做一一排查

## 查看mysql客户端读取配置文件的程序[root@10-186-61-162 ~]# mysql --verbose --help|grep my.cnf                      order of preference, my.cnf, $MYSQL_TCP_PORT,/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf /data/mysql/3306/base/my.cnf ~/.my.cnf

2、排查 /etc/my.cnf

/etc/my.cnf 在后面曾经确认没有做相干配置，这里间接跳过

3、排查 /etc/mysql/my.cnf

查看 /etc/mysql/my.cnf 配置，发现不存在相干配置，排除

[root@10-186-61-162 ~]# cat /etc/mysql/my.cnfcat: /etc/mysql/my.cnf: 没有那个文件或目录

4、排查 /usr/local/mysql/etc/my.cnf

查看 /usr/local/mysql/etc/my.cnf 配置，发现不存在相干配置，排除
[root@10-186-61-162 ~]# cat /usr/local/mysql/etc/my.cnfcat: /usr/local/mysql/etc/my.cnf: 没有那个文件或目录

5、排查 /data/mysql/3306/base/my.cnf

查看 /data/mysql/3306/base/my.cnf 配置，发现不存在相干配置，排除
[root@10-186-61-162 ~]# cat /data/mysql/3306/base/my.cnfcat: /data/mysql/3306/base/my.cnf: 没有那个文件或目录

6、排查 ~/.my.cnf

查看 ~/.my.cnf 仍旧不存在相干配置，排除
[root@10-186-61-162 ~]# cat ~/.my.cnfcat: /root/.my.cnf: 没有那个文件或目录

至此依照 mysql --verbose --help|grep my.cnf 获取的配置文件读取门路都被排除，都未对用户 zhenxing 做配置

7、应用 no-defaults 排除配置文件烦扰

  • 尝试用 --no-defaults 不读取任何配置文件排除配置文件的烦扰,看是否会恢复正常
[root@10-186-61-162 ~]# mysql --help|grep no-defaults--no-defaults           Don't read default options from any option file## 查看不读取配置文件时,客户端的默认值[root@10-186-61-162 ~]# mysql --no-defaults --help|egrep "user|host|port"  -h, --host=name     Connect to host.  -P, --port=#        Port number to use for connection or 0 for default to, in  -u, --user=name     User for login if not current user.host                              127.0.0.1port                              3306user                              zhenxing## 查看读取的所有客户端配置文件参数设置[root@10-186-61-162 ~]# mysql --print-defaultsmysql would have been started with the following arguments:--host=127.0.0.1 --user=root --port=3306 --host=127.0.0.1 --user=root --port=3306 --prompt=\U[\d]>  --user=zhenxing --password=***** --host=127.0.0.1 --port=3306

从下面输入的后果来看,咱们能够失去以下2个根本景象：

  • 即便指定--no-defaults不读取任何配置文件,这个user的默认值仍旧是zhenxing用户
  • 当输入--print-defaults获取理论运行值时,能够看到/etc/my.cnf下的[client],和[mysql]标签下的属性配置从上到下被正确获取
  • 除了/etc/my.cnf外,在最初还有--user=zhenxing --password=***** --host=127.0.0.1 --port=3306这4个参数被额定增加到了命令最初

ps: mysql 客户端和服务端读取配置的准则都是文件读取从上到下，前面雷同参数配置笼罩后面的参数

通过一系列的排除，仍旧没找到这个默认值被批改的源头

8、打印 mysql 客户端的零碎调用

  • 应用 strace 间接观测 mysql 客户端在执行时到底调用了哪些配置，以下是调用 my.cnf 相干配置的片段(对后果做了精简输入)
1. stat("/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=195, ...}) = 0      = 32. stat("/etc/mysql/my.cnf", 0x7ffd56813180) = -1 ENOENT (No such file or directory)3. stat("/usr/local/mysql/etc/my.cnf", 0x7ffd56813180) = -1 ENOENT (No such file or directory)4. stat("/data/mysql/3306/base/my.cnf", 0x7ffd56813180) = -1 ENOENT (No such file or directory)5. stat("/root/.my.cnf", 0x7ffd56813180)   = -1 ENOENT (No such file or directory)6. stat("/root/.mylogin.cnf", {st_mode=S_IFREG|0600, st_size=336, ...}) = 0

通过以上调用程序能够可到以下论断：

  • 1-5行的调用程序与咱们验证的逻辑基本一致
  • 2-5行显示为No such file or directory与咱们的验证后果统一
  • 第6行输入，减少了一个对/root/.mylogin.cnf的读取操作，并且能够晓得以后这个文件是的确存在的

9、排查 /root/.mylogin.cnf

看到这个文件咱们个别都晓得，这个是 mysql_config_editor 工具用来配置 login-path 的生成的文件，咱们能够用以下形式查看以后的配置信息

[root@10-186-61-162 ~]# mysql_config_editor print --all[client]user = "zhenxing"password = *****host = "127.0.0.1"port = 3306

这里能够看到配置中有一个 client 标签的连贯参数配置，配置的内容正好是咱们文章结尾显示的异样默认值，到这咱们根本定位了造成这个奇怪景象的起因，呈现这个故障场景的起因也是刚好这台是测试环境已经做过一些 mysql_config_editor 用法的测试，导致了该景象的产生

三、场景总结

1、mysql 客户端除了会依照命令 mysql --verbose --help|grep my.cnf输入的惯例的程序读取配置外，在最初还会额定的读取 .mylogin.cnf 文件中配置

2、即便指定了 --no-defaults ，依旧会去读取.mylogin.cnf中的[client] ，[mysql] 标签的配置值

其中官网文档也在以下链接中给到了明确的阐明(以下是要害形容片段)

  • https://dev.mysql.com/doc/ref...
The mysql client reads [client] and [mysql] from other option files, and [client], [mysql], and [mypath] from the login path file.Client programs read the login path file even when the --no-defaults option is used. This permits passwords to be specified in a safer way than on the command line even if --no-defaults is present.
  • 集体猜想过后这么设计的目标是思考如备份脚本等须要连贯数据库时，为了避免非必要的参数文件的烦扰，在指定了 --no-defaults 参数后仍旧能应用到 .mylogin.cnf 文件中配置的加密明码，晋升安全性