我运行一个主机大约50Gb数据的MySQL服务器（主要用于大约250个网站），我想知道我的选项是用来设置一个冗余的MySQL集群吗？ 主要目的是为了维护或重新启动服务器，而不影响数据库可用性 – 其次，如果活动服务器出现问题，将会出现某种热故障切换 。
我的理解是， mysql-cluster要求数据库完全包含在内存中，并且有这么多的数据，这不是一个实际的select。
你需要的是复制。 虽然有很多人使用MySQL复制，但我已经处理了足够的（数十个大容量生产MySQL实例），知道这不是一个成功的select。 这是相当脆弱的，并会在不方便的时候失败。 现在，我倾向于使用诸如DRBD之类的块复制解决scheme来使MySQL存储保持一致。
就故障转移而言，MySQL复制并不能很好地解决这个问题。 虽然从主机到从机的故障是一个相当自动化的操作，但处理后果（以其他方式重新运行复制）始终是一个手动过程，需要戳和刺激才能确保一切正常。 无论您select哪种复制方法，我都会使用心跳来检测是否一切正常，以及当前活动的服务器何时崩溃，确保有序接pipe资源。
检查嗯自动故障转移。 确保将这两台服务器设置为主服务器，以便进行双向复制。 另外，如果您使用的是自动增量，请确保将其设置为不使用冲突（请参阅本文以了解详细信息）。
最后，使用Maatkit来确保服务器之间没有不一致。
我们一直在使用DRBD / Heartbeat一段时间，这很不错，但对于虚拟服务器的情况（我们有这种情况）并不理想，因为它应该在服务器之间有多个连接，在虚拟环境中，所有的连接（串口，以太网等）基本上是通过同一根电线来传输的 – 所以当有一次超时的时候，它们都会超时。 （我意识到我可以把一个真正的串行电缆放在那里，但是我不能再在主机之间迁移我的虚拟机 – 这是我不想放弃的能力）
在这种情况下，我偶尔会得到一个情况：服务器都不能看到对方，同时又变成了“主”（这是一种叫做“脑裂”的情况，这是一个令人头疼的问题）
但是，与之前使用的binlog复制相比，它绝对是一个更好的解决scheme – 从目前来看，这听起来像是一个比mysql-cluster更强大的解决scheme。
从MySQL 5.1开始，MySQL集群数据（尽pipe不是它的索引）可以存储在磁盘上： MySQL 5.1中的新特性
然而，我同意womble，鉴于mysql-cluster / ndb的许多限制和复制的脆弱性，我会毫不犹豫地考虑一个通用的解决scheme。 对于一个具有良好理解的使用模型的单个数据库和一个与开发人员一起工作的真正的DBA？ 可能。 但不支持支持许多不同应用程序的通用数据库服务器群集。
相反，我想要使用DRBD方法，或者只是把钱扔在问题上，并使用SAN。 没有解决scheme，我知道是完美的。