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软件

MHA高可用架构部署细节:
三台MySQL独立节点实例，主机名、IP、防火墙关闭等
开启1主2从GTID复制结构
关闭各节点relay-log自动删除功能
各节点部署node工具包及依赖包
选择其中一个从节点进行部署manager工具包
各节点ssh秘钥互信配置
配置manager节点配置文件（注意：在数据库中添加mha管理用户和密码）
做ssh互信检查和主从状态检查
开启MHA功能

检查防火墙和enforce开关情况：
iptables -L
getenforce
关闭二进制日志删除功能：relay_log_purge=0;
数据库中全局关闭：set relay_log_purge=0;
检查状态：mysql -e "show variables like '%relay%'";
上传MHA软件，然后解压：unzip mha.zip
#涉及到安装两个软件，node和manager；
依赖包perl-DBD-MySQL ，并在三个节点都安装node软件（三个节点都安装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/mysql
#mha小bug只能在/usr/bin下使用

3.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-HiRes

3.5、安装 manager软件

rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm 

3.6、创建Manager必要目录与配置文件（DB03）

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=3306

3.7、配置互信(所有节点)

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1

ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.51
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.52
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.53

测试：ssh 10.0.0.51 date

3.8、检测互信

masterha_check_ssh --conf=/etc/mha/app1.cnf 3.9、检测主从

masterha_check_ssh --conf=/etc/mha/app1.cnf

3.10、启动MHA manager

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 &

tail -f /var/log/mha/app1/manager

故障演练：

1、宕掉db01主库
/etc/init.d/mysqld stop
2、tail -f /var/log/mha/app1/manager  观察日志变化(实时监控日志)
3、恢复主库运行，重新将db01加入到主从复制关系中
检查状态：
show slave stauts\G;
/etc/init.d/mysqld start
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave;
show slave status\G;
4、将配置文件中加入修稿的故障节点(宕机后自动删除被删除的server信息)
5、启动MHA了manager程序（经历主库宕机后，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 漂移，应用透明) #################################END#########################################

配置步骤

上传准备好的/usr/local/bin/master_ip_failover(脚本文件)
chmod +x master_ip_failover
dos2unix /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一致（master_ip_failover），我的是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24
切换测试：
停主库，看vip是否漂移

/etc/init.d/mysqld stop

3.12、binlogserver配置：

找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave
vim /etc/mha/app1.cnf（在10.0.0.53机器上）
[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     -----》必须进入到自己创建好的目录，在主库的/data/binlog目录中查看是否是从以下001开始的。

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 &

3.13、其他参数说明

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

最后，祝大家早日学有所成，拿到满意offer，快速升职加薪，走上人生巅峰。

可以的话请给我一个三连支持一下我哟??????【获取资料】