具有自动故障转移的MySQL H.A

Question

MySQL有许多不同的高度可用的解决方案，我想知道所有当前实现之间的区别是什么，下面是最新的实现：

• MySQL组复制(由Oracle)
• MySQL NDB集群(由Oracle编写)
• Galera集群(加雷拉)
• XtraDB集群( Percona)
• MySQL Fabric集群(由Oracle编写)
• MySQL Orchestrator (吉特布)

对于具有自动故障转移的高可用设置，建议的选项(或任何其他选项)是什么？(对于与具有同步复制的Server镜像等效的内容)

Answer 1

没有几个词比其他答案更多了(没有很好的格式)：

• 这不是HA技术，它是可视化拓扑和解决问题的工具，但仍然是基于底层的其他技术。
• Galera vs NDB，main (就我的观点而言)是受支持的引擎- NDB对InnoDB。
• 组复制是新的，我不使用它。

就像评论：

• 记住他们俩(Galera和NDB) --有大量的“在某些情况下.”，“可能是.”等等在文件中。可以正确地进行测试，但当您尝试将遗留应用程序传输到集群时，请在此之前进行适当的测试。我在项目中遇到过几个案例，比如坏的应用程序仍然在单节点(主从)上工作，并在Galera上死掉。错误设计的问题，但是客户端通过简单的测试将现场应用程序转移到“现代”技术。

特别是出于最后的原因，我非常怀疑每个数据中心大约有一个节点，取决于业务需要，您可以选择更好的-几秒钟延迟从后面的主人，或放缓每一个变化。它不可能在很小的交易中受到影响，在更复杂的交易中也可能是杀手。

Answer 2

您可能想要考虑的一个简单的解决方案是使用DRBD的主动/被动心脏起搏器/Corosync设置。最大的缺点是故障转移涉及崩溃恢复，但是如果您的ib_logfiles不是很大，并且在故障发生时可以忍受一点时间(无论崩溃恢复需要多长时间--可能需要几秒钟，取决于重做日志需要重放多少)，它可以简化您的生活。

使用DRBD时，数据复制发生在MySQL之外和块级，因此您可以避免在多个主模块之间重复键和数据一致性方面的任何问题。这也可以与从对中的活动服务器读取的MySQL复制从中组合。

没有一个HA解决方案是最适合每一种情况，而且有许多相互矛盾的意见。这个不是一个“写任何地方”的解决方案，所以如果这是你想要的，你很可能可以把它从清单上划掉。