高可用性MySQL的体系结构，可在物理上不同的位置进行自动故障转移

我一直在研究数据中心之间MySQL的高可用性（HA）解决方案。

对于位于同一物理环境中的服务器，我更喜欢使用主动被动方法的具有心跳（浮动VIP）的双主服务器。心跳通过串行连接和以太网连接进行。

最终，我的目标是在数据中心之间保持相同的可用性水平。我想在两个数据中心之间进行动态故障转移，而无需人工干预，并且仍然保持数据完整性。

顶部将是BGP。两个位置的Web集群都有可能路由到双方之间的数据库。如果站点1上的Internet连接中断，客户端将通过站点2路由到Web群集，然后路由到站点1中的数据库（如果两个站点之间的链接仍然可用）。

在这种情况下，由于缺乏物理链接（串行），因此更可能出现大脑分裂的可能性。如果两个站点之间的WAN断开，则VIP最终将出现在两个站点上，在此各种不愉快的情况都可能导致不同步。

我看到的另一个潜在问题是，将来很难将此基础架构扩展到第三个数据中心。

网络层不是重点。此阶段的体系结构很灵活。同样，我的重点是提供解决方案，以维护数据完整性以及MySQL数据库的自动故障转移。我可能会设计其余的东西。

您能否在两个物理位置不同的站点之间推荐一种成熟的MySQL HA解决方案？

感谢您抽出时间来阅读。我期待着阅读您的建议。

您将面临“ CAP”定理问题。您不能同时具有一致性，可用性和分区容限。

DRBD / MySQL HA在块设备级别依赖于同步复制。当两个节点都可用时，或者如果一个节点遇到临时故障，重新启动等然后又回来时，这很好。当您获得网络分区时，问题开始。

当您在两个数据中心运行时，网络分区极有可能发生。本质上，任何一方都无法将分区与其他发生故障的节点区分开。次节点不知道是否应该接管（主节点发生故障）或不应该接管（链接消失）。

当您的机器位于同一位置时，您可以添加辅助通信通道（通常是串行电缆或交叉以太网）来解决此问题-因此，辅助服务器知道主服务器何时正常关闭，并且它不是网络分区。

下一个问题是性能。当您的计算机具有低延迟的连接（例如，千兆以太网-但有些人使用专用的高速网络）时，DRBD可以提供不错的性能**，但网络延迟越大，提交事务所需的时间就越长*** 。这是因为它需要等待辅助服务器（在线时）确认所有写入，然后对应用说“确定”以确保写入的持久性。

如果在不同的数据中心中执行此操作，则即使距离很近，通常也会有几毫秒的延迟。

**仍然比体面的本地IO控制器慢很多

***您不能将MyISAM用于高可用性DRBD系统，因为它无法从不干净的关机中正确/自动恢复，而故障关机是必需的。

使用VLAN将两个（或更多）数据中心的所有服务器绑定在一起怎么办。然后，您可以使用CARP进行自动故障转移。使用数据库复制使所有内容保持同步。

如果您拥有数据中心，则可以确保每个数据中心具有多个WAN上行链路。

您的第一步应该是将当前的HA解决方案升级到使用OpenAIS作为集群成员资格层的解决方案：这将为您提供很大的灵活性，并且由于站点之间的低延迟链接可能可以跨越。PaceMaker和RHEL群集支持此功能。

对于自动数据中心故障转移，您确实需要第三个站点来充当决胜局，否则您的站点将无法区分站点间路由问题和远程站点故障。微软在该领域有一些令人惊讶的出色网络广播：

Windows Server 2008多站点群集

显然，确切的技术并没有映射到Linux域，但是概念是相同的。

抱歉，这是另一个网络，但您需要考虑一下...

对于您提到的裂脑方案，您还可以在两个站点之间建立冗余链接，以减少这种情况的发生。

请注意，您可能无法使用BGP，因为最小的可路由块是4k，/ 22，祝您好运。可能需要基于DNS的解决方案。

根据您拥有的数据量，想要容纳的服务器数量等，给出正确的答案可能很困难。也就是说，我的答案可能不是一个，或者至少是您要寻找的答案。

没有针对MySQL的多个站点的可靠解决方案。但是有可行的解决方案。正如某些人指出的那样，是的，DRDB可以正常工作，但是其限制或可能的问题取决于您的设置。

您是否需要第三个站点（另一个数据中心）？如果是这样，您将需要多少时间和金钱？

考虑到每次添加主/从/ dns服务器，备份... ...添加自己要管理的服务器，就服务器数量而言，您的管理能力是多少？如果可以定义此数字，则可能必须放弃一些可能的解决方案，并朝着适合您的数字的方向努力，以使管理不会成为瓶颈。

考虑到数据中心不会经常停机，多个站点意味着负载平衡和一些DNS黑客入侵，这是否将在同一数据中心内？如果是这样，如果一个数据中心由于任何原因而宕机，您将遇到问题，因为DNS和负载平衡的很大一部分将位于此数据中心中。

因此，您可能必须计划这种裂脑情况。对于almsot每种可能的设置，解决吐口水情况的方法是不同的。同样，每种解决方案都需要X的时间。
从一开始就计划使用3个数据中心可能也容易得多。我不是MySQL专家，但我听说在生产中，如果遇到问题，拥有3个硕士比2个更容易。

可能会帮助您的一件事是一些网络供应商（如Zeus）提供的负载平衡服务，在这里看看，可能还有更多的公司提供这种服务。我敢肯定，这是有代价的，但有时会让您减少一些其他事情。

祝好运！

不建议将DRBD用于远程数据中心的解决方案，因为它需要的带宽可能会影响数据库和复制的速度。推荐的解决方案是“主服务器-主复制”。唯一的问题是，您需要交错自动增加字段。

如果您需要针对MySQL的真正的HA解决方案，则必须使用MySQL Cluster，因为在发生故障的情况下DRBD无法为您提供数据完整性。

我发现有关MySQL中可用选项的博客文章及其优缺点。 http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

克服串行电缆的缺失实际上非常容易，您可以使用黑暗时代的一种叫做调制解调器的东西-您在两端都有一个调制解调器，然后通过PPP链路运行Heartbeat。您也可以使用帧中继。两种方法都可以解决您对layer1 / 2冗余路径的任何担心。

话虽这么说-DRBD在任何链路上以超过300µs（请注意0.3ms）的延迟运行很快就变得很荒谬。

通过使用标准的MySQL复制和基于PPP＆eth的LinuxHA进行故障转移，将为您提供更好的服务。

至少那是我过去为客户所做的。