美文网首页
DBA之路 12_MySQL_主从复制进阶及MHA

DBA之路 12_MySQL_主从复制进阶及MHA

作者: Linux_淡忘 | 来源:发表于2019-06-28 21:44 被阅读0次

上节回顾

主从复制：

1.介绍
    依赖于binlog的“实时”备份的一个多节点架构
2.前提
    2台机器/两个实例
    主库开启二进制日志
    server_id
    复制用户
    数据预同步
    change master to
    start slave
3.名词
    文件
        主库：binlog
        从库：relaylog    
              relay-log.info
              master.info
    线程
        主库：
              binlog_dump_thread
        从库：
              IO_thread
              SQL_thread
              purge-relay-log线程自动清理relay.log


4.原理
5.故障分析
show slave status\G

8.过滤复制

主库（了解）：
binlog_do_db
binlog_ignore_db
从库：
Replicate_Do_DB: 
Replicate_Ignore_DB: 

Replicate_Do_Table: 
Replicate_Ignore_Table: 
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table:

例子：

只需要复制xyz库的数据到从库
vim /data/3309/my,cnf

replicate_do_db=xyz
白名单
systemctl restart myslqd3309

show slave status\G
Replicate_Do_DB: xyz

9.半同步复制

和传统复制的区别：
是一个插件形式提供的功能
主库：ack_receiver
从库：ack_send

主库的ack_receiver线程，只有接收到从库发来的ack确认，主库事务才能commit成功
从库acksend只有等relaylog落地才能发送adc
主库只会等10秒钟，如果ACK还没有收到，会自动替换为异步复制

10GTID复制(MHA环境准备)

10.0作用

group commit,MTS都是依赖于GTID

10.1重点参数

gtid-mode=on
enforce-gtid-consistency=true
log_slave-updates=1----强制刷新从库二进制日志：1.MHA2.级联复制的中间库

10.2清理环境

10.3配置文件（后文4.1中有详细步骤）

2.主从复制架构演变

2.1基础主从（不依赖第三方）

一主一从
一主多从
级联主从
-------->以上架构大部分中小型存在，还有一部分用了RDS
多主一从
-------->中型企业，在MHA（MMM），分布式架构中会出现。
双主结构
环状复制
-------->几乎没人用

2.2高性能架构---读写分离架构

mysql-proxy---->0.8停了
360------------>二次开发 Atlas Atlas-sharding 2016年
MySQL---------->mysql-router****
Percona--------->ProxySQL
Mariadb--------->Maxscale

2.3高可用架构

2.3.1企业高可用标准（全年无故障率）

99%                   
99.9%
99.99%
99.999%
99.9999%

2.3.2高可用架构产品

（1）负载均衡
     LVS,F5,Nginx有一定的高可用能力
（2）主备系统（单活）
    KA，HA（roseHA,RHCS）,PowerHA,mc_sg,MHA,MMM
（3）多活系统
    PXC（不收费）,MGC（不收费）,MYSQL Cluster（收费）,InnoDB Cluster(8.0，不收费),Oracle RAC（收费）,Sysbase Cluster,DB2 Cluster[c

2.4分布式架构（现在的趋势）

Mycat 1.65
DBLE

2.5NewSQL

RDBMS+ NoSQL+分布式
sp
TiDB
巨杉
polarDB
OceanBase

3.MHA架构模型

3.1架构图

略

3.2软件结构

Manager
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
Node工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志（不会阻塞SQL线程）

4.MHA工作过程

4.1安装过程说明

配置关键程序软连接

ln -s /data/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql          /usr/bin/mysql

配置各节点互信

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配置文件
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

状态检查

互信检查

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

主从状态检查

[root@db03 ~]# masterha_check_ssh  --conf=/etc/mha/app1.cnf 
[root@db03 ~]# masterha_check_repl  --conf=/etc/mha/app1.cnf

开启MHA(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 &

查看MHA状态

[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.51 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 51    |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.52 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 52    |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.53 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 53    |
+---------------+-------+

4.2软件工作过程（宕机）

4.2.1manager启动

（1）读取--conf=/etc/mha/app1.cnf配置文件
（2）获取到node相关的信息（1主2从）
（3）调用masterha_check_ssh使用ssh_user=root用户进行互信检测
（4）调用masterha_check_repl检查主从复制情况
（5）manager启动成功
（6）通过masterha__master_monitor以ping_interval=2为间隔持续监控主库的状态
    网络，主机，数据库状态（mha用户监控状态）。
（7）当manager监控到master宕机。
（8）开始选主过程
      算法一：判断是否有“强制主”参数
      算法二：判断两个从库谁更新
      算法三：按照配置文件顺序
（9）判断主库SSH的连通性
      能：S1和S2会立刻保存（save_binary_logs）缺失部分的binlog到本地
      不能：
          在传统模式下：调用apply_diff_relay_logs计算S1和S2的relay-log的差异
          需要通过内容进行比较复杂的对比
          在GTID模式下：调用apply_diff_relay_logs计算S1和S2的relay-log的差异
          只需对比GTID号码即可，效率较高。
      最后进行数据补偿
（10）解除S1从库身份
（11）S2和S1构建新的主从关系
（12）移除配置文件中故障节点
（13）manager工作完成，退出程序（一次性的高可用）

额外的功能

（1）提供了binlog server实时在异地保存二进制日志
（2）应用透明（VIP）
（3）实时通知管理员（send_report）
（4）自愈（待开发）6

模拟故障

1.停主库DB01

systemctl stop mysqld
观察manager日志tail -f /var/log/mha/app1/manager
末尾必须显示successfully，才算正常切换成功。

2.修复故障库

[root@db01 ~]# /etc/init.d/mysqld start

3.恢复主从结构

查看日志：
[root@db03 ~]# grep -i 'change master to ' /var/log/mha/app1/manager
Fri Jun 28 18:21:05 2019 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';

db01:
CHANGE MASTER TO 
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306, 
MASTER_AUTO_POSITION=1, 
MASTER_USER='repl', 
MASTER_PASSWORD='123';
start slave ;

4.修改配置文件（db03）

vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306

5.启动MHA（db3）

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
app1 (pid:19347) is running(0:PING_OK), master:10.0.0.52

6. Manager额外参数介绍

说明：
主库宕机谁来接管？
1. 所有从节点日志都是一致的，默认会以配置文件的顺序去选择一个新主。
2. 从节点日志不一致，自动选择最接近于主库的从库
3. 如果对于某节点设定了权重（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

7.MHA的vip功能（db3）

参数
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意：/usr/local/bin/master_ip_failover，必须事先准备好
修改脚本内容
vi  /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";
chmod +x /usr/local/bin/master_ip_failover

更改manager配置文件
vi /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意：
[root@db03 ~]# dos2unix /usr/local/bin/master_ip_failover 
dos2unix: converting file /usr/local/bin/master_ip_failover to Unix format ...
[root@db03 ~]# chmod +x /usr/local/bin/master_ip_failover 
主库上，手工生成第一个vip地址
手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)
ifconfig eth0:1 10.0.0.55/24
重启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 &

8.邮件提醒

1. 参数：
report_script=/usr/local/bin/send
2. 准备邮件脚本
send_report

(1)准备发邮件的脚本(上传 email_2019-最新.zip中的脚本，到/usr/local/bin/中)
(2)将准备好的脚本添加到mha配置文件中,让其调用

3. 修改manager配置文件，调用邮件脚本
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send

（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) 关闭主库,看警告邮件

故障修复

1. 恢复故障节点

（1）实例宕掉
/etc/init.d/mysqld start 
（2）主机损坏，有可能数据也损坏了
备份并恢复故障节点。

2.恢复主从环境

看日志文件：
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave ;

3.恢复manager

3.1修好的故障节点配置信息，加入到配置文件
[server1]
hostname=10.0.0.51
port=3306
启动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 &
binlog server（db03）
参数：
binlogserver配置：
找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave（db03）
vim /etc/mha/app1.cnf 
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
拉取主库binlog日志
cd /data/mysql/binlog     -----》必须进入到自己创建好的目录
mysqlbinlog  -R --host=10.0.0.52 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点

重启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 &

故障处理

主库宕机，binlogserver 自动停掉，manager 也会自动停止。
处理思路：
1、重新获取新主库的binlog到binlogserver中
2、重新配置文件binlog server信息
3、最后再启动MHA

9. 管理员在高可用架构维护的职责
1. 搭建：MHA+VIP+SendReport+BinlogServer
2. 监控及故障处理
3.  高可用架构的优化
核心是：尽可能降低主从的延时，让MHA花在数据补偿上的时间尽量减少。
5.7 版本，开启GTID模式，开启从库SQL并发复制。

相关文章

网友评论

      本文标题：DBA之路 12_MySQL_主从复制进阶及MHA

      本文链接：https://www.haomeiwen.com/subject/qkvjcctx.html

      延伸阅读

      深度阅读

      • 您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

      栏目导航

      热点阅读

      关于我们|服务条款|联系我们|DBA之路 12_MySQL_主从复制进阶及MHA|投稿指南|网站地图|RSS订阅|排版工具|手机版

      提供经典美文摘抄,优美散文欣赏,现代诗歌精选,短篇小说,心情随笔,表白情书范文,故事会在线阅读欣赏

      Copyright © 2014-2023 Haomeiwen.com All Rights Reserved. 好美文阅读网 版权所有

      备案信息：桂公网安备 45052102000051号 · 桂ICP备13007215号-3

      本站所收录作品、热点评论等信息部分来源互联网，目的只是为了系统归纳学习和传递资讯

      所有作品版权归原创作者所有，与本站立场无关，如不慎侵犯了你的权益，请联系我们告知，我们将做删除处理！