zoukankan      html  css  js  c++  java
  • MySQL 高可用之MHA

    前言

    在 MySQL 的高可用方案中,MHA(Master High Availability)可谓是最为成熟、使用最为广泛的方案之一了。其作者 Yoshinori Matsunobu 现就职于 Facebook,该架构采用 perl 语言编写,可完成秒级别的主库故障切换,接下来详细介绍 MHA 在铜板街的上线之路。

    架构选型

    在开始计划实施 MySQL 数据库高可用时,我们选择了比较流行的几大方案,分别进行了调研。

    MHA:适用于一主多从的架构体系,在故障切换过程中,可从宕机的主库上保存二进制日志,最大程度的保证数据不丢失。但是需要 MHA 架构内所有的节点都必须可以 ssh互通。

    MMM:(Master-Master replication manager for MySQL) 适用于双主架构,是一套支持双主故障切换和日常管理的脚本程序,虽无需架构内 ssh 互通,但是无法保存主库的二进制日志,所以数据一致性不如 MHA 高。

    PXC:(Percona XtraDB Cluster)是 percona 公司提供的一套高可用方案,需要三个或以上 percona 版本的 DB 节点,该架构保证了数据强一致,但是同等硬件配置下,性能不如 MHA 和 MMM,尤其木桶效应明显,该方案还需依赖外部组件。

    MGR:(MySQL Group Replication)是 MySQL 官方发布的高可用架构,该方案依赖于 MySQL5.7 版本,适用于主从架构,但是需要类似主库全表包含主键等相关依赖,成熟度不如以上方案,该方案同样需要依赖外部组件。

    综上,在结合自身的业务场景,最终选择 MHA 作为 MySQL 集群的高可用方案。以下详细介绍 MHA 的体系结构及部署和测试的各项细节。

    架构简介

    MHA由两个部分组成,如下图1:管理节点(以下称为 manager )和数据节点(以下称为 node )组成,其中 manager 可以单独部署也可以部署在 DB 节点上,为规范,我们将 manager 单独部署在一台机器上(为节省资源,可以部署在虚拟机上,并做好备份),node 部署在每个 DB 上和 manager 上。

    MHA架构中,manager 会定时探测集群中的主库节点,一般为每秒钟探测一次,当主库出现故障后,拉取主库和最新从库的差异日志并应用到该从库上,将该从库提升为新的主库,然后把其他所有的从库重新指向新的主库,由于主库采取 VIP 方式对外提供服务,整个故障转移的过程对应用程序是完全透明的。

    为最大程度的保证数据一致性,对于核心业务的数据库参数 sync_binlog、

    innodb_flush_log_at_trx_commit 均设置为1,每次主库事物提交后,都立即写入 binlog 并且立即将缓存中的 redo 日志写到日志文件,并调用操作系统 fsync 刷新 IO 缓存。主从同步上采用半同步复制,主库的每个事物需要等待从库返回响应后再对外宣布成功,最大程度的保证数据的一致性( MySQL的半同步复制即使在 5.7 版本中也没有做到数据的强一致)。

    图 1

    原理说明

    由于篇幅有限,本章将着重介绍MHA的工作原理,以及相关实现的细节,具体的搭建步骤,将在下一章节重点介。

    以下图 图2为例,总结一下MHA的工作原理(以下序列号和图2序列号一一对应)。

    manager 确认主库宕机后,触发 master_ip_failover 脚本,摘除 VIP。

    manager 识别最新的从库(同步主库数据最多的 slave1)binlog 的位置。

    manager 把主库和最新从库的差异 binlog 保存到 manager 本地。

    manager 将本地保存的差异 binlog 复制到最新从库上,并进行应用,应用完成后,将原主库的 VIP 设置到该从库上,提升该从库为新的主库。

    将其他所有从库指向新的主库。

    图 2

    那么MHA具体是通过什么操作的呢,其实就是一些 perl 脚本,包括 manager 和 node 工具包,具体说明如下:

    MHAmanager 端常用工具:

    masterha_master_switch:控制故障转移(常用,一般手动在线切换主库使用)

    masterha_check_ssh:检查 MHA 的 SSH 配置状况 (常用,每次配置完 ssh 互通需测试一下)

    masterha_check_repl:检查 MySQL 复制状况 (常用,每次部署完 MHA 后,都需要进行检测)

    masterha_manager:启动 MHA 使用(常用,主库自动故障切换时开启 MHA 所需命令)

    masterha_secondary_check:对主库监听进行二次校验

    masterha_check_status:检查当前 MHA 运行状态

    masterha_master_monitor:监测 master 是否宕机

    masterha_stop:停止 MHA

    manager 使用到的脚本:

    master_ip_failover_script=/usr/local/bin/master_ip_failover设置自动 failover 时候使用到的切换脚本

    master_ip_online_change_script=/usr/local/bin/master_ip_online_change设置手动在线切换时所使用的切换脚本

    report_script=/usr/local/bin/send_report 设置切换完发送通知使用的的脚本,仅自动故障切换场景时触发,手动在线切换时不触发该脚本

    当MHA到主库 192.168.1.220 之间的网络出现问题时,再通过从库 192.168.1.221(该从库尽量不要选择备主)进行登录验证,两次验证都出现问题时,MHA 认为主库宕机。

    MHA node 端常用工具(这些工具由 manager 触发,不需人工操作):

    save_binary_logs:保存和复制 master 的二进制日志

    apply_diff_relay_logs:识别差异的中继日志事件,并将其差异的事件应用到其他从库

    purge_relay_logs:MHA 在切换过程中,可能依赖从库的 relay log,利用该脚本采用定期清除 relay log 的方式,防止其自动清除(该脚本需要手工在从库上进行部署,具体部署方法后面文章详细说明),该脚本在从库上需要有数据库的 SELECT, RELOAD, SUPER 权限才可以执行。

    部分细节说明

    软件下载地址:

    强烈建议使用MHA作者的git地址下载0.56版本的tarball,其git地址:

    https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads,

    其他地址如 Google code中的软件包,笔者经过测试,都会有bug,Google code地址:

    https://code.google.com/p/mysql-master-ha/downloads/list,可自行测试。

    VIP是通过脚本方式实现,分别配置在 master_ip_failover 和 master_ip_online_change中,核心代码为:

    以此方式下掉原故障主库VIP,在新的主库上添加VIP。

    本次 MHA 架构使用 VIP,多数公司使用域名方式连接 DB,可通过修改域名解析到VIP,重启应用,即可快速完成 MHA 架构的上线。

    授权相关说明。由于从库在本地应用差异的 relay log 时,需要对所有 DB 有 all 权限,所以 MHA 的授权时,防止权限外泄,要指定所有节点(manager 和 node)的具体 IP 地址。

    本章只介绍了 MHA 理论相关的方面,如有不当之处还望留言多多指教。下一次会将全部代码贴出来,可以直接使用进行搭建 MHA 。

    参照:

    1.《深入浅出MySQL 数据库开发、优化与管理维护(第二版)》

  • 相关阅读:
    CF1202F You Are Given Some Letters...
    CF1178E Archaeology
    PTA (Advanced Level) 1005 Spell It Right
    PTA (Advanced Level) 1004 Counting Leaves
    Qt5——从零开始的Hello World教程(Qt Creator)
    PTA (Advanced Level) 1003 Emergency
    PTA (Advanced Level) 1002 A+B for Polynomials
    HDU 1272 小希的迷宫
    FZU 2150 Fire Game
    HihoCoder
  • 原文地址:https://www.cnblogs.com/fat-girl-spring/p/14582279.html
Copyright © 2011-2022 走看看