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

2019-06-28 本文已影响0人 Linux_淡忘

上节回顾

主从复制：

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企业高可用标准（全年无故障率）

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

上节回顾

主从复制：

8.过滤复制

例子：

9.半同步复制

10GTID复制(MHA环境准备)

10.0作用

10.1重点参数

10.2清理环境

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

2.主从复制架构演变

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

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

2.3高可用架构

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

2.3.2高可用架构产品

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

2.5NewSQL

3.MHA架构模型

3.1架构图

3.2软件结构

4.MHA工作过程

4.1安装过程说明

配置关键程序软连接

配置各节点互信

各节点验证

安装软件

所有节点安装Node软件依赖包

在db01主库中创建mha需要的用户

Manager软件安装（db03）

配置文件准备(db03)

状态检查

互信检查

主从状态检查

开启MHA(db03)：

查看MHA状态

4.2软件工作过程（宕机）

4.2.1manager启动

额外的功能

模拟故障

1.停主库DB01

2.修复故障库

3.恢复主从结构

4.修改配置文件（db03）

5.启动MHA（db3）

6. Manager额外参数介绍

7.MHA的vip功能（db3）

8.邮件提醒

故障修复

1. 恢复故障节点

2.恢复主从环境

3.恢复manager

3.1修好的故障节点配置信息，加入到配置文件

启动manager

binlog server（db03）

重启MHA

故障处理

猜你喜欢

热点阅读