我希望有一个高可用性的MySQL系统，在Amazon EC2实例上运行自动故障转移。
解决这个问题的标准方法是Heartbeat + DRBD问题，但是我发现很多post提示DRBD在EC2上不起作用，尽pipe没有人确切地说明了为什么。 显然，在虚拟化环境中，连续的心跳或不同的networking是不可能的。 让不同的服务器处于不同的可用区域也是一件好事，但是我们遇到了一个非常棘手的问题 。
什么是人们对在“云”中拥有高运行时间解决scheme的看法？
注意：这个问题是在RDS发布之前被问及的，这个问题对于今天的现代IT专业人士来说是一个很好的自动答案。 🙂
我想你真的想要一个最近添加到AWS的多区域RDS设置。
请阅读更多信息： http ： //aws.typepad.com/aws/2010/05/amazon-rds-multi-az-deployment.html
如果你不会问AWS，我会build议包括DRBD在内的设置。 这将确保两台服务器始终保持同步。 但是我几乎100％肯定这在AWS上还是不可能的。
一般来说，我会小心快照和所有这一切 – 这不是一颗银子弹！ 在AWS上需要很长时间。 实例存储本身是a）不快，b）不持久！ 即使使用EBS，速度也不是很快，您仍然需要停止I / O以获得一致的快照。
廉价的简单选项 – 自己在EC2的不同数据中心上安装mysql，并在它们之间build立master / master复制。 将您的前端Web服务器指向这些复制的MySQL服务器上的每个数据中心。 如果您的主站点上的内容运行状况检查失败，则会在每个位置的前端Web服务器之间设置自动DNS故障转移 – 它会自动将客户端stream量redirect到其他数据中心内的复制站点 – 您修复主站点并开始传送运行状况检查再次 – 然后stream量将自动故障回复到主站点。 我一直这样做 – 即使在不同的供应商之间，即EC2和Linode之间。 它工作的很好，客户端stream量故障转移发生在不到1分钟的时间。 您可以从dnshat.com获得自动的DNS故障转移，价格便宜。
我会默认使用浮动VIP进行主动/被动双主复制。 （心跳，OpenAIS，MMRM或起搏器）
我想不出为什么这不是一个好主意。 你可以吗？
MMRM
自己动手的select是将MySQL安装到EBS卷，使用弹性IP或dynamicDNS来切换指向哪个服务器失败。
您将需要一个外部服务器监控心跳，然后卸载EBS卷，重新安装到您的备份服务器，然后重新映射IP或更改DNS。 如果您担心文件系统本身，那么您必须执行lvm快照或获取数据副本，然后您可以将其备份到S3或EBS卷。
我喜欢在EBS卷上拥有这些数据，因为如果这听起来令人感到恐惧，那么您可以抓取它的EBS快照进行备份，而不必介入lvm的东西。
另外要注意的是，亚马逊有一个我没有使用的企业MySQL包 ，但可能是一个更好的select。 支持合同的价格通常很合理。