经常有人请求我们为他们的各种类型数据库,尤其是MySQL构建完全自动化的HA 故障转移系统。这件事情可能会令你感到意外,但是我们并不是自动故障转移的狂热粉丝,因为我们感觉到数据损坏的风险以及导致额外宕机的几率太高。

但是,应当客观地看待事情,我们确实每年大约会有1个系统崩溃,所以,完全自动化的监测/故障转移还是有用的。所以,我们必须非常小心,确保任何“解决方案”都不会造成多次停机。不幸的是,这些工具和系统太复杂,很容易造成故障转移过于频繁、移来移去、系统崩溃、机器分离控制或造成额外的数据问题。

随着工具越来越先进,这些层面的故障转移性能也不断改变。因为人们要求有更长的线上运行时间,尤其是大型电商或其它直接以收入为基础的系统。

当考虑自动HA故障转移系统时,有几个问题必须牢记在心。许多人希望拥有或认为自己想拥有一个完美的全自动化监控、故障转移、故障恢复系统。但是,除了集群机之外,这种情况是不存在的;要想实现这种完美情况是有害的,主要是因为有许多问题会降低整个系统的可靠性,这个风险是很高的。

首先要消除的问题是自动故障恢复,这会使情况变得很糟糕,很难做到完全正确。没有工具能够做好这件事情,更不必说涉及到业务、技术或运营问题以及各种组合类型的问题,这些情况太复杂了,不可能在所有情况下都实现自动化。幸运的是,自动故障恢复并非完全必须的,可以忽略这个问题。但重要的是,要记住这并不是说使用工具进行手动故障恢复是不可能的,恰恰相反,手动故障恢复是能够做到的而且也是有必要使用的,但是不是自动恢复。

许多系统有多个MySQL数据库服务器,多数情况下是一对主-从机的模式,在应用层实现读写分离。大型系统有更多的读从机,在应用层实现负载均衡或在主机上第4层上通过HAproxy进行调度。

有一点很重要,就是你要时时刻刻尽可能地将从机配置成与主机一样的配置,并且准备好这些从机以便随时接替主机。可能在主从机之间会有些差异,如InnoDBtrx commit,binlogsyncing(二进制日志同步)等等,如果确实有这些差异,你必须在从机转变成主机的时候,调整这些关键设置。

理想的情况是所有的读和负载平衡IP都是虚拟的,但是,由于包含额外工作,这就意味着这种情况在真实系统中基本很少发生。但是,我们仍然朝着这个方向工作,所有的自动或半自动化系统都应该正确地运作。从实际情况来看,如果没有自带的IP及VIP的话,在故障系统中正常工作会变得很困难。

最古老的MySQL HA 方法是使用DRBD作为基础磁盘系统。但是这种方法变得越来越不常用了,因为DRBD问题变得越来越明显,尤其是对于大型数据库而言,这个问题更明显。此外,也浪费了一台备用服务器,因为这个服务器根本用不到。有了DRBD,实现故障转移就变得轻而易举了,只需要转移IP,安装文件系统并开启数据库。虽然可能并非如此简单,而且我们也看见过有趣的故障情形,尤其是当从机在新主机binlog之前的话,会造成binlog丢失,但是,总的来说,有了DRBD,故障转移还是比较容易的。

此外,有许多工具可以帮助进行故障转移,有手动工具也有自动工具。有些工具比较古老,有些是新的,有些可能比其它工具要复杂。基本来说,这些工具可以帮助顺利地从写主机转移到从机上,包括选择最好的从机、移动所有的IP、调整配置、最重要的是,改变所有从机,使它们使用新的主机(即使VIP会因为日志位置改变而移动)。

这些工具包括MMM,但是已经不再推荐使用该工具了,因为这个工具会努力地做许多事情并且会带来上述许多问题。更加流行的一个工具是Yoshinori Matsunobu的MHA,这很可能是当前最简单最好用的工具,并且还具有商务支持功能。该工具只做基本的事情,不额外做其它事情,解决了许多MMM问题,甚至需要一个管理节点来控制一切。

Percona有自己的Percona Replication Manager(PRM),它使用PaceMaker(是LinuxHA的一部分)以及Corosync和bash脚本来管理所有事项,构建了一个接近于集群器的东西。但是,该工具配置很复杂而且有许多活动部件,会把事情搞糟(包括自动故障恢复)。这很可能是当今最好最强的工具。

Continuent的Tungsten Replicator是另一款功能强大的工具,不仅是开源的也具有商业功能。通过一组专业的子系统来代替整个MySQL复制系统(设计该子系统是为了解决所有这些问题)。但是,确实是需要使用Java和Ruby 的。

HA的最后一个级别就是集群器,如Percona Cluster或MariaDB Cluster。这两个集群器都使用Galera,这是一个特殊的复制系统,它给MySQL增加了许多额外的功能,以便做好集群。这是名符其实的实时主机-主机-主机集群器,但是使用所有标准的MySQL配置、节点、行为和工具(与MySQL集群器不同)。集群器是独立的实体机器,不单独作为服务器使用。所有的节点都是激活的读机器和写机器,任何一个客户机可以在任何时候使用任意一台服务器。但是,总的来说,需要3个节点。

总之,有许多方法可以管理MySQL HA和故障转移,从什么也不做到采用脚本系统到先进的复制器再到完全集群器。这些是难以做好的,都有不同的复杂程度,有不同的风险和挑战。但是,使用正确的工具可以帮助您提高整个系统的可靠性和可用性,使您24×7小时在线。