美文网首页
day12 主从复制高级进阶

day12 主从复制高级进阶

作者: 藏鋒1013 | 来源:发表于2019-06-29 16:05 被阅读0次

    八、过滤复制

    主库：(了解)

    show master status;
db01 [(none)]>show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000002 |      730 |              |                  | 76165fbf-9956-11e9-951d-000c296913bb:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

db01 [(none)]>

binlog_do_db
binlog_ignore_db

    从库：

    在SQL线程回放日志时，进行监控过滤
show slave status\G;
Replicate_Do_DB: 
Replicate_Ignore_DB: 
        
Replicate_Do_Table: 
Replicate_Ignore_Table: 
        
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table:

    例：

    只需要复制xyzku的数据到从库
在/data/3308/my.cnf中加入：
relicate_do_db=xyz
----------
vim /data/3308/my.cnf
relicate_do_db=xyz

systemctl restart mysqld3308
mysql> show slave status\G;
注意：如果有多个库的话，写多行即可

    九、半同步复制

    解决主从数据一致性问题

    9.1 半同步复制工作原理的变化

    1.主库执行新的事物，commit时，更新show master status\G,触发一个信号给
2.binlog dump接收到主库的 show master status\G信息，通知库的日志更新了
3. 从库IO线程请求新的二进制日志事件
4.主库通知dump线程传送新的日志事件，告诉主库commit可以成功了
5.从库IO线程接收到binlog日志，当日止写入到磁盘上的relaylog文件时，给主库ACK_receiver线程
6.ACK_receiver线程触发一个事件，告诉主库commit可以成功了
7.如果ACK达到了我们预设值的超时时间，半同步复制会切换为原始的异步复制

    9.2 配置半同步复制

    加载插件
主：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
从:
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
查看是否加载成功:
show plugins;
启动:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
重启从库上的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
查看是否在运行
主:
show status like 'Rpl_semi_sync_master_status';
从:
show status like 'Rpl_semi_sync_slave_status';

    9.3 和传统复制的区别：

    是一个插件刑事提供的功能
    主库：ack_recevier
    从库：ACK_sehd
    主库的ACK_re线程，只有接收到从库发来的ACK确认，主库事务才能commit成功
    从库的ACK_send只有等relaylog落地才能发送ACK
    总库只会等待10s，如果ACK还诶收到的，会自动替换为异步复制

    十、GTID复制(高可用环境准备)

    10.0 作用：

    group commit ,MTS

    10.1 重点参数

    gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1  --->强制刷新从库二进制日志：1. 高可用(MHA)   2. 级联复制的中间库

    10.2 清理环境

    pkill mysqld
\rm -rf /data/*
mkdir -p /data/mysql/data
mkdir -p /data/binlog/
chown -R mysql.mysql /data

    10.3 准备配置文件

    主库db01：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF

slave1(db02)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF

slave2(db03)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF

    10.4 初始化数据(所有节点)

    mysqld --initialize-insecure --user=mysql --basedir=/application/mysql datadir=/data/mysql/data

    10.5 启动数据库

    /etc/init.d/mysqld start

    10.6 主库创建用户

    db01 [(none)]> grant replication slave on *.* to repl@'10.0.0.%' identified by '123';

    10.7 两个从库开启主从

    mysql -e "change master to master_host='10.0.0.51',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;start slave; "
mysql -e "shoa salve status\G"|grep Yes
出现以下内容说明开启成功
[root@db03~]# mysql -e "show slave status \G"|grep Yes
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

    MHA 高可用技术

    一、准备环境(一主两从，GTID，略)

    1.1 配置关键程序软链接

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

    1.2 配置各节点互信

    db01；
rm -rf /root/.ssh
ssh-keygen
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

    1.3 安装软件

    下载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

    1.4 配置文件准备(db03)

    创建配置文件目录：
mkdir -p /etc/mha
创建日志目录：
mkdir -p /var/log/mha/app1
编辑mha配置文件：
cat > /etc/mha/app1.cnf<<EOF
[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
candidate_master=1
port=3306
[server3]
hostname=10.0.0.53
port=3306
EOF

    1.5 状态检查(db03)

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

    1.6 开启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 &

    1.7 查看MHA状态

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

    二、主从复制架构演变

    2.1 基础主从(不依赖于其他的任何软件)

    一主一从
一主多从
多级主从
       ---->以上架构大部分中小型企业还在用，还有一部分用RDS
双主    ---->中型企业，在高可用(MMM)，分布式架构(Mycat，DBLE)

环状
多主一从
        ----> 以上两种几乎没人用

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

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

    2.3 高可用架构

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

    99%                 (1-99%)x365=3.65dx24≈ 87.60小时
99.9%               (1-99.9%)x365=0.365dx24≈ 8.760小时           ---> 互联网级别
99.99%              (1-99.99%)x365=0.0365dx24≈ 0.8760小时        ---> 准金融级别
99.999%             (1-99.999%)x365=0.00365dx24≈ 0.08760小时     ---> 金融级别  
99.9999%            (1-99.9999%)x365=0.000365dx24≈ 0.008760小时  ---> “0” 宕机

    2.3.2 高可用架构产品

    (1) 负载均衡
    Lvs  F5  NGINX  有一定的高可用能力
(2) 主备系统(单活)
    KA ，HA(roseHA,RHCS),PowerHA,mc_sg,MHA,MMM,可以保证3个9到4个9
(3) 多活系统
    PXC (不收费), MGC(不收费) , MySQL Cluster（收费）, InnoDB Cluster(8.0，不收费)
    Oracle RAC(收费)
    Sysbase cluster
    DB2 Cluster

    2.4 分布式架构(现在的大趋势)

    Mycat 1.65
DBLE

    2.5 NewSQL

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

    三、MHA结构演变

    3.1 架构图

    Manager
    Node
    一主两从(三台独立主机)

    3.2 软件结构

    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工作过程

    4.1 安装过程说明

    略……

    4.2 软件工作过程(宕机)

    4.2.1 Manager 启动

    (1) 读取--conf=/etc/mha/app1.cnf配置文件
(2) 获取到node相关的信息(一主两从)
(3) 调用masterha_check_ssh脚本，使用ssh_user=root 进行互信检查
(4) 调用masterha_check_repl 检查主从复制情况
(5) master启动成功
(6) 通过masterha_master_monitor 以 ping_interval=2为间隔持续监控主库的状态
     网络，主机，数据库状态（mha）
(7) 当manager监控到master宕机
(8) 开始选主过程
    算法一：判断是否有《强制主》参数
    算法二：判断两个从库谁更新
    算法三：按照配置文件书写顺序来选主
(9) 判断主库SSH的连通性
    能：S1和S2立即保存(apply_binary_logs) 缺失部分的binlog到本地  
 不能：在传统模式下。调用apply_relay_logs来计算S1和S2的relay-log的差异
    需要通过内容进行复杂的对比：
    在GTID模式下：调用apply_relay_logs计算S1和S2的差异
    只需要对比GTID号码即可，效率较高
    最后进行数据补偿
(10) 解除S1从库身份
(11) S1和S2构建新的主从关系
(12) 移除配置文件中故障节点
(13) manager工作完成，自杀。(一次性的高可用)
额外的功能：
  (1) 提供了Binlog Server
  (2) 应用透明(VIP)
  (3) 实时通知管理员(send_report)
  (4) 自愈系统(待开发……)

    五、故障模拟及处理

    5.1 停主库bd01

    /etc/init.d/mysqld stop

    5.2 修复故障库

    /etc/init.d/mysqld /start

    5.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 ;

    5.4 修改配置文件

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

    5.5

    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

    六、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

    七、MHA的VIP功能

    参数:
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";


更改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

    8.2 准备邮件脚本

    send_report

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

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

    8.4 故障修复：

    8.4.1. 恢复故障节点

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

    8.4.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 ;

    8.4.3 恢复manager

    (1) 修好的故障节点配置信息，加入到配置文件
[server1]
hostname=10.0.0.51
port=3306
(2) 启动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）

    9.1 参数：

    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

    9.2 创建必要目录

    mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）

    9.3 拉取主库binlog日志

    cd /data/mysql/binlog     -----》必须进入到自己创建好的目录
mysqlbinlog  -R --host=10.0.0.52 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点

    9.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 &

    9.5故障处理

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

    十、管理员在高可用架构维护的职责

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

    .

    相关文章

      网友评论

          本文标题：day12 主从复制高级进阶

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

          延伸阅读

          深度阅读

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

          栏目导航

          热点阅读

          关于我们|服务条款|联系我们|day12 主从复制高级进阶|投稿指南|网站地图|RSS订阅|排版工具|手机版

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

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

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

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

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