一、MHA简介：
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于 Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在 0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其 他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器 硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从
MHA工作原理总结为如下：
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave；
（3）应用差异的中继日志（relay log）到其他的slave；
（4）应用从master保存的二进制日志事件（binlog events）；
（5）提升一个slave为新的master；
（6）使其他的slave连接新的master进行复制；
MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。
Manager工具包主要包括以下几个工具：
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_manger 启动MHA
masterha_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 识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs 清除中继日志（不会阻塞SQL线程）二、相关配置
实验环境：
server5：MHA管理节点 172.25.66.5
server6：myslq master 172.25.66.6
server7：mysql Candicate slave 172.25.66.7
server8：mysql slave 172.2.66.8
1.安装数据库，搭建主从复制：（server6、7、8）
以server6为例：
vim /etc/my.cnf
重启服务并初始化数据库
/etc/init.d/mysqld start
grep password /var/log/mysqld.log
mysql -p
进入数据库首先需要重置root用户密码
查看master的状态，并授权slave能通过repl用户，使用‘Yuanxiaoxi+007‘的密码从master端进行数据同步
两个slave端的配置：
vim /etc/my.cnf
问题：SQL线程显示为NO，错误提示中有“PRIMARY'
解决：在master端 reset master
在slave端：
测试两个slave是否可以和master保持数据同步
在master端插入数据
slave端数据同步
MHA端的配置：
检查ssh连接
masterha_check_ssh
原因：MHA manager通过ssh访问所有的node节点，各个node节点同样也需要ssh来相互发送不同的relay log文件，所以有必要在每一个node和manager之间配置ssh无密码登陆
ssh-keygen
ssh-copy-id 172.25.66.5
scp -r .ssh/ 172.25.66.6:
scp -r .ssh/ 172.25.66.7:
scp -r .ssh/ 172.25.66.8:
检查repl环境
解决方法：在master上
在检测时可能还会出现报错：
slave节点配置：
在sever7和server8上配置slave为只读，但不要写入配置文件，因为master机down掉后可能随时升级为master
set global read_only=1;
测试：
在server5开启MHA监控模式：
启动参数介绍：
--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件， 默认情况下，MHA发生切换后会在日志目录下产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后手动删除该文件，为了方便，这里设置为--ignore_last_failover。
将Master的服务down掉
在server5查看日志：
server7变为了master
server8的状态
为了后续的实验，将server6的服务恢复
/etc/init.d/mysqld start
在线切换
在许多情况下， 需要将现有的主服务器迁移到另外一台服务器上。 比如主服务器硬件故障，RAID 控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降， 导致停机时间至少无法写入数据。 另外， 阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入，这个切换过程只需要 0.5-2s 的时间，这段时间内数据是无法写入的。在很多情况下，0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口。
其中参数的意思：
--orig_master_is_new_slave 切换时加上此参数是将原 master 变为 slave 节点，如果不加此参数，原来的 master 将不启动
--running_updates_limit=10000,故障切换时,候选master 如果有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover 时relay 日志的大小决定
server7上变为了slave
server6变为了master
手动切换（MHA Manager必须没有运行）
手动failover，这种场景意味着在业务上没有启用MHA自动切换功能，当主服务器故障时，人工手动调用MHA来进行故障切换操作
将server6的mysql服务down掉，在server5上手动切换到server7上
server7已经变为了master
通过脚本的方式管理VIP：
vim master_ip_failover
vim master_ip_online_change
vim /etc/masterha/app1.cnf
第一次需要添加虚拟ip
在客户端测试：可以访问服务器
将server7的mysql服务down掉，看是否server6能否接替
客户端使用虚拟ip访问不受影响，并且虚拟ip自动调转到了server6上
发送告警邮件
server5：
vim root/MHA/send_report
cp send_report /usr/local/bin/
cd /usr/local/bin/
chmod +x send_report
vim /etc/masterha/app1.cnf
测试：
mysql binlog日志优化
在数据库安装完毕，对于binlog日志参数设置，有一些参数的调整，来满足业务需求或使性能最大化。Mysql日志主要对io性能产生影响，本次主要关注binlog日志。binlog日志会记录下数据库的所有增删改操作，当不小心删除、清空数据，或数据库系统出错，这时候就可以使用binlog日志来还原数据库，简单来说就是一个记录备份的东西
参数binlog_row_image 控制着这种image类型，默认为FULL（log all columns），即记录before&after images。
该参数还有两种，minimal和noblob，minimal表示只记录after更改后的值，并且如果有主键或者非空唯一索引，则只以该字段作为where条件判断；noblob同full，只是不记录blob、text列。
慢查询日志
slow_query_log，这个东西是用来记录查询比较慢的sql语句，通过查询日志来查找哪条sql语句比较慢，然后就可以进行数据库或sql语句或程序上的优化，简单来说就是一个优化辅助工具
1.开启慢查询日志
如果想关闭慢查询日志，只需要执行 set global slow_query_log = off
2.查询慢查询时间临界点：查询时间高于这个临界点的都会被记录到慢查询日志中
3.设置慢查询时间临界点：所有执行时间超过1秒的sql都将被记录到慢查询文件中
set long_query_time = 1;
4.查看慢查询日志
比如上面，就表示 sql语句 select sleep（10）; 执行时间为10.001548秒，超出了我们设置的慢查询时间临界点10s，所以被记录下来了。
5.我们通过查看慢查询日志可以发现，很乱，数据量大的时候，可能一天会产生几个G的日志，根本没有办法去清晰明了的分析。所以，这里，我们采用工具进行分析。
mysqldumpslow是mysql安装后就自带的工具，用于分析慢查询日志，但是pt-query-digest却不是mysql自带的，如果想使用pt-query-digest进行慢查询日志的分析，则需要自己安装pt-query-digest。pt-query-digest工具相较于mysqldumpslow功能多一点。