1、普通主从复制架构存在的不足
高可用？
业务不间断的工作。
用户的体验不出来业务断点。
普通主从环境，存在的问题：
1、监控的问题：APP应用程序，并不具备监控数据库的功能，没有责任监控数据库是否能连接。
2、选主的问题
3、failover：VIP漂移，对于应用透明
4、数据补偿2、企业高可用解决方案：
MMM（过时）
MHA（目前推荐）
PXC、Galera Cluster（出现很多年，企业很少用）
5.7.17 MGR 、Innodb Cluster（未来的趋势，尽早研究）
MySQL NDB Cluster（出现很多年，仍然不完善）
MyCAT 高可用3、MHA高可用架构部署实战：
3.0 MHA介绍及工作原理
（1）Manager程序负责监控所有已知Node（1主2从所有节点）
（2）当主库发生意外宕机
（2.1）mysql实例故障（SSH能够连接到主机）
0、监控到主库宕机，选择一个新主（取消从库角色，reset slave），选择标准：数据较新的从库会被选择为新主(show slave status\G)
1、从库通过MHA自带脚本程序，立即保存缺失部分的binlog
2、二号从库会重新与新主构建主从关系，继续提供服务
3、如果VIP机制，将vip从原主库漂移到新主，让应用程序无感知
（2.2）主节点服务器宕机（SSH已经连接不上了）
0、监控到主库宕机，尝试SSH连接，尝试失败
1、选择一个数据较新的从库成为新主库（取消从库角色 reset slave），判断细节：show slave status\G
2、计算从库之间的relay-log的差异，补偿到2号从库
3、二号从库会重新与新主构建主从关系，继续提供服务
4、如果VIP机制，将vip从原主库漂移到新主，让应用程序无感知
5、如果有binlog server机制，会继续讲binlog server中的记录的缺失部分的事务，补偿到新的主库3.1、安装mha node：
依赖包perl-DBD-MySQL ，并在三个节点都安装node软件
rpm包直接rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
3.2、主库中创建mha管理用户grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
3.3、配置软连接
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql3.4、部署manger节点（建议在从节点db03）
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes3.5、安装 manager软件
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
3.6、创建Manager必须目录与配置文件
mkdir -p /etc/mha
mkdir -p /var/log/mha/app1 ----》可以管理多套主从复制
创建配置文件 (不需要的配置不要留着，注释没用,切换后会重写)vim /etc/mha/app1.cnf -----》serverdefault可以独立
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=33063.7、配置互信(所有节点)
ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1
ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]3.8、检测互信
masterha_check_ssh --conf=/etc/mha/app1.cnf
3.9、检测主从masterha_check_repl --conf=/etc/mha/app1.cnf
3.10、启动MHA managernohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
故障演练：
1、宕掉db01主库
2、tail -f /var/log/mha/app1/manager 观察日志变化
3、恢复主库运行，重新将db01加入到主从复制关系中CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
4、将配置文件中加入修好的故障节点
5、启动MHA了manager程序
masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_ssh --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &3.11、使用MHA自带脚本实现IP FailOver(vip 漂移，应用透明)
配置步骤
上传准备好的/usr/local/bin/master_ip_failoverdos2unix /usr/local/bin/master_ip_failover
vim /etc/mha/app1.cnf
添加：master_ip_failover_script=/usr/local/bin/master_ip_failover
重启mha
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)
ifconfig eth0:1 10.0.0.55/24
切换测试：
停主库，看vip是否漂移
11、binlogserver配置：
找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog提前创建好,这个目录不能和原有的binlog一致
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql/*修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
cd /data/mysql/binlog -----》必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &重启MHA，生效配置：
重启mha
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &12、其他参数说明
ping_interval=2 manager检测节点存活的间隔时间，总共会探测4次。
#设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
candidate_master=1
#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，
因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,
MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，
因为这个候选主在切换的过程中一定是新的master
check_repl_delay=0