本节索引
原理分析
实验环境准备
主从复制集群
安装MHA包
初始化MHA
配置Keepalived
故障出现
故障恢复
总结
一 原理分析
1 MHA简介：
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
2 MHA组成：
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
Manager工具包主要包括以下几个工具：
masterha_check_ssh检查MHA的SSH配置状况masterha_check_repl检查MySQL复制状况masterha_manger启动MHAmasterha_check_status检测当前MHA运行状态masterha_master_monitor检测master是否宕机masterha_master_switch控制故障转移（自动或者手动）masterha_conf_host添加或删除配置的server信息
Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：
save_binary_logs保存和复制master的二进制日志apply_diff_relay_logs识别差异的中继日志事件并将其差异的事件应用于其他的slavefilter_mysqlbinlog去除不必要的ROLLBACK事件（MHA已不再使用这个工具）purge_relay_logs清除中继日志（不会阻塞SQL线程）
3 MHA工作原理：
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。其结构如下：
官方地址：/p/mysql-master-ha/
二 实验环境准备
1 系统版本
统一版本，统一规范，这是将来能够自动户运维的前提。
[root@vin~]#cat/etc/redhat-releaseCentOSLinuxrelease7.3.1611(Core)
2 内核参数
[root@vin~]#uname-r3.10.0-514.el7.x86_64
3 主机配置参数：准备4台干净的主机node{1,2,3,4}
互相能够解析主机名，由于节点上配置文件，很多都是大体相同的，只需要修改一份让后使用for循环复制给其他节点即可，简单方便，所以这里实现主机名的认证。
角色ip地址主机名server_id类型MHA-Manager172.18.253.73node1-监控复制组Master172.18.250.27node21写入Candicatemaster172.18.253.160node32读Slave172.18.254.15node43读
4 实现互相能够解析主机名
[root@vin~]#cat/etc/hosts172.18.253.73node1172.18.250.27node2172.18.253.160node3172.18.254.15node4
5 实现主机间的互相无密钥通信
由于使用MHA时，Manager需要验证各个节点之间的ssh连通性，所以我们在这里需要实现给节点之间的无密钥通信，这里采用了一个简单的方法，那就是在某个节点上生成ssh密钥对，实现本主机的认证，然后将认证文件以及公私钥都复制到其他节点，这样就不需要，每个节点都去创建密钥对，在实现认证了。
[root@vin~]#ssh-keygen-trsa-P''[root@vin~]#ssh-copy-id-i./id_rsa.pubnode1:[root@vin~]#foriin{2..4};doscpid_rsa{,.pub}authorized_keysroot@node$i:/root/.ssh/;done
三 实现主从复制集群
1 Master配置：
修改配置文件
[root@vin~]#cat/etc/f.d/f[server]server_id=1#提供给主节点一个server号码，可以是任意的整数log_bin=master-log#启用二进制日志relay_log=relay-log#启用中继日志，因为主将来也会成为从innodb_file_per_table=ON#每个数据表存储为单个文件skip_name_resolve=ON#关闭主机名解析，有助于提升性能max_connections=5000#最大并发连接数
创建具有复制功能的用户与用于Manager节点管理的用户；
[root@vin~]#mysqlMariaDB[(none)]>showmasterstatus\G;***************************1.row***************************File:master-log.000003Position:245Binlog_Do_DB:Binlog_Ignore_DB:MariaDB[(none)]>grantreplicationslave,replicationclienton*.*to->'vinsent'@'172.18.%.%'identifiedby'vinsent';#这是一个语句MariaDB[(none)]>grantALLon*.*to'MhaAdmin'@'172.18.%.%'identifiedby'MhaPass';MariaDB[(none)]>flushprivileges;
说明：我们应该先查看主节点正在使用的日志文件及对应的POSITION，再创建用户，以便于从节点能够同步拥有这些用户；创建Manager节点用于管理的用户时需要注意的是，用户名中的主机范围必须能够囊括其他节点的地址。
2 Slave{1,2}配置：
两个从节点的配置相同；修改配置文件，以支持主从复制功能；
[root@vin~]#cat/etc/f.d/f[server]server_id=2log_bin=master-logrelay_log=relay-logrelay_log_purge=OFF#关闭中继日志裁剪功能read_only=ON#由于是从节点，故设置为只读模式innodb_file_per_table=ONskip_name_resolve=ONmax_connections=5000
连接至主节点，实现同步；
[root@vin~]#mysqlMariaDB[(none)]>changemastertomaster_host='172.18.250.27',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245;MariaDB[(none)]>startslave;MariaDB[(none)]>showslavestatus\G;***************************1.row***************************Slave_IO_State:WaitingformastertosendeventMaster_Host:172.18.250.27Master_User:vinsentMaster_Port:3306Connect_Retry:60Master_Log_File:master-log.000003Read_Master_Log_Pos:637Relay_Log_File:relay-log.000002Relay_Log_Pos:922Relay_Master_Log_File:master-log.000003Slave_IO_Running:YesSlave_SQL_Running:YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno:0Last_Error:Skip_Counter:0Exec_Master_Log_Pos:637Relay_Log_Space:1210Until_Condition:NoneUntil_Log_File:Until_Log_Pos:0Master_SSL_Allowed:NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master:0Master_SSL_Verify_Server_Cert:NoLast_IO_Errno:0Last_IO_Error:Last_SQL_Errno:0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id:1
说明：查看从节点状态，确保"Slave_IO_Running","Slave_SQL_Running"的值为"YES"，即从节点正常工作，并且"Last_IO_Errno","Last_SQL_Errno"中没有错误信息提示，出现错误，一般就是连接性错误，这说明要么用户创建的有问题，要么主从节点的数据不同步，请确保两者数据一致。
测试一下从节点是否将主节点的数据同步至本地：
MariaDB[(none)]>selectuserfrommysql.user;+----------+|user|+----------+|root||MhaAdmin||vinsent||root||||root||||root|+----------+
四 安装MHA包
除了源码包，MHA官方也提供了rpm格式的程序包，其下载地址为/p/mysql-master/wiki/Downloads?tm=2。CentOS 7 系统可直接使用适用于el6的程序包，另外，MHA Manager和MHA NODe程序包的版本并不强制要求一致。
1 Manager节点
[root@vin~]#lsmha4mysql-manager-0.56-0.el6.noarch.rpmmha4mysql-node-0.56-0.el6.noarch.rpm
主节点需要安装mha4mysql-manager管理包，以及node几点包，
2 Master && SLave{1,2}节点
从节点只需要安装mode包即可
[root@vin~]#lsmha4mysql-node-0.56-0.el6.noarch.rpm[root@vin~]#yuminstall/root/*.rpm
3 检测各节点之间ssh可用性
出现下面的结果则说明ssh联通性无误
[root@vin~]#masterha_check_ssh--conf=/etc/masterha/f...-[info]AllSSHconnectiontestspassedsuccessfully.
4 检测管理的mysql主从复制集群的连接配置参数是否满足
[root@vin~]#masterha_check_repl--conf=/etc/masterha/f...MonNov1322:11:30-[info]Slavessettingscheckdone.MonNov1322:11:30-[info]172.18.250.27(172.18.250.27:3306)(currentmaster)+--172.18.253.160(172.18.253.160:3306)+--172.18.254.15(172.18.254.15:3306)...MySQLReplicationHealthisOK.
如果配置参数满足要求，那么你将看到这个集群的主从节点，如上实例。
5 启动MHA
Manager节点：
[root@vin~]#masterha_manager--conf=/etc/masterha/fMonNov1322:16:17-[warning]Globalconfigurationfile/etc/fnotfound.Skipping.#没有默认配置文件MonNov1322:16:17-[info]Readingapplicationdefaultconfigurationfrom/etc/masterha/f..MonNov1322:16:17-[info]Readingserverconfigurationfrom/etc/masterha/f..
说明：MHA默认是工作在前台的，要想将它防止至后台运行，可使用下面的命令：
[root@vin~]#nohupmasterha_manager--conf=/etc/masterha/f>\/data/masterha/app1/managerha/manager.log2&>1&
成功启动之后，查看一下Master节点的状态；
[root@vin~]#masterha_check_status--conf=/etc/masterha/fapp1(pid:4090)isrunning(0:PING_OK),master:172.18.250.27
说明：如果未成功启动，这里的命令将不能够正确执行；提示："app1 is stopped(2:NOT_RUNNING)."
六 配置keepalived
设置为用户提供服务的地址为"172.18.14.55/16",通过keepalived实现VIP在Mysql复制集群中浮动。
1 安装keepalived
使用默认yum安装即可；在Mysql复制集群的所有主机上都安装配置keepalived；
[root@vin~]#yuminstallkeepalived-y
2修改keepalived配置文件实现keepalived集群
Master：
[root@vin~]#vim/etc/keepalived/keepalived.conf!ConfigurationFileforkeepalivedglobal_defs{notification_email{root@localhost}notification_email_fromkadmin@localhostsmtp_server127.0.0.1smtp_connect_timeout30router_idLVS_DEVELroute_mcast_group4224.14.0.14#广播地址}vrrp_scriptchk_mysql{script"killall-0mysql"#监控mysql健康性脚本insterval1weight-10}vrrp_instanceVI_1{#keepalived实例stateBACKUPinterfaceens33virtual_router_id66priority98#keepalived节点优先级advert_int1authentication{auth_typePASSauth_pass1111}virtual_ipaddress{172.18.14.55/16#面向客户端的地址}track_script{chk_mysql}}
Slave{1,2}：复主节点的配置文件至Slave节点：
[root@vin~]#foriin{3,4};doscp/etc/keepalived/keepalived.conf\root@node$i:/etc/keepalived/;done
说明：复制过去并不能直接使用，由于keepalived通过优先级机制来决定VIP工作在哪台主机，所以将两个从节点的优先级调节至比主节点上keepalived的优先级低，且互相不同。
有心人可能发现问题了，怎么没有修改VRRP实例的状态"state BACKUP";上面服务器的keepalived都设置为了BACKUP模式，在keepalived中2种模式，分别是master->backup模式和backup->backup模式。这两种模式有很大区别。在master->backup模式下，一旦主节点宕机，虚拟ip会自动漂移到从节点，当主节点修复后，keepalived启动后，还会把虚拟ip抢占过来，即使设置了非抢占模式（nopreempt）抢占ip的动作也会发生。在backup->backup模式下，当主节点故障后虚拟ip会自动漂移到从节点上，当原主节点恢复后，并不会抢占新主的虚拟ip，即使是优先级高于从库的优先级别，也不会发生抢占。为了减少ip漂移次数，通常是把修复好的主库当做新的备库。
七 故障出现
模拟故障发生，我们手动"down"掉了主节点，生产中可能有各种原因导致故障的出现，这里为了最好的模拟办法，当然是关停服务了。
1 Master
[root@vin~]#systemctlstopmariadb
2 在MHA节点上查看MHA的状态
[root@vin~]#masterha_check_repl--conf=/etc/masterha/f....MonNov1322:36:37-[info]MHA::MasterMonitorversion0.56.MonNov1322:36:37-[info]GTIDfailovermode=0MonNov1322:36:37-[info]DeadServers:#指明故障的节点MonNov1322:36:37-[info]172.18.250.27(172.18.250.27:3306)MonNov1322:36:37-[info]AliveServers:MonNov1322:36:37-[info]172.18.253.160(172.18.253.160:3306)MonNov1322:36:37-[info]172.18.254.15(172.18.254.15:3306)MonNov1322:36:37-[info]AliveSlaves:MonNov1322:36:37-[info]172.18.254.15(172.18.254.15:3306)#从节点由两个转为了一个，另为一个升级为主节点....
3 在从节点进行测试看主节点是否正确切换
Slave1：
MariaDB[(none)]>showslavestatus;#查看从节点状态为空，说明已非从节点Emptyset(0.00sec)MariaDB[(none)]>showmasterstatus;#再查看master状态，已正确切换+-------------------+----------+--------------+------------------+|File|Position|Binlog_Do_DB|Binlog_Ignore_DB|+-------------------+----------+--------------+------------------+|master-log.000003|245|||+-------------------+----------+--------------+------------------+
Slave2：
MariaDB[(none)]>showslavestatus\G;***************************1.row***************************Slave_IO_State:WaitingformastertosendeventMaster_Host:172.18.253.160#从节点"Slave2"已经将主节点指向了新的主节点Master_User:vinsentMaster_Port:3306Connect_Retry:60Master_Log_File:master-log.000003...
4 查看keepalived地址绑定情况：
Master：
[root@vin~]#ipa|grepens332:ens33:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscpfifo_faststateUPqlen1000inet172.18.250.27/16brd172.18.255.255scopeglobaldynamicens33
Slave1：
[root@vin~]#ipa|grepens332:ens33:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscpfifo_faststateUPqlen1000inet172.18.250.160/16brd172.18.255.255scopeglobaldynamicens33inet172.18.14.55/16scopeglobalsecondaryens33#地址正确漂移至从节点Slave1
Slave2：
[root@vin~]#ipa|grepens332:ens33:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscpfifo_faststateUPqlen1000inet172.18.254.15/16brd172.18.255.255scopeglobaldynamicens33
八 故障恢复
为了满足集群要求，应当立即将故障的主节点修复上线。由于Mysql复制集群的主节点已然切换，那么故障的原主节点上线之后只能为从节点，所以应当修改其配置文件满足从节点的要求。
1 Master节点
[root@vin~]#vim/etc/f.d/f#添加如下两项[server]relay_log_purge=OFFread_only=ON
启动服务，并连接Mysql；并连接至新的主节点做主从同步；这里值得注意的是：如果你的主节点是在运行过程中故障宕机来了，那么你要做的就不仅仅是修改配置，启动服务了。修改配置文件之后，应当对新主做一个完全备份，将新主节点的数据恢复至本机，然后在连接至新的主节点做复制同步（本实验没有太多的数据，故直接上线）。
[root@vin~]#systemctlstartmariadb[root@vin~]#mysqlMariaDB[(none)]>changemastertomaster_host='172.18.253.160',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245;MariaDB[(none)]>startslave;MariaDB[(none)]>showslavestatus\G***************************1.row***************************Slave_IO_State:WaitingformastertosendeventMaster_Host:172.18.253.160Master_User:vinsentMaster_Port:3306...
2 Manager：
切换至MHA上并查看集群状态；
[root@vin~]#masterha_check_repl--conf=/etc/masterha/f...MonNov1322:54:53-[info]GTIDfailovermode=0MonNov1322:54:53-[info]DeadServers:MonNov1322:54:53-[info]AliveServers:MonNov1322:54:53-[info]172.18.250.27(172.18.250.27:3306)#由于没有在配置文件中指明谁是主，故这里只能看到所有工作的主机MonNov1322:54:53-[info]172.18.253.160(172.18.253.160:3306)MonNov1322:54:53-[info]172.18.254.15(172.18.254.15:3306)MonNov1322:54:53-[info]AliveSlaves:MonNov1322:54:53-[info]172.18.250.27(172.18.250.27:3306)...MySQLReplicationHealthisOK.
启动MHA Manger监控，查看集群里面现在谁是master；
[root@vin~]#masterha_check_status--conf=/etc/masterha/fapp1isstopped(2:NOT_RUNNING).
？？怎么回事，明明已经正确启动，为何此处显示为“stopped”；赶紧去官网一查发现："Currently MHA Manager process does not run as a daemon. If failover completed successfully or the master process was killed by accident, the manager stops working. To run as a daemon, daemontool. or any external daemon program can be used. Here is an example to run from daemontools.",原来如此。
九 总结
通过查日志观察切换过程分析MHA切换过程：
[root@vinmasterha]#catmanager.logMonNov1322:36:03-[info]MHA::MasterMonitorversion0.56.MonNov1322:36:04-[info]GTIDfailovermode=0MonNov1322:36:04-[info]DeadServers:MonNov1322:36:04-[info]172.18.250.27(172.18.250.27:3306)MonNov1322:36:04-[info]AliveServers:MonNov1322:36:04-[info]172.18.253.160(172.18.253.160:3306)MonNov1322:36:04-[info]172.18.254.15(172.18.254.15:3306)MonNov1322:36:04-[info]AliveSlaves:MonNov1322:36:04-[info]172.18.254.15(172.18.254.15:3306)Version=5.5.52-MariaDB(oldestmajorversionbetweenslaves)log-bin:enabledMonNov1322:36:04-[info]Replicatingfrom172.18.253.160(172.18.253.160:3306)MonNov1322:36:04-[info]PrimarycandidateforthenewMaster(candidate_masterisset)MonNov1322:36:04-[info]CurrentAliveMaster:172.18.253.160(172.18.253.160:3306)MonNov1322:36:04-[info]Checkingslaveconfigurations..MonNov1322:36:04-[warning]relay_log_purge=0isnotsetonslave172.18.254.15(172.18.254.15:3306).MonNov1322:36:04-[info]Checkingreplicationfilteringsettings..MonNov1322:36:04-[info]binlog_do_db=,binlog_ignore_db=MonNov1322:36:04-[info]Replicationfilteringcheckok.MonNov1322:36:04-[info]GTID(withauto-pos)isnotsupportedMonNov1322:36:04-[info]StartingSSHconnectiontests..MonNov1322:36:05-[info]AllSSHconnectiontestspassedsuccessfully.MonNov1322:36:05-[info]CheckingMHANodeversion..MonNov1322:36:06-[info]Versioncheckok.MonNov1322:36:06-[error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm,ln492]Server172.18.250.27(172.18.250.27:3306)isdead,butmustbealive!Checkserversettings.MonNov1322:36:06-[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm,ln424]Errorhappenedoncheckingconfigurations.at/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pmline399.MonNov1322:36:06-[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm,ln523]Errorhappenedonmonitoringservers.MonNov1322:36:06-[info]Gotexitcode1(Notmasterdead).MonNov1322:36:13-[info]MHA::MasterMonitorversion0.56.MonNov1322:36:13-[info]GTIDfailovermode=0MonNov1322:36:13-[info]DeadServers:MonNov1322:36:13-[info]172.18.250.27(172.18.250.27:3306)MonNov1322:36:13-[info]AliveServers:MonNov1322:36:13-[info]172.18.253.160(172.18.253.160:3306)MonNov1322:36:13-[info]172.18.254.15(172.18.254.15:3306)MonNov1322:36:13-[info]AliveSlaves:MonNov1322:36:13-[info]172.18.254.15(172.18.254.15:3306)Version=5.5.52-MariaDB(oldestmajorversionbetweenslaves)log-bin:enabledMonNov1322:36:13-[info]Replicatingfrom172.18.253.160(172.18.253.160:3306)MonNov1322:36:13-[info]PrimarycandidateforthenewMaster(candidate_masterisset)MonNov1322:36:13-[info]CurrentAliveMaster:172.18.253.160(172.18.253.160:3306)MonNov1322:36:13-[info]Checkingslaveconfigurations..MonNov1322:36:13-[warning]relay_log_purge=0isnotsetonslave172.18.254.15(172.18.254.15:3306).MonNov1322:36:13-[info]Checkingreplicationfilteringsettings..MonNov1322:36:13-[info]binlog_do_db=,binlog_ignore_db=MonNov1322:36:13-[info]Replicationfilteringcheckok.MonNov1322:36:13-[info]GTID(withauto-pos)isnotsupportedMonNov1322:36:13-[info]StartingSSHconnectiontests..MonNov1322:36:15-[info]AllSSHconnectiontestspassedsuccessfully.MonNov1322:36:15-[info]CheckingMHANodeversion..MonNov1322:36:15-[info]Versioncheckok.MonNov1322:36:15-[error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm,ln492]Server172.18.250.27(172.18.250.27:3306)isdead,butmustbealive!Checkserversettings.MonNov1322:36:15-[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm,ln424]Errorhappenedoncheckingconfigurations.at/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pmline399.MonNov1322:36:15-[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm,ln523]Errorhappenedonmonitoringservers.MonNov1322:36:15-[info]Gotexitcode1(Notmasterdead).
从上面的输出可以看出整个MHA的切换过程，共包括以下的步骤：
配置文件检查阶段，这个阶段会检查整个集群配置文件配置
宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作，这是MHA管理keepalived的时候，我们这里是通过keepalived的脚本实现mysql状态监控的。MHA也有管理keepalived的脚本，有需要的可以自行研究。
复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下
识别含有最新更新的slave
应用从master保存的二进制日志事件（binlog events）
提升一个slave为新的master进行复制
使其他的slave连接新的master进行复制
目前高可用方案可以一定程度上实现数据库的高可用，比如MMM，heartbeat+drbd，Cluster等。还有percona的Galera Cluster等。这些高可用软件各有优劣。在进行高可用方案选择时，主要是看业务还有对数据一致性方面的要求。最后出于对数据库的高可用和数据一致性的要求，推荐使用MHA架构。
