War*_*ner 19 mysql linux disaster-recovery heartbeat linux-ha
我一直在研究数据中心之间 MySQL 的高可用性 (HA) 解决方案。
对于位于同一物理环境中的服务器，我更喜欢使用主动被动方法的带心跳的双主（浮动 VIP）。心跳通过串行连接和以太网连接。
最终，我的目标是在数据中心之间保持相同级别的可用性。我想在没有人工干预的情况下在两个数据中心之间进行动态故障转移，并且仍然保持数据完整性。
上面会有 BGP。两个位置的 Web 集群，这将有可能路由到双方之间的数据库。如果站点 1 上的 Internet 连接中断，则客户端将通过站点 2 路由到 Web 集群，如果两个站点之间的链接仍然存在，则路由到站点 1 中的数据库。
在这种情况下，由于缺乏物理链接（串行），更有可能发生脑裂。如果两个站点之间的 WAN 出现故障，VIP 最终会出现在两个站点上，在那里各种令人不快的情况可能会导致不同步。
我看到的另一个潜在问题是，将来难以将此基础设施扩展到第三个数据中心。
网络层不是重点。在这个阶段，架构是灵活的。同样，我的重点是维护数据完整性以及与 MySQL 数据库的自动故障转移的解决方案。我可能会围绕此设计其余部分。
您能否为两个物理上不同的站点之间的 MySQL HA 推荐一个经过验证的解决方案？
感谢您抽出时间来阅读。我期待着阅读您的建议。
您将面临“CAP”定理问题。您不能同时拥有一致性、可用性和分区容错性。
DRBD / MySQL HA 依赖于块设备级别的同步复制。当两个节点都可用时，这很好，或者如果一个节点遇到临时故障，重新启动等，然后又回来了。当您获得网络分区时，问题就开始了。
当您在两个数据中心运行时，极有可能出现网络分区。本质上，任何一方都无法区分一个分区和另一个失败的节点。辅助节点不知道它是否应该接管（主节点发生故障）或不（链接消失）。
当您的机器位于同一位置时，您可以添加辅助通信通道（通常是串行电缆或交叉以太网）来解决此问题 - 因此辅助设备知道主设备何时真正关闭，并且它不是网络分区.
下一个问题是性能。虽然当您的机器具有低延迟连接（例如千兆以太网 - 但有些人使用专用高速网络）时，DRBD 可以提供不错的性能**，但网络的延迟越长，提交事务所需的时间就越长*** . 这是因为它需要等待辅助服务器（当它在线时）在对应用程序说“OK”之前确认所有写入，以确保写入的持久性。
如果您在不同的数据中心执行此操作，通常会有更多毫秒的延迟，即使它们就在附近。
** 仍然比一个体面的本地 IO 控制器慢得多
*** 您不能将 MyISAM 用于高可用性 DRBD 系统，因为它无法从不正常关机中正确/自动恢复，这是故障转移期间所需的。