mysql-master-ha
MHA for MySQL: Master High Availability Manager and tools for MySQL
https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2
MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10—30秒内),完成故障切换,部署MHA,可避免主从一致性问题,节约购买新服务器的费用,不影响服务器性能,易安装,不改变现有部署。
还支持在线切换,从当前运行master切换到一个新的master上面,只需要很短的时间(0.5-2秒内),此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护。
在有高可用,数据一致性要求的系统上,MHA 提供了有用的功能,几乎无间断的满足维护需要。
优点1 master自动监控和故障转移
在当前已存在的主从复制环境中,MHA可以监控master主机故障,并且故障自动转移。
即使有一些slave没有接受新的relay log events,MHA也会从最新的slave自动识别差异的relay log events,并apply差异的event到其他slaves。因此所有的slave都是一致的。MHA秒级别故障转移(9-12秒监测到主机故障,任 选7秒钟关闭电源主机避免脑裂,接下来apply差异relay logs,注册到新的master,通常需要时间10-30秒即total downtime)。另外,在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性,dba就不用去处理一致 性问题。
当迁移新的master之后,并行恢复其他slave。即使有成千上万的slave,也不会影响恢复master时间,slave也很快完成。
DeNA公司在150+主从环境中用MHA。当其中一个master崩溃,MHA4秒完成故障转移,这是主动/被动集群解决方案无法完成的。
优点2 自动(手动)master故障转移
MHA可以用来只做故障转移,而不监测master,MHA只作为故障转移的交互。
优点3 在线切换master到不同主机
在很多情况下,有必要将master转移到其他主机上(如替换raid控制器,提升master机器硬件等等)。这并不是master崩溃,但是计划维护 必须去做。计划维护导致downtime,必须尽可能快的恢复。快速的master切换和优雅的阻塞写操作是必需的,MHA提供了这种方式。优雅的 master切换, 0.5-2秒内阻塞写操作。在很多情况下0.5-2秒的downtime是可以接受的,并且即使不在计划维护窗口。这意味着当需要更换更快机器,升级高版 本时,dba可以很容易采取动作。
优点4 master crash不会导致主从数据不一致性
当master crash后,MHA自动识别slave间relay logevents的不同,然后应用与不同的slave,最终所有slave都同步。结合通过半同步一起使用,几乎没有任何数据丢失。
优点5 MHA部署不影响当前环境设置
当你需要升级MHA到新版本时,不需要停止mysql,仅仅更新HMA版本,然后重新启动MHAmanger即可。
MHA最重要的一个设计理念就是尽可能使用简单。使用与5.0+以上主从环境,其他HA方案需要改变mysql部署设置,MHA不会让dba做这些部 署配置,同步和半同步环境都可以用。启动/停止/升级/降级/安装/卸载 MHA都不用改变mysql主从(如启动/停止)。
优点6 不增加服务器费用
MHA 包含MHA Manager和MHA node。MHA node运行在每台mysql服务器上,Manager可以单独部署一台机器,监控100+以上master,总服务器数量不会有太大增加。需要注意的是 Manager也可以运行在slaves中的一台机器上。
优点7 性能无影响
当监控master,MHA只是几秒钟(默认3秒)发送ping包,不发送大的查询。主从复制性能不受影响
优点8 适用任何存储引擎
Mysql replication 是同步或半同步。当master崩溃时,很有可能一些slave还没有接受最新的relay log events,这意味着每一个slave都相互处在不同的状态。人为修复一致性问题显得不再平凡。没有一致性问题,主从也可能不会启动(如 duplicate key error)。花费1个多小时重新启动主从复制显得不同寻常。
缺点1 虽然MHA试图从宕机的主服务器上保存二进制日志,但也会有问题。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失最新数据。
缺点2 当主DB故障,切换到另外的服务器上后,即使恢复了原来的主DB,也不能立即加入整套MHA系统中,得重新部署。而且当发生一次切换后,管理节点的监控进 程就会自动退出,需要用脚本来自动启动。另外还得删除app1.failover.complete这个文件,否则新的主DB出现问题MHA就不会切换 了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26735168/viewspace-2096308/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26735168/viewspace-2096308/