概述

MySQL高可用，顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作，并且最低要求是要保证数据一致性。因此，对于一个MySQL高可用系统需要达到的目标有以下几点：
  • 数据一致性保证–这个是最基本的同时也是前提，如果主备的数据不一致，那么切换就无法进行，当然这里的一致性也是一个相对的，但是要做到最终一致性。
  • 故障快速切换–当master故障时这里可以是机器故障或者是实例故障，要确保业务能在最短时间切换到备用节点，使得业务受影响时间最短。
  • 简化日常维护–通过高可用平台来自动完成高可用的部署、维护、监控等任务，能够最大程度的解放DBA手动操作，提高日常运维效率。
  • 统一管理–当复制集很多的情况下，能够统一管理高可用实例信息、监控信息、切换信息等。
  • 高可用的部署–要对现有的数据库架构无影响，如果因为部署高可用，需要更改或者调整数据库架构则会导致成本增加。

MySQL MHA

MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案，来保证数据库系统的高可用，在宕机的事件内（通常10-30秒），完成故障转意，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署架构。 MHA（Master HA）为MySQL主从复制架构提供了automating master failover 功能。MHA在监控到master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过与其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。 相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

应用场景

一主多从的环境下，MySQL的主从复制是异步或是半同步。 Master发生故障的时候，有可能一部分（或者全部）的Slave未能获取到最新的binlog，造成Slave之间的binlog转发发生偏差。 如下图所示，Master宕机之后，id=102的binlog未能被发送到任何一个Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id=101的binlog
详解MySQL高可用方案--MySQL MHA架构、原理、应用场景等
如果想要正确恢复：
  • Master必须发出的ID=102的binlog
  • 还要消除各个Slave之间的差异性
而MHA可以全自动的处理以上这些问题。

MHA架构

MHA架构如下：
详解MySQL高可用方案--MySQL MHA架构、原理、应用场景等
可实现master工作状态的监控以及宕机时的故障转移

MHA原理

MHA原理如下图：
详解MySQL高可用方案--MySQL MHA架构、原理、应用场景等
  • 1、等待SQL线程执行完毕
  • 2、解析最新的Slave上的中继日志（relay log）的日志头（log Header），为其他各个服务器确定出差异位置
  • 3、将i1–>i2–>X 全部组成一个二进制日志

MHA的主要特性

  • 从master的监控到故障转移全部都能自动完成，故障转移也可手动执行
  • 可在秒级单位内实现故障转移
  • 可将任意Slave提升至master
  • 具备在多个点上调用外部脚本（扩展）的技能，可以用在电源OFF或者IP地址的故障转移上。
  • 安装和卸载不用停止当前的mysql进程
  • MHA 自身不会增加服务器负担，不会降低性能，不用追加服务器
  • 不依赖Storage Engine
  • 不依赖二进制文件的格式（不论是statement模式还是Row模式）

MHA组件

1、 Manager工具: – masterha_check_ssh : 检查MHA的SSH配置。 – masterha_check_repl : 检查MySQL复制。 – masterha_manager : 启动MHA。 – masterha_check_status : 检测当前MHA运行状态。 – masterha_master_monitor : 监测master是否宕机。 – masterha_master_switch : 控制故障转移(自动或手动)。 – masterha_conf_host : 添加或删除配置的server信息。 2、 Node工具(这些工具通常由MHAManager的脚本触发,无需人手操作)。 – save_binary_logs : 保存和复制master的二进制日志。 – apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。 – filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。 – purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。 3、自定义扩展： -secondary_check_script：通过多条网络路由检测master的可用性； -master_ip_failover_script：更新application使用的masterip； （需要修改） -shutdown_script：强制关闭master节点； -report_script：发送报告； -init_conf_load_script：加载初始配置参数； -master_ip_online_change：更新master节点ip地址；（需要修改）

总结

目前MySQL高可用方案可以一定程度上实现数据库的高可用，比如MMM，heartbeat drbd，NDB Cluster等。还有MariaDB的Galera Cluster，以及MySQL 5.7.17 Group Replication等。这些高可用软件各有优劣。在进行高可用方案选择时，主要是看业务对数据一致性方面的要求。不过出于对数据库的高可用和高可靠的要求，个人比较推荐使用MHA架构。 后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
详解MySQL高可用方案--MySQL MHA架构、原理、应用场景等