MySQL MHA高可用

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 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是否在主库
      相关实践学习
      如何在云端创建MySQL数据库
      开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
      全面了解阿里云能为你做什么
      阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
      相关文章
      |
      4月前
      |
      存储 关系型数据库 MySQL
      Mysql高可用|索引|事务 | 调优
      Mysql高可用|索引|事务 | 调优
      |
      4月前
      |
      SQL 容灾 关系型数据库
      rds容灾与高可用
      rds容灾与高可用
      60 4
      |
      22天前
      |
      运维 容灾 关系型数据库
      MySQL高可用方案--Xenon全解
      MySQL高可用方案--Xenon全解
      |
      19天前
      |
      SQL 关系型数据库 MySQL
      orchestrator搭建mysql高可用
      orchestrator搭建mysql高可用
      14 0
      |
      19天前
      |
      缓存 关系型数据库 MySQL
      如何实现mysql高可用集群
      如何实现mysql高可用集群
      12 0
      |
      22天前
      |
      安全 关系型数据库 MySQL
      【MySQL】Orchestrator最简单的 mysql 高可用方案最细细细细~
      【MySQL】Orchestrator最简单的 mysql 高可用方案最细细细细~
      |
      3月前
      |
      运维 容灾 关系型数据库
      介绍几种 MySQL 官方高可用方案
      MySQL 官方提供了多种高可用部署方案,从最基础的主从复制到组复制再到 InnoDB Cluster 等等。本篇文章以 MySQL 8.0 版本为准,介绍下不同高可用方案架构原理及使用场景。
      453 3
      介绍几种 MySQL 官方高可用方案
      |
      1月前
      |
      缓存 关系型数据库 MySQL
      MySQL调优秘籍曝光!从索引到事务,全方位解锁高可用秘诀,让你的数据库性能飞起来!
      【8月更文挑战第6天】MySQL是顶级关系型数据库之一,其性能直接影响应用的高可用性与用户体验。本文聚焦MySQL的高性能调优,从索引设计到事务管理,逐一解析。介绍如何构建高效索引,如联合索引`CREATE INDEX idx_order_customer ON orders(order_id, customer_id);`,以及索引覆盖查询等技术。
      65 0
      |
      3月前
      |
      SQL 关系型数据库 MySQL
      MySQL高可用架构设计:从主从复制到分布式集群
      MySQL高可用性涉及主从复制、半同步复制和Group/InnoDB Cluster。主从复制通过二进制日志同步数据,保证故障时可切换。半同步复制确保事务在至少一个从服务器确认后才提交。Group Replication是多主复制,支持自动故障切换。InnoDB Cluster是8.0的集成解决方案,简化集群管理。使用这些技术能提升数据库的稳定性和可靠性。
      289 2
      |
      4月前
      |
      运维 负载均衡 关系型数据库
      MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
      MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
      146 9

      热门文章

      最新文章