我一直在研究数据中心间 MySQL 的高可用性（HA）解决方案。
对于位于同一物理环境中的服务器，我更喜欢使用主动被动方法的双主控和心跳（浮动 VIP）。心跳通过串行连接和以太网连接进行。
最终，我的目标是在数据中心之间保持相同级别的可用性。我希望在两个数据中心之间动态进行故障转移，而无需人工干预，同时仍保持数据完整性。
上面会有 BGP。两个位置都有 Web 集群，它们有可能路由到双方之间的数据库。如果站点 1 上的互联网连接中断，客户端将通过站点 2 路由到 Web 集群，然后路由到站点 1 中的数据库（如果两个站点之间的链接仍然正常）。
在这种情况下，由于缺乏物理链路（串行），更有可能出现脑裂。如果两个站点之间的 WAN 发生故障，VIP 最终会同时出现在两个站点上，从而导致各种令人不快的情况，从而导致不同步。
我看到的另一个潜在问题是未来难以将该基础设施扩展到第三个数据中心。
网络层不是重点。现阶段的架构很灵活。同样，我的重点是维护数据完整性以及使用 MySQL 数据库自动故障转移的解决方案。我可能会围绕这一点设计其余部分。
您能否推荐一个针对两个物理上不同的站点之间 MySQL HA 的经过验证的解决方案？
感谢您花时间阅读本文。我期待阅读您的建议。
答案1
您将面临“CAP”定理问题。您无法同时拥有一致性、可用性和分区容忍性。
DRBD / MySQL HA 依赖于块设备级别的同步复制。当两个节点都可用时，或者当其中一个节点出现临时故障、重新启动等情况，然后恢复时，这种情况是可以的。当您遇到网络分区时，问题就开始了。
当您在两个数据中心运行时，网络分区极有可能发生。本质上，任何一方都无法区分分区与另一方节点故障。辅助节点不知道它是否应该接管（主节点发生故障）或不接管（链接断开）。
当您的机器位于同一位置时，您可以添加辅助通信通道（通常是串行电缆或交叉以太网）来解决此问题 - 这样辅助通道就知道主通道何时真正关闭，并且这不是网络分区。
下一个问题是性能。虽然当您的机器具有低延迟连接（例如千兆以太网 - 但有些人使用专用高速网络）时，DRBD 可以提供不错的**性能，但网络延迟越大，提交事务所需的时间就越长***。这是因为它需要等待辅助服务器（当它在线时）确认所有写入，然后才能向应用程序说“OK”，以确保写入的持久性。
如果您在不同的数据中心执行此操作，即使它们很近，通常也会有几毫秒的延迟。
** 仍然比一个像样的本地 IO 控制器慢得多
*** 您不能将 MyISAM 用于高可用性 DRBD 系统，因为它无法从异常关机中正确/自动恢复，而这在故障转移期间是必需的。
答案2
如何使用 VLAN 将两个（或更多）数据中心的所有服务器连接在一起。然后，您可以使用 CARP 进行自动故障转移。使用数据库复制来保持一切同步。
如果您拥有数据中心，您可以确保每个数据中心都有多个 WAN 上行链路。
答案3
您的第一阶段应该是将当前的 HA 解决方案升级为使用 OpenAIS 作为集群成员层的解决方案：这将为您提供很大的灵活性，并且考虑到站点之间的低延迟链接，可能能够实现跨越。PaceMaker 和 RHEL Clustering 支持这一点。
对于自动数据中心故障转移，您确实需要第三个站点作为决胜局，否则您的站点将无法区分站点间路由问题和远程站点故障。微软有一些令人惊讶的很好的网络广播涵盖了这一领域：
显然，确切的技术并未映射到 Linux 领域，但概念是相同的。
答案4
请注意，您可能无法使用 BGP，因为最小的可路由块是 4k，即 /22，祝您好运。可能需要基于 DNS 的解决方案。