主从复制架构演变介绍
基本结构
(1)一主一从
(2)一主多从
(3)多级主从
(4)双主
(5)循环复制
高级应用架构演变
高性能架构
(1) 读写分离架构(读性能较高)
代码级别
MySQL proxy (Atlas,mysql router,proxySQL(percona),maxscale)、amoeba(taobao) ,xx-dbproxy等。
(2) 分布式架构(读写性能都提高):
分库分表——cobar--->TDDL(头都大了),DRDS
Mycat--->DBLE自主研发等。
NewSQL-->TiDB
高可用架构
(1)单活:MMM架构——mysql-mmm(google)
(2)单活:MHA架构——mysql-master-ha(日本DeNa),T-MHA
(3)多活:MGR ——5.7 新特性 MySQL Group replication(5.7.17) --->Innodb Cluster
(4)多活:MariaDB Galera Cluster架构,(PXC)Percona XtraDB Cluster、MySQL Cluster(Oracle rac)架构
高可用MHA *****
架构工作原理
#主库宕机处理过程
1. 监控节点 (通过配置文件获取所有节点信息)
系统,网络,SSH连接性
主从状态,重点是主库
2. 选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
1. 默认情况下如果一个slave落后master 100M的relay logs的话,即使有权重,也会失效.
2. 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主
3. 数据补偿
(1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
(2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs)
4. Failover
将备选主进行身份切换,对外提供服务
其余从库和新主库确认新的主从关系
5. 应用透明(VIP)
6. 故障切换通知(send_reprt)
7. 二次数据补偿(binlog_server)
8. 自愈自治(待开发...)
# Failover
1. MHA通过脚本(masterha_master_monitor)实时(ping_interval=2)监控主库的状态(主机,数据库状态)
2. 监控到主库宕机之后,会发生自动选主(masterha_master_switch )
(1) 权重: 参数
(2) 日志量
(3) 配置文件的顺序
3. 数据补偿
(1) 当主库SSH能够连接,各个从库会立即保存(save_binary_logs)缺失部分的日志到/var/tmp,进行数据补偿.
(2) 当主库SSH无法连接,通过脚本(apply_diff_relay_logs)自动进行从库的relaylog的差异处理,进行数据补偿.
4. 构建新的主从关系,并将故障节点移除(配置文件移除)
5. MHA主进程完成工作后,自动退出.
6. 应用透明 VIP(master_ip_failover_script=/usr/local/bin/master_ip_failover)
7. 故障通知 (report_script=/usr/local/bin/send)
8. 提供额外数据补偿的手段(binlog server)
自动自愈,待开发....
架构介绍:
1主2从,
master:db01
slave:db02 db03 ):
MHA 高可用方案软件构成
Manager软件:选择一个从节点安装
Node软件:所有节点都要安装
MHA软件构成
Manager 工具包主要包括以下几个工具:
masterha_manger # 启动MHA
masterha_check_ssh #检查MHA的SSH配置状况
masterha_check_repl #检查MySQL复制状况
masterha_master_monitor #检测master是否宕机
masterha_check_status #检测当前MHA运行状态
masterha_master_switch #控制故障转移(自动或者手动)
masterha_conf_host #添加或删除配置的server信息
Node工具包主要包括以下几个工具:
这些工具通常由MHA Manager的脚本触发,无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志(不会阻塞SQL线程)
MHA环境搭建
规划:
主库: 51 node
从库:
52 node
53 node manager
准备环境
(略。1主2从GTID)
配置关键程序软连接
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
配置各节点互信
第一次连接需要手动yes确认,
db01:
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp -r /root/.ssh 10.0.0.52:/root
scp -r /root/.ssh 10.0.0.53:/root
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
安装软件
下载mha软件
mha官网:https://code.google.com/archive/p/mysql-master-ha/
github下载地址:https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
Manager软件安装(db03)
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
配置文件准备(db03)
创建配置文件目录
mkdir -p /etc/mha
创建日志目录
mkdir -p /var/log/mha/app1
编辑mha
配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf
[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
状态检查
## 互信检查
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
## 主从状态检查
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
MySQL Replication Health is OK.
开启MHA(db03):
[root@db03 ~]# masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51
2.4.10 故障模拟及处理
(1) 停主库db01:
[root@db01 ~]# /etc/init.d/mysqld stop
观察manager 日志 tail -f /var/log/mha/app1/manager
末尾必须显示successfully,才算正常切换成功。
(2) 修复主库
[root@db01 ~]# /etc/init.d/mysqld start
(3) 修复主从
[root@db01 ~]# mysql -e "change master to master_host='10.0.0.52',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;"
[root@db01 ~]# mysql -e "start slave;"
[root@db01 ~]# mysql -e "show slave status G"|grep Running:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
(4) 恢复配置文件
[root@db03 /etc/mha]# cat /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
user=mha
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
(5) 启动MHA
[root@db03 ~]# 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 &
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
Manager额外参数介绍
说明:
主库宕机谁来接管?
- 所有从节点日志都是一致的,默认会以配置文件的顺序去选择一个新主。
- 从节点日志不一致,自动选择最接近于主库的从库
- 如果对于某节点设定了权重(candidate_master=1),权重节点会优先选择。
但是此节点日志量落后主库100M日志的话,也不会被选择。可以配合check_repl_delay=0,关闭日志量的检查,强制选择候选节点。
(1) ping_interval=1
# 设置监控主库,发送ping包的时间间隔,尝试三次没有回应的时候自动进行failover
(2) candidate_master=1
# 设置为候选master,如果设置该参数以后,发生主从切换以后将会将此从库提升为主库,即使这个主库不是集群中事件最新的slave
(3)check_repl_delay=0
#默认情况下如果一个slave落后master 100M的relay logs的话,MHA将不会选择该slave作为一个新的master,因为对于这个slave的恢复需要花费很长时间,通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时,这个参数对于设置了candidate_master=1的主机非常有用,因为这个候选主在切换的过程中一定是新的master
MHA 的vip功能
(1) 准备vip脚本
[root@db03 ~]# cp master_ip_failover.txt /usr/local/bin/master_ip_failover
[root@db03 ~]# cd /usr/local/bin/
[root@db03 /usr/local/bin]# yum install -y dos2unix
[root@db03 /usr/local/bin]# dos2unix master_ip_failover
[root@db03 /usr/local/bin]# chmod +x master_ip_failover
(2) 更改manager配置文件:
vi /etc/mha/app1.cnf
#添加:
master_ip_failover_script=/usr/local/bin/master_ip_failover
(3) 修改文件内容:
[root@db03 /usr/local/bin]# vim /usr/local/bin/master_ip_failover
my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
(4)主库上,手工生成第一个vip地址
手工在主库上绑定vip,注意一定要和配置文件中的ethN一致,我的是eth0:1(1是key指定的值)
ifconfig eth0:1 10.0.0.55/24
(5) 重启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 &
邮件提醒
(1) 添加配置选项
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send
(2) 拷贝脚本
[root@db03 ~]# cp -a email/* /usr/local/bin
(3)停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
(4)开启MHA
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 &
(5) 关闭主库,看警告邮件
主库关闭后,会自动切换主库,同时发送警告邮件。但是MHA会停止,需要重新搭建MHA
binlog server(db03)
(1) 添加配置信息
vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
(2) 创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
(3)拉取主库binlog日志
注意:拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
cd /data/mysql/binlog
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
(4) 重启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 &
MHA 故障处理
检查MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf
检查mha配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
master_ip_failover_script=/usr/local/bin/master_ip_failover
password=mha
ping_interval=2
repl_password=123
repl_user=repl
report_script=/usr/local/bin/send
ssh_user=root
user=mha
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
3.检查互信关系
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
4.检查脚本
同时需要检查脚本内容是否正确
ls -l /usr/local/bin/
-rwxr-xr-x 1 root root 2166 Aug 20 15:45 master_ip_failover
-rwxr-xr-x 1 root root 35 Aug 20 15:51 send
-rwxr-xr-x 1 root root 80213 Aug 20 15:51 sendEmail
-rwxr-xr-x 1 root root 198 Aug 20 16:01 testpl
5.检查binlogserver
ps -ef| grep mysqlbinlog
6.确认主库,恢复binlog日志
db02 [(none)]>show master status
cd /data/mysql/binlog
rm -rf *
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000005 &
7.检查主库VIP
ifconfig eth0:1 10.0.0.55/24
ifconfig
8.检查主从状态
masterha_check_repl --conf=/etc/mha/app1.cnf
9.启动MHA
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 &
masterha_check_status --conf=/etc/mha/app1.cnf