MySQL多实例踩坑
最近由于业务要求，需要在服务器添加一个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启动起来