站长资讯网实验环境：
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 控制卡需要重建，将主服务器移到性能更好的服务器上等等。
server7上变为了slave
server6变为了master
手动切换：手动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的日志，根本没有办法去清晰明了的分析。所以，这里，我们采用工具进行分析。
