我一直在为数据中心之间的MySQL研究高可用性（HA）解决scheme。 对于位于同一物理环境中的服务器，我倾向于使用主动被动方法的心跳（浮动VIP）双主控。 心跳通过串行连接以及以太网连接。 最终，我的目标是保持相同的可用性级别，但是在数据中心之间。 我希望在两个数据中心之间进行dynamic故障切换而无需人工干预，并仍然保持数据完整性 上面会有BGP。 两个地点的networking集群，这将有可能通过双方之间的数据库。 如果在站点1上的Internet连接断开，则如果两个站点之间的链接仍处于运行状态，则客户端将通过站点2路由到Web群集，然后再到站点1中的数据库。 在这种情况下，由于缺乏物理链接（系列），更有可能分裂大脑。 如果广域网在两个站点之间发生故障，那么VIP将在两个站点上结束，在这两个站点上，各种令人不快的情况可能会导致asynchronous。 我看到的另一个潜在问题是，将来这个基础设施难以扩展到第三个数据中心。 networking层不是重点。 在这个阶段架构是灵活的。 同样，我的重点是维护数据完整性的解决scheme以及MySQL数据库的自动故障转移。 我可能会围绕这个devise其余的。 你能推荐一个经过validation的解决scheme吗？ 感谢您抽出时间来阅读。 我期待着阅读你的build议。
除了典型的Heartbeat / Pacemaker / CoroSync组合以外，Linux上是否有自动故障切换的主要select？ 特别是，我在EC2实例上设置了故障转移，它仅支持单播 – 不允许多播或广播。 我正在专门处理那些还没有自动故障转移function的软件，而且不支持多主环境。 这包括HAProxy和Solr等工具。 我有心跳+起搏器工作，但我不感到激动。 以下是我的一些问题： 心跳 – 本身，限于两个节点。 我想要3+。 起搏器 – 不可能自动configuration。 群集必须以法定人数运行，然后仍需要手动configuration。 CoroSync – 不支持单播。 起搏器工作得很好，虽然它的功率很难安装。 Pacemaker的真正问题是没有简单的方法来自动化configuration。 我真的想要启动一个EC2实例，安装Chef / Puppet，让整个集群不需要我介入就可以启动。
我们需要一些比ELB更高级的function（主要是L7检测），但是如何使用EC2等haproxy处理心跳和高可用性等问题并不明显。 很有可能我们在集群中需要3个或更多的haproxy节点，所以两个节点之间的简单心跳不起作用。 似乎在haproxy节点前面有一个心跳图层是可能的，可能使用IPVS，但是在EC2集群变化时处理configuration更改（通过有意的更改，如扩展，或无意，如丢失EC2节点）似乎不平凡。 优选地，该解决scheme将跨越至less两个可用区域。 回答问：不，会话不粘。 是的，我们需要SSL，但理论上可以完全由另一个设置来处理 – 我们能够将SSLstream量导向到与非SSLstream量不同的位置。