详解MySQL高可用方案:MySQL MHA架构、原理、应用场景等
概述 MySQL高可用,顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作,并且最低要求是要保证数据一致性。因此,对于一个MySQL高可用系统需要达到的目标有以下几点:
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 ![]() 如果想要正确恢复:
而MHA可以全自动的处理以上这些问题。 MHA架构 MHA架构如下: ![]() 可实现master工作状态的监控以及宕机时的故障转移 MHA原理 MHA原理如下图: ![]()
MHA的主要特性
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架构。 (编辑:好传媒网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |