mysql3

Rainie999

　　MHA（Master High Availability）是目前在MySQL高可用方面相对成熟的一个解决方案，MHA在监控到master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能。
　　MHA 服务有两种角色，MHA Manager(管理节点)和 MHA Node(数据节点)：
　　MHA Manager：通常单独部署在一台独立机器上管理多个 master/slave 集群，每个master/slave集群称作一个application。
　　MHA node：运行在每台MySQL服务器上(master/slave/manager)，它通过监控具备解析和清理logs功能的脚本来加快故障转移。
　　环境
　　本次实验环境共有四个节点，其角色分配如下所示。
　　manager: MHA Manager
　　master:  MariaDB master
　　slave1:  MariaDB slave
　　slave2:  MariaDB slave
　　修改各节点名字，各节点的/etc/hosts 文件配置内容中添加：
　　172.16.1.2 manager.zrs.com manager
　　172.16.1.3 master.zrs.com master
　　172.16.1.4 slave1.zrs.com slave1
　　172.16.1.5 slave2.zrs.com slave2
　　初始主节点master配置：
　　server_id=1
　　relay_log=relay-log
　　log_bin=master-log
　　节点slave1的配置：
　　server_id=2
　　relay_log=relay-log
　　log_bin=master-log
　　relay_log_purge=0
　　read_only=1
　　节点slave2的配置：
　　server_id=3
　　relay_log=relay-log
　　log_bin=master-log
　　relay_log_purge=0
　　read_only=1
　　下面进行主从复制架构
　　主服务器
　　授权从服务器，并刷新
　　MariaDB [(none)]> grant replication slave,replication client on . to 'repluser'@'172.16.1.4'identified by 'replpass';
　　MariaDB [(none)]> grant replication slave,replication client on . to 'repluser'@'172.16.1.5'identified by 'replpass';
　　MariaDB [(none)]>  flush privileges;
　　从服务器配置
　　两个slave都指定主服务器
　　MariaDB [(none)]> change master to master_host='172.16.1.3',master_user='repluser',master_password='replpass',master_log_file='binlog.000003',master_log_pos=245;
　　开启io线程和sql线程
　　MariaDB [(none)]> start slave io_thread;
　　MariaDB [(none)]> start slave sql_thread;
　　在所有MySQL节点授权

　　MariaDB [(none)]> GRANT ALL ON . TO 'mhamngr'@'172.16.1.%'>　　建立免钥通信
　　MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。可在Manager节点生成密钥对，并设置其可远程连接本地主机后，将私钥文件及authorized_keys文件复制给余下的所有节点即可。
　　[root@manager ~]# ssh-keygen -t rsa -P ''
　　Generating public/private rsa key pair.
　　Enter file in which to save the key (/root/.ssh/id_rsa): .ssh/id_rsa

　　Your>　　Your public key has been saved in .ssh/id_rsa.pub.
　　The key fingerprint is:
　　80:59:23:b9:f8:ce:7e:86:66:ad:23:82:b3:d9:a8:81 root@manager.zrs.com
　　The key's randomart image is:
　　+--[ RSA 2048]----+
　　|    ..o          |
　　|    .= .         |
　　|   .o..          |
　　|  . .  .         |
　　|   .    S        |
　　|.   .            |
　　|E  o o           |
　　|+=. B +          |
　　|*+.=o=           |
　　+-----------------+
　　[root@manager ~]# cat .ssh/id_rsa.pub >> .ssh/authorized_keys
　　[root@manager ~]# chmod go= .ssh/authorized_keys
　　[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@master:/root/.ssh/
　　The authenticity of host 'master (172.16.1.3)' can't be established.
　　ECDSA key fingerprint is 65:f7:d6:d7:ae:3b:a2:dc:2b:bc:33:64:0e:47:11:b4.
　　Are you sure you want to continue connecting (yes/no)? yes
　　Warning: Permanently added 'master' (ECDSA) to the list of known hosts.
　　root@master's password:
　　id_rsa                                                100% 1675     1.6KB/s   00:00
　　authorized_keys                                       100%  402     0.4KB/s   00:00
　　[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@slave1:/root/.ssh/
　　The authenticity of host 'slave1 (172.16.1.4)' can't be established.
　　ECDSA key fingerprint is eb:b4:c4:c4:aa:15:2c:f8:6b:e8:cc:59:75:7a:a5:89.
　　Are you sure you want to continue connecting (yes/no)? yes
　　Warning: Permanently added 'slave1' (ECDSA) to the list of known hosts.
　　root@slave1's password:
　　id_rsa                                                100% 1675     1.6KB/s   00:00
　　authorized_keys                                       100%  402     0.4KB/s   00:00
　　[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@slave2:/root/.ssh/
　　The authenticity of host 'slave2 (172.16.1.5)' can't be established.
　　ECDSA key fingerprint is be:2f:9f:d7:f8:2e:09:b1:7d:29:c2:76:53:0f:d2:94.
　　Are you sure you want to continue connecting (yes/no)? yes
　　Warning: Permanently added 'slave2,172.16.1.5' (ECDSA) to the list of known hosts.
　　root@slave2's password:
　　id_rsa                                                100% 1675     1.6KB/s   00:00
　　authorized_keys                                       100%  402     0.4KB/s   00:00
　　安装MHA
　　除了源码包，MHA官方也提供了rpm格式的程序包，其下载地址为https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。这次安装是使用的rpm格式，在manager和node的所有节点均需安装MHA Node。
　　安装 MHA Manager
　　rpm安装方式：
　　[root@manager ~]# yum install perl-DBD-MySQLperl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
　　[root@manager ~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
　　[root@manager ~]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
　　tar包安装方式：
　　tar -zxf mha4mysql-manager-0.56.tar.gz
　　cd mha4mysql-manager-0.56
　　perl Makefile.PL
　　make
　　make install
　　安装 MHA Node
　　rpm安装方式：
　　~]# yum install perl-DBD-MySQL
　　~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
　　tar包安装方式：
　　tar -zxfmha4mysql-node-0.56.tar.gz
　　cd mha4mysql-node-0.56
　　perl Makefile.PL
　　make
　　make install
　　初始化 MHA
　　Manger节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如果仅监控一组 master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义，本次实验将使用/etc/masterha/app1.cnf
　　[server default]
　　user=mhamngr
　　password=mhapass
　　manager_workdir=/data/masterha/app1
　　manager_log=/data/masterha/app1/manager.log
　　remote_workdir=/data/masterha/app1
　　ssh_user=root
　　repl_user=repluser
　　repl_password=replpass
　　ping_interval=1
　　[server1]
　　hostname=172.16.1.3
　　candidate_master=1
　　[server2]
　　hostname=172.16.1.4
　　candidate_master=1
　　[server3]
　　hostname=172.16.1.5
　　检测各节点间ssh互信通信配置是否正常
　　[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf
　　看到输出的信息中，最后一行显示如下，表示其通过检测。
　　[info] All SSH connection tests passed successfully.
　　检查管理的MySQL复制集群的连接配置参数是否正常
　　[root@manager ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf
　　看到输出的信息中，最后一行显示如下，表示其通过检测。
　　MySQL Replication Health is OK.
　　启动MHA
　　[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &
　　查看master节点的状态
　　[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
　　app1 (pid:23265) is running(0:PING_OK), master:172.16.1.3
　　[root@manager ~]#
　　停止MHA
　　[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf
　　Stopped app1 successfully.
　　MHA 提供诸多工具程序，其常见的如下所示。
　　Manager 节点:

• 　　masterha_check_ssh：MHA 依赖的 SSH 环境检测工具；
  
• 　　masterha_check_repl：MySQL 复制环境检测工具；
  
• 　　masterha_manager：MHA 服务主程序；
  
• 　　masterha_check_status：MHA 运行状态探测工具；
  
• 　　masterha_master_monitor：MySQL master 节点可用性监测工具；
  
• 　　masterha_master_switch：master 节点切换工具；
  
• 　　masterha_conf_host：添加或删除配置的节点；
  
• masterha_stop：关闭 MHA 服务的工具；
  

　　Node 节点:

• 　　save_binary_logs：保存和复制 master 的二进制日志：
  
• 　　apply_diff_relay_logs：识别差异的中继日志事件并应用于其它 slave：
  
• 　　filter_mysqlbinlog：去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具)：
  
• purge_relay_logs：清除中继日志(不会阻塞 SQL 线程)：
  

　　自定义扩展：

• 　　secondary_check_script：通过多条网络路由检测 master 的可用性；
  
• 　　master_ip_failover_script：更新 application 使用的 masterip；
  
• 　　shutdown_script：强制关闭 master 节点；
  
• 　　report_script：发送报告；
  
• 　　init_conf_load_script：加载初始配置参数；
  
• master_ip_online_change_script：更新 master 节点 ip 地址；
  

　　测试故障转移
　　在master节点上面关闭mariadb服务
　　[root@master ~]# killall -9 mysqld mysqld_safe
　　查看日志发现，172.16.1.3这个节点down了，172.16.1.4提升为master。
　　使用zabbix完成masterha-manager重新启动
　　大致步骤
　　略过zabbix server和agent端的安装步骤，我在manager主机上同时安装了zabbix server和zabbix agent，监控刚才设置的nohup启动的manager管理进程，一旦发现这个后台命令执行结束了，立即通过zabbix里面设置的条件和触发器，来调用脚本，使得manager进程始终运行在manager上。
　　在agent上需要完成的配置：
　　1.zabbix用户拥有所需要的管理权限
　　编辑/etc/sudoers文件
　　注释如下行：因为系统默认是要能够通过tty登陆的用户，执行命令，zabbix没有可以登录系统的权限，所以要把这个注释
　　添加如下行：这样做不怎么安全，生产环境下，要用更为安全的方法
　　#Defaults requiretty
　　zabbix ALL=(ALL)NOPASSWD:ALL
　　2.agent进程要允许执行远程命令
　　开启远程命令，即将/etc/zabbix/zabbix_agentd.conf配置文件中的该配置设置为1即可。
　　EnableRemoteCommands=1
　　3.开启服务
　　[root@manager ~]# systemctl start zabbix-agent.service
　　4.在客户端的界面上设置Hosts，items，Triggers，Actions(Action,Conditions,Operations)，
　　需要注意的是Operations需要设置Commands调用脚本来启动MHA程序
　　[root@manager ~]# cat mannager.sh
　　nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &
　　5.可以测试zabbix是否根据设置的事务动作，完成脚本的调用，完成manager的后台启动
　　关闭nohup执行的进程用
　　[root@manager ~]# kill -9 +id     #这个id号需要先查询
　　手动get获取：
　　[root@manager ~]# zabbix_get -s 172.16.1.2 -k masterha.manager
　　2
　　再次get获取：
　　[root@manager ~]# zabbix_get -s 172.16.1.2 -k masterha.manager
　　0
　　当这里显示是0了，同时通过ps命令可以查看这个进程确实已经启动了，于是使用zabbix完成masterha-manager重新启动就成功了。
　　zabbix_get是在命令行下获取数值的zabbix命令：
　　-s   要查的ip地址,本地或者远程的都可以
　　-p   zabbix_agentd的端口
　　-k   key值