关于使用DRBD为MySQL提供HA的问题
我需要确保备份MySQL实例在发生故障转移时总是处于function状态。 例如，如果主模具部分通过交易进行交易，会发生什么情况？
我们将最终将数据复制到MySQL无法处理的次要数据？ 或者，如果networking在两者同步的同时消失了，而不是所有的数据都能通过。
似乎有可能进入一个状态，在辅助数据不完整，使得无法启动和读取数据库。
我错过了什么吗？
自然，这取决于故障转移的性质。 这听起来像你已经知道你的问题的答案。
DRBD从根本上说就是networkingRAID镜像。 阻止 – >阻止。 您可以同步或asynchronous运行，具体取决于您的延迟要求。 你select哪一个对你的副本是否符合崩溃是非常重要的。
降低到这个水平，你的问题就变成：“当MySQL启动并读取数据文件时会发生什么？ 无论您的数据是格式良好还是默认情况下，它开始顺利，或崩溃一致，并且可能有一致性问题。 （当然也有可能出现磁盘损坏，这也可能是DRBD的一个问题，特别是如果你以某种方式结束了脑裂情况）。通常，它可以通过重播日志来恢复自身if你正在使用事务引擎，但有时你会遇到更严重的问题。 DRBD与其他共享块存储一样，例如共享SAN卷或NFS上的（禁止）数据库文件。
假设一个符合ACID的数据库应该总是从不完整的事务中正常恢复。 在实践中，特别是在某些MySQL版本的情况下，情况并非总是如此（主要是因为MySQL不具备ACID合规性的最大遗产，尽pipe近些年来情况有所改善）。 保持频繁的备份总是一个明智的做法。
没有办法确保任何高可用性系统将始终继续故障转移。 您可以做的最好的方法就是在构build高可用性解决scheme时做出正确的决定，并testing其中的垃圾，以validation您在出现问题时如何行事的假设。
在你的情况下，如果遇到主磁盘上的一致性问题，可能需要考虑备用从设备。 当然，这需要人工进行推广，但至less不会恢复数小时或数天的数据。
我不认为DRBD是正确的解决scheme。
根据你的工作量，你可能需要一个或下面的组合
第一个是相当微不足道的设置明智的第二个有几个警告像裂脑，STONITH（拍摄其他节点在头）等。
这可能是一个复杂的话题，我build议您深入研究和testing您的预期用途。 他们每个人都有很多的指导。
如果您可以控制应用程序代码，则可以使用MySQL Galera同步复制而不是DRBD。 Galera有要求奇数群集节点成员最好是至less三个如此多数票胜利是正确的数据。 你可以用HAProxy来扩充MySQL Galera。 因此，在每个Web Brick上运行HAProxy，然后连接并检查MySQL服务器是否处于活动状态。
以下是一些限制http://www.codership.com/wiki/doku.php?id=limitations
如果你
那么你可以合理地确信你的数据库是高度可用的。 在你的例子中，如果它在事务中间失败，它将被中止，你的应用程序应该希望重试，并希望能够连接到你希望有一个一致的数据副本的第二个节点（因为所有的写入是同步的写入到两个节点，然后返回到已写入的数据库）。
几年前，我尝试了DRBD，但在故障转移后遇到了很多问题。
通过将所有数据和日志移动到通过双SAS控制器连接的独立驱动器arrays，我从图中删除了DRBD。 我们为此使用IBM DS-3525。 这种设置有什么好处是二级系统总是连接，只是没有安装分区。 我使用Corosync来控制故障切换。 当主服务器返回时，CorosyncclosuresMySQL，卸载分区，将其重新装入主服务器，启动MySQL备份。 即使主机在交易中间死亡，InnoDB也会恢复。
驱动arrays在这个范围内运行约15-20K。 如果考虑到所有东西都需要2个（更不用说每个节点需要相同的硬件），那么arrays的成本就是合理的。 驱动器arrays的另一个好处是速度。 就我而言，我使用多path驱动程序，因此系统可以同时使用两个控制器。 吞吐量与内部RAID相比通常要高得多。
基督教提到加莱拉。 检查Percona集群。 它使用Galera，并且是一个非常有前途的增加MySQL的可靠性。