MySQL高可用及读写分离(MHA)

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/mysql

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必须目录与配置文件

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 [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 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 &

故障演练:

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_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一致,我的是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

转载于:https://blog.51cto.com/12083623/2360114

你可能感兴趣的:(运维,开发工具,数据库)