最近由于业务要求,需要在服务器添加一个mysql实例,遇到个坑,分享下
安装mysql不必多说了,多实例肯定是下载二进制包安装,这个网上很多教程,我就不罗嗦了
正常安装mysql实例,在解压的二进制包里面,会有一个support-files的文件夹
它里面会带有一些推荐的配置文件和启动脚本,单实例mysql.server,多实例mysqld_multi.server,通过修改basedir和datadir,就可以用这两个脚本来管理mysql服务
正常情况下,都是安装好,然后修改my.cnf,添加一些优化配置,然后用脚本启动,我也是这么启动的,但是无论如何都启动不了,查看错误日志
发现有个配置不认,而这个配置也不是我配置的,我的配置中默认配置的Innodb的引擎,完全没有配置这一条,后来发现这个是之前的数据库的配置文件/etc/my.cnf中的配置
我是通过脚本启动的,脚本中关于配置文件这一块儿也是会从$basedir中找my.cnf的
没办法,于是我只能通过执行shell脚本,详细查看它的每个变量的输出来查看是哪里出了问题,因为按我原来的理解,应该是会以我指定的配置文件为准的,所以查看脚本执行过程
其中parse_server_arguments函数这块儿发现读取了两部分的my.cnf配置,/etc/my.cnf有,然后第二个实例的也有,于是我把报错的一些,第二个实例不认得配置在/etc/my.cnf中先注释掉,然后正常启动了第二个实例
登录第二个实例查看配置,可以如果是相同的配置名称,那么配置值是会覆盖掉/etc/my.cnf的,如果第一个配置中有,第二个配置中没有,那么也会被加载上,这是目前发现的问题
也就是如果你要做多实例,就不要写/etc/my.cnf这个配置文件,而是改成多实例配置文件,比如my3306.cnf和my3307.cnf这种,这样通过defaluts-file来指定配置文件启动就可以
这个过程中,查找了关于mysql读取配置文件和启动的一些原理整理如下:
MySQL读取配置文件的顺序是:
/etc/my.cnf > /etc/mysql/my.cnf > /usr/etc/my.cnf > ~/.my.cnf
这个顺序可以通过命令来验证
MySQL启动方式通常分成三种:mysqld、mysqld_safe、mysqld_multi
这三种方式的关系大致如下:
首先当我们使用service mysqld start或者/etc/init.d/mysqld start这样的方式启动的时候,其实是使用了mysql.server这个脚本,这个脚本默认会调用mysqld_safe来启动mysqld,所以通常我们启动mysql之后查看进程的时候会发现有mysqld和mysqld_safe这两个进程存在。这两种通常都是单实例的启动方式,当然也可以使用mysqld来启动多实例的。而mysqld_multi用来启动多实例,也是通过先调用mysqld_safe和mysqld来启动mysql的
你去分析启动脚本,也就是上面这么调用的
接着通过分析启动脚本看下MySQL启动原理
默认的mysql的服务启动程序是mysql.server,就是我上面说得那个目录下,mysql.server程序主要是会用到两个程序和一个函数,分别是my_print_defaults、mysqld_safe和parse_server_arguments
my_print_defaults:读取my.cnf配置文件,输出参数传递给parse_server_arguments,该程序只读my.cnf中[mysqld]中的参数。
parse_server_arguments:该函数处理my_print_defaults传递过来的参数赋值给--basedir、--datadir、--pid-file、--server-startup-timeout
myslqd_safe:mysqld_safe程序调用mysqld程序来启动mysql服务,[mysqld_safe]会覆盖mysqld部分中的参数
mysqld_multi会读取配置文件中的[mysqld_muti],[mysqldN]下面的参数,N需要是一个整数,建议用端口号表示,该部分的配置会覆盖[mysqld]部分中的配置
在mysqld进程挂掉的时候,mysqld_safe进程会监测到并重新将mysqld启动起来