MySQL MHA高可用

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: MySQL MHA高可用
+关注继续查看

数据损坏的类型

物理损坏 :磁盘、主机、程序、数据文件
逻辑损坏 :drop ..

高可用解决方案选型依据:全年无故障率

无故障时间           故障时间                     解决方案
99.9%                0.1%     = 525.6  min        KA+双主 :人为干预 
99.99%               0.01%    = 52.56  min        MHA  :半自动化  
应用场景:比较适合非金融类互联网公司。facebook MHA ,淘宝 TMHA  --》polardb。替代产品:ORCH go语言。
99.999%              0.001%   = 5.256  min        PXC 、 MGR 、MGC
应用场景:金融类业务。
99.9999%             0.0001%  = 0.5256 min        自动化、云化、平台化

MHA基础环境实施

GTID复制

参考:主从延时问题的监控及处理建议    

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 组件
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志(不会阻塞SQL线程)

MHA软件安装及配置

程序软连接

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

各节点进行互信

ssh-keygen 
ssh-copy-id 
 
各节点验证
db01:
ssh 10.0.1.121 date
ssh 10.0.1.122 date
ssh 10.0.0.53 date
 
db02:
ssh 10.0.1.121 date
ssh 10.0.1.122 date
ssh 10.0.0.53 date
 
db03:
ssh 10.0.1.121 date
ssh 10.0.1.122 date
ssh 10.0.0.53 date

安装软件

# 所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

# Manager软件安装(db03)
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
yum install -y mha4mysql-manager-0.58-0.el7.centos.noarch.rpm 

# 在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';

Manager配置文件准备(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         # MHA的工作日志设置
manager_workdir=/var/log/mha/app1             # MHA工作目录        
master_binlog_dir=/data/binlog                # 主库的binlog目录
user=mha                                      # 监控用户                      
password=mha                                  # 监控密码
ping_interval=2                               # 心跳检测的间隔时间
repl_password=123                             # 复制用户
repl_user=repl                                # 复制密码
ssh_user=root                                 # ssh互信的用户
[server1]                                     # 节点信息....
hostname=10.0.1.121
port=3306  
                                
[server2]            
hostname=10.0.1.122
port=3306
candidate_master=1
 
 
[server3]
no_master=1
hostname=10.0.0.53
port=3306
EOF

状态检查(db03) ok

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

开启MHA-manager

开启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.1.121

MHA工作原理

MHA 是当 master 出现故障,挑选一个 slave 作为新的 master 并构建成新的 主从架构的管理工具。从 master 出现故障到构建成新的主从架构时间是 10-30 秒。在 master 出现故障时可能会出现 slave 同步的数据不一致的现象,此工具 可以自动应用差异的中继日志到其他 slave 上保证数据的一致性。

优点:

(1).可以快速的进行故障切换

(2).自动选择数据同步最全的slave,并把差异日志应用到其他slave上

(3).一个mha manage server可以监控很多master,更改升级配置,不影响线上正在运行的数据库

(4).对原先的体系结构的性能影响很小

(5).适合任何支持主从复制的存储引擎

如图:

640.png

    # 1. 启动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 &
     
    # 2. 监控  
    /usr/bin/masterha_master_monitor ,每隔ping_interval秒探测1次,连续4次还没有,说明主库宕机。
     
    # 3. 选新主
    3.1 日志量 latest 
     
    3.2 备选主 pref
     
    3.3 哪些不被选主 bad
    no_master=1
    log_bin 二进制日志没开
    check_slave_delay,如果从库落后主库100M的日志量(可以关闭)
     
    =============
    数组:
    alive   : 存活
    latest  :最新
    pref    :备选
    bad     :不选
     
    选主判断:
    伪代码:
    if 情况
    =1. 如果pref和bad数组当中slave的个数为0,则选择latest数组当中的第一个slave为master。
    db02没有candidate_master,又没有以下bad三种情况,db02恰好是latest。
     
    =2. 循环对比latest数组和perf数组的slave,如果存在相同的slave,并且这个slave不在bad数组当中,该slave会被推选为新的master。
    db02 pref , latest  ,又不是bad,会被选主。
     
     
    =3. 循环对比slaves数组pref数组当中的slave,如果有一个slave相同并且不在bad数组当中,该就会成为新的master。
    db02 ,不是latest,不是bad,是pref。会被选择。
     
     
    =4. 循环latest数组,如果又循环到的slave不在bad数组当中,这个slave就会成为master。
        也就是说就算添加了candidate_master=1,该slave也不一定会成为主库。
      
      db02 , latest  ,不是bad 
      db03 , pref,不是latest ,不是bad 
             
    =5. 从活着的slave当中进行循环,如果循环到的slave不在bad数组当中,那么这个slave就会成为主库。
      db02 ,slaves ,不是bad 。
     
    else 如果进行了多次选择都找不到主库,那么主库选择失败,failover失败。
     
    ==============
     
    4. 数据补偿 :
    4.1 原主库ssh能连接 
      各个从节点调用:save_binary_logs 脚本,立即保存缺失部分的binlog到各自节点/var/tmp目录。
    4.2 原主库ssh不能连接 
        从节点调用apply_diff_relay_logs  ,进行relay-log日志差异补偿。
     
    4.3. 额外数据补偿(主库日志冗余机制)
       binlog_server.
     
    5. 切换 
       所有从库解除主从身份。stop slave ; reset slave;
       重构新的主从关系。change master to 
     
    6. 应用透明(vip)
     
    7. 故障提醒
     
    8. 额外数据补偿
     
     
    9. 剔除故障节点
     
    10. manager 程序"自杀"

    应用透明(VIP)

    vip 介绍 
    #作用网卡:
    eth0:1 
    eth0:1
    # IP
    vip :   10.0.1.125/24
    一定是一个空闲地址。
    一定要和对外提供服务的地址同一网段。
    不能跨网段。
     
    类似nginx中keepalived的

    vip 故障转移脚本

      上传脚本文件到/usr/local/bin 
      [root@db03 mha_script]# \cp -a * /usr/local/bin
       
      修改权限 
      [root@db03 bin]# chmod +x /usr/local/bin/*
       
       修改内容
      [root@db03 bin]#vim  /usr/local/bin/master_ip_failover
       
      my $vip = '10.0.1.125/24';
      my $key = '1';
      my $if  = 'eth0';
      my $ssh_start_vip = "/sbin/ifconfig $if:$key $vip";
      my $ssh_stop_vip = "/sbin/ifconfig  $if:$key down";
      my $ssh_Bcast_arp= "/sbin/arping -I $if -c 3 -A 10.0.1.125";
       
      修改Manager 配置文件
       
      vim /etc/mha/app1.cnf 
       
      master_ip_failover_script=/usr/local/bin/master_ip_failover
       
       
      检查  masterha_check_status --conf=/etc/mha/app1.cnf
       
       
      重启MHA 
      [root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
      [root@db03 bin]# 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 
      [root@db02 ~]# ifconfig eth0:1 10.0.1.125/24

      故障提醒功能

      [root@db03 bin]# vim  send_report 
      my $smtp='smtp.qq.com';             # smtp服务器
      my $mail_from='xxxx@qq.com';    # 发件箱
      my $mail_user='xxxx';           # 用户名 QQ号
      my $mail_pass='gemghsvgkeyzcagh';   # 授权码
      my $mail_to=['xxxx@qq.com'];    # 收件箱
       
      #my $mail_to=['to1@qq.com','to2@qq.com'];

      修改配置文件

      vim /etc/mha/app1.cnf 
      # 添加一行:
      report_script=/usr/local/bin/send_report

      重启MHA

      [root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
      [root@db03 bin]# 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)

      mkdir -p /data/binlog_server/
       
      chown -R mysql.mysql /data/*
      cd  /data/binlog_server/
       
      [root@db03 ~]# mysql -e "show slave status \G"|grep "Master_Log"
      mysqlbinlog  -R --host=10.0.1.121 --user=mha --password=mha --raw  --stop-never mysql-bin.000004 &
       
      注意:
      拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点

      配置文件设置

      vim /etc/mha/app1.cnf 
      [binlog1]
      no_master=1
      hostname=10.0.1.123
      master_binlog_dir=/data/binlog_server/

      重启MHA

      [root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
      [root@db03 bin]# 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高可用,故障模拟及恢复演练

      db01:
      /etc/init.d/mysqld stop 
       
      db03:看日志 
      [root@db03 binlog_server]# tail -f  /var/log/mha/app1/manager
      

      MHA的维护操作 - 在线切换功能

      只切换角色
       
      masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.1.122 --orig_master_is_new_slave --running_updates_limit=10000
       
      注意:
      master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes
       
      1. 此种方法切换,要注意将原主库,FTWRL(Flush table with read lock),否则会造成主从不一致。
      2. 手工切换vip
      3. 重新拉去新主库的binlog

      master_ip_online_change_script功能实现

      功能: 在线切换时,自动锁原主库,VIP自动切换

      准备切换脚本

      vim /usr/local/bin/master_ip_online_change
       
      my $vip = "10.0.1.125/24";
      my $key = "1";
      my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
      my $ssh_stop_vip = "/sbin/ifconfig eth0:$key $vip down";
      my $ssh_Bcast_arp= "/sbin/arping -I eth0 -c 3 -A 10.0.1.125";
       
       
       修改MHA配置文件 
      vim /etc/mha/app1.cnf
      master_ip_online_change_script=/usr/local/bin/master_ip_online_change
       
       
       停 MHA
      [root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
       
       检查repl
      [root@db03 bin]# masterha_check_repl   --conf=/etc/mha/app1.cnf 
       
      在线切换 
      masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.1.121 --orig_master_is_new_slave --running_updates_limit=10000
       
       
      重构binlogserver
      [root@db03 bin]# ps -ef |grep mysqlbinlog
      root      2144  16272  0 17:50 pts/1    00:00:00 mysqlbinlog -R --host=10.0.1.122 --user=mha --password=x x --raw --stop-never mysql-bin.000005
      root      2529  16272  0 1:03 pts/1    00:00:00 grep --color=auto mysqlbinlog
      [root@db03 bin]# kill -9 2144
      [root@db03 bin]# cd /data/binlog_server/
      [root@db03 binlog_server]# ll
      total 4
      -rw-r----- 1 root root 194 Apr  1 17:50 mysql-bin.000005
      [root@db03 binlog_server]# rm -rf *
      [root@db03 binlog_server]# mysqlbinlog  -R --host=10.0.1.121 --user=mha --password=mha --raw  --stop-never mysql-bin.000009 &
      [1] 2534
       
      启动MHA 
      [root@db03 bin]# 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 binlog_server]# masterha_check_status   --conf=/etc/mha/app1.cnf 
      app1 (pid:2535) is running(0:PING_OK), master:10.0.1.121
      

      MHA故障通用修复方法

      检查三节点是否启动
       
      检查主从关系 
      1主2从:
      [root@db03 binlog_server]# mysql -e "show slave status\G" |grep "Master_Host"
      Master_Host: 10.0.1.122
      [root@db01 data]#  mysql -e "show slave status\G" |grep "Master_Host"
       
      修复1主从:
      db01: 
       
      change master to 
      master_host='10.0.1.122',
      master_user='repl',
      master_password='123' ,
      MASTER_AUTO_POSITION=1;
      start slave;
       
      [root@db01 data]#  mysql -e "show slave status\G" |grep "Master_Host"
                        Master_Host: 10.0.1.122
       
       
      检查vip是否在主库
      相关实践学习
      基于CentOS快速搭建LAMP环境
      本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
      全面了解阿里云能为你做什么
      阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
      相关文章
      |
      7天前
      |
      关系型数据库 MySQL 数据库
      还在观望?先来免费体验RDS MySQL高可用系列ARM架构的高性价比!
      无需手动搭建环境,提供免费真实资源,对高可用系列ARM架构RDS MySQL与部署在ECS实例(X86架构)的自建MySQL基于Sysbench进行性能压测,实时动态查看性能、价格和性价比结果。
      还在观望?先来免费体验RDS MySQL高可用系列ARM架构的高性价比!
      |
      15天前
      |
      存储 算法 关系型数据库
      微服务轮子项目(28) -MySQL 高可用方案
      微服务轮子项目(28) -MySQL 高可用方案
      31 0
      |
      21天前
      |
      负载均衡 网络协议 关系型数据库
      rhel 8.7 部署 keepalived+haproxy 实现 mysql 双主高可用场景 2
      rhel 8.7 部署 keepalived+haproxy 实现 mysql 双主高可用场景
      33 2
      |
      21天前
      |
      关系型数据库 MySQL 网络安全
      rhel 8.7 部署 keepalived+haproxy 实现 mysql 双主高可用场景 1
      rhel 8.7 部署 keepalived+haproxy 实现 mysql 双主高可用场景
      30 0
      |
      1月前
      |
      关系型数据库 MySQL Nacos
      生产环境下的终极指南:在生产环境部署 Nacos 集群和高可用 MySQL 使用 Docker
      生产环境下的终极指南:在生产环境部署 Nacos 集群和高可用 MySQL 使用 Docker
      64 0
      |
      1月前
      |
      存储 关系型数据库 MySQL
      Kubesphere手把手教你轻松打造高可用MySQL集群!
      Kubesphere手把手教你轻松打造高可用MySQL集群!
      51 0
      |
      1月前
      |
      Kubernetes 关系型数据库 MySQL
      Kubernetes中部署MySQL高可用集群
      Kubernetes中部署MySQL高可用集群
      |
      2月前
      |
      存储 SQL 负载均衡
      MySQL高可用九种方案(下)
      MySQL高可用九种方案(下)
      |
      2月前
      |
      负载均衡 关系型数据库 MySQL
      |
      2月前
      |
      监控 关系型数据库 MySQL
      MySQL高可用搭建方案之(MHA)(下)
      MySQL高可用搭建方案之(MHA)(下)
      推荐文章
      更多