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