Jeson聊Mysql管理之道-MHA最全搭建步骤

MHA是一套相对成熟的MySQL高可用方案，能做到在0~30s内自动完成数据库的故障切换操作，在master服务器不宕机的情况下，基本能保证数据的一致性。

一、常见部署架构模式

模式一、拿一台mysql的slave作为manager节点部署

模式二、单独拿一台服务器作为manager节点

模式三、基于VIP进行漂移模式

由于，我本地测试的服务器资源有限，接下来我拿模式一来介绍下配置的实现。

一、搭建步骤

1、本地资源准备

准备三台虚拟机，分别如下：

IP	初始化主从成员类型	MHA成员类型
192.168.8.70	Master	node
192.168.8.226	Slave1	node
192.168.8.228	Slave2	Manager\node

2、配置主从

需要将这三个节点，配置好主从模式，上一篇手记中有介绍，大家可以看下：

Jeson聊DBA晋级之路-Mysql主从搭建

（注意：所有主从都需要开启bin-log，并且配置保持一致）

3、配置yum源地址

使用的Centos6.8作为测试机器，所以我们需要配置好yum源。

如下：

rpm-ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

4、所有node节点都需要安装如下包

#如果有专门的管理节点（也就是选择架构模式2或者3），从库就只要安装perl-DBD-MySQL

 yum install -yperl-DBD-MySQL

#如果没有管理节点，那么在所有的主从节点都安装如下依赖包：

yum install -y perl-DBD-MySQL perl-Config-Tinyperl-Log-Dispatch

                    perl-Parallel-ForkManager perl-MIME-Liteperl-Params-Validate

5、manager节点安装mha

登陆192.168.8.228，执行如下：

rpm -Uvhmha4mysql-manager-0.56-0.el6.noarch.rpm

                   mha4mysql-node-0.56-0.el6.noarch.rpm

6、建立所有节点的信任关系

注意：所有节点都需要建立ssh登陆认证的信任关系

ssh-keygen  -t  rsa

           *提示：会生成一个/root/.ssh/id_rsa.pub公钥文件，将公钥文件内容复制到.ssh/authorized_keys文件中，将几个节点的公钥的内容都复制到该文件。将这个authorized_keys文件复制到其他节点，确保每个节点都有其他和自己的公钥

测试：

从manager节点上ssh IP，测试是否都可以免密登陆。

7、mysql的master主节点上新建两个mysql用户

创建一个超级管理员以及复制帐号，必须具有远程连接权限，如下：

先登陆192.168.8.70的mysql，执行如下：

grant replication slave on*.* to repl@'%' identified by 'repl';grant all on *.* to mhall@'%'identified by '123456' with grant option;

8、补充

（1）如果mysql安装不是yum的方式安装，则需要建立软链接，

因为mha运行时需要用到/usr/bin下的两个mysql命令（貌似路径写死了，更改/etc/profile对mha无效），所以建立两个软连接  

       ln -s/usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

       ln -s/usr/local/mysql/bin/mysql /usr/bin/mysql

（2）从库设置只读和关闭自动清理binlog

         setglobal read_only=1;

         setglobal relay_log_purge=0;

          *提示：必须设置，否则做masterha_check_repl这个检测步骤的时候会不通过

          

二、配置

登陆manager节点，登陆：192.168.8.228

1、新建配置文件

vim /etc/masterha/app1.cnf

内容如下：

[server default]

#mhamanager工作目录

#管理节点工作目录，如果管理节点也是数据节点，那么建议设置为与remote_workdir不同的目录，如：/tmp

manager_workdir =/var/log/masterha/app1 

manager_log= /var/log/masterha/managerhu1.log  # manager 日志文件

remote_workdir =/var/log/masterha/app1  #mysql数据节点的工作目录

user =mhall                           # MySQL管理帐号和密码（上面超级管理员）

password=123456

ssh_user=root                        # 系统ssh用户

repl_user=repl                        # 复制帐号和密码

repl_password= repl

ping_interval=1                       # 监控间隔(秒)

 

[server1]

hostname=192.168.8.226

ssh_port=9922

port=3306

master_binlog_dir=/var/lib/mysql       #binlog 文件目录

check_repl_delay=0

#默认情况下，如果一个slave落后master超过100MB的relay logs（相当于会应用超过100MB的relay logs），MHA就不会选择该slave作为new master，因为恢复过程会花费太长时间。通过设置check_repl_delay=0，在选择new master的时候MHA就会忽略复制延迟。如果在某个指定的host上设置了candidate_master=1，并且想要确保该host成为new master，那这个选项是有用的。

candidate_master=1

#通过设置candidate_master为1，只要该服务器符合成为new master的条件，该服务器会优先成为master（比如：开启binlog，延迟不明显，等等）所以candidate_master=1不代表指定的host在current master挂掉后总会成为new master，只是用于设置优先级。

如果在多台服务器上设置了candidate_master=1，优先级根据block名称（[server_xxx]）的顺序决定。[server_1] 优先级高于[server_2]。

[server2]

hostname=192.168.8.228

ssh_port=9922

port=3306

master_binlog_dir=/var/lib/mysql

check_repl_delay=0

candidate_master=1

 

[server3]

hostname=192.168.8.70

ssh_port=9922

port=3306

check_repl_delay=0

candidate_master=1

2、检测ssh秘钥以及复制配置是否正确

masterha_check_ssh --conf=/etc/masterha/app1.cnf

 # 检测免密钥环境需要看到[info]All SSH connection tests passed successfully.提示才

算通过

   *提示：这里面会很容易出错，所以确保每个节点上的公钥文件都包含自己和其他节点的公钥

masterha_check_repl--conf=/etc/masterha/app1.cnf

          # 检测复制环境需要看到MySQL Replication Health is OK. 提示才算通过

 *提示：这里面会很容易出错，确保所以得主从关系是否正确，

eg：show slave status\G 出现错误可以将slave stop，然后再次启动

eg: 出现MySQL ERROR 1045(28000): Access denied for use 'mha'@'localhost'

(using password:NO)，可以查看数据库mysql中的user表中是否存在user=mha 但

是host为空的数据，删除

3、测试启动MHA管理节点、检测管理节点状态、停止管理节点

nohup masterha_manager--conf=/etc/masterha/app1.cnf >> /var/log/masterha/app1/managerhu1.log2>&1 &

  # 此时可以查看日志/var/log/masterha/app1/managerhu1.log里是否有报错信息，如果不报错信息，则继续往下

  masterha_check_status--conf=/etc/masterha/app1.cnf

# 检测管理节点状态，需要看到类似app1 (pid:14913) is running(0:PING_OK), master:192.168。8.70 提示信息才表示无误

  masterha_stop --conf=/etc/masterha/app1.cnf

# 停止管理节点程序之后，检测下进程是否被关掉

        ps aux |grep masterha |grep -v grep

 

    拓展：masterha_check_status 可能会返回的状态值及其对应的解释如下表

          

三、测试            

 

    测试故障转移，把管理节点启动起来，然后把主库停止，观察管理节点日志的输出：

       1、在主库中执行：

              pkill mysqld               #停止mysql

       2、重新启动管理节点 ：

nohup masterha_manager--conf=/etc/masterha/app1/app1.conf >> /var/log/masterha/managerhu1.log2>&1 &

       3、查看日志：

            vim  /var/log/masterha/managerhu1.log

                   #看到 Master failover to 192.168.8.226completed successfully

       4、查看其他节点的slave状态,查看主库是否转移

             showslave status;

 

      5、使用change master 指向新主库：

CHANGE MASTER TO

     MASTER_HOST='192.168.8.226',

     MASTER_USER='repl',

     MASTER_PASSWORD='repl',

     MASTER_PORT=3306,

     MASTER_LOG_FILE='mysql-bin.000001',

     MASTER_LOG_POS=106,

     MASTER_CONNECT_RETRY=10

* 提示：如果频繁测试，mha会有错误出现，这个时候需要手动在manger上移除

/var/log/masterha/app1/app1/app1.failover.complete 文件