关于使用 DRBD 为 MySQL 提供 HA 的问题。
我需要确保当发生故障转移时，我的备份 MySQL 实例始终处于正常运行状态。例如，如果主实例在提交事务的过程中中途死亡，会发生什么情况？
我们最终会得到 mysql 无法处理的复制到辅助节点的数据吗？或者，如果在两个节点同步时网络中断，导致并非所有数据都能够传输，该怎么办？
似乎有可能陷入这样一种状态：辅助服务器上的数据不完整，导致 mysql 无法启动并读取数据库。
我是否遗漏了什么？
答案1
当然，这取决于故障转移的性质。听起来你已经知道问题的答案了。
从根本上讲，DRBD 是网络 RAID 镜像。块入 -> 块出。您可以同步或异步运行，具体取决于您的延迟要求。您选择哪种方式会极大地影响您的副本是否具有崩溃一致性。
简化到这个级别，您的问题就变成了：“当 MySQL 启动并读取数据文件时会发生什么？”要么您的数据格式正确且处于静止状态，并且启动时没有出现任何问题，要么数据崩溃时保持一致，并且您可能存在一致性问题。（当然，也有可能磁盘损坏，这也可能是 DRBD 的问题，特别是如果您以某种方式最终出现裂脑情况。）通常，如果您使用事务引擎，它可以通过重放日志来恢复自身，但有时您会遇到更严重的问题。DRBD 和其他共享块存储（如共享 SAN 卷或（但愿不会）NFS 上的数据库文件）的情况一样。
理论上，符合 ACID 的数据库应该始终能够从不完整的事务中优雅地恢复。实际上，尤其是对于某些 MySQL 版本，情况并非总是如此（主要是因为 MySQL 并没有最优秀的 ACID 合规性，尽管近年来情况有所改善）。经常进行备份始终是明智之举。
没有任何方法可以确保任何高可用性系统在发生故障转移时始终能够继续工作。您能做的最好的事情就是在构建 HA 解决方案时做出正确的决定，并对其进行测试以验证您对出现问题时系统将如何运行的假设。
就你的情况而言，你可能要考虑一个备用从属服务器，以防主服务器磁盘出现一致性问题。当然，这需要手动操作，但至少你不会恢复几小时或几天前的数据。
答案2
我认为 DRBD 不是这里的正确解决方案。
根据您的工作量，您可能需要以下一项或多项的组合
- 主从复制
- 大师 - 大师
- 主人——有奴隶的主人
- MySQL 集群
第一个是相当简单的设置，第二个有一些警告，例如裂脑，STONITH（射击头部其他节点）等。
这可能是一个复杂的话题，我建议你研究和测试深入了解您的预期用途。每种用途都有很多指南。
答案3
如果您可以控制应用程序代码，则可以使用 MySQL Galera 同步复制而不是 DRBD。Galera 要求集群节点成员数量为奇数，最好至少为三个，这样多数票才能确定谁的数据正确。您可以使用 HAProxy 增强 MySQL Galera。因此，在每个网络块上，您都可以运行 HAProxy，然后连接并检查 MySQL 服务器是否处于活动状态。
以下是一些限制 http://www.codership.com/wiki/doku.php?id=limitations
答案4
我几年前尝试过 DRBD，但在故障转移后遇到了很多问题。
我将所有数据和日志移至通过双 SAS 控制器连接的单独驱动器阵列，从而从图片中删除了 DRBD。我们为此使用了 IBM DS-3525。此设置的优点是辅助系统始终处于连接状态，只是没有安装分区。我使用 Corosync 来控制故障转移。当主服务器恢复时，Corosync 会关闭 MySQL，卸载分区，将它们重新安装到主服务器上，然后重新启动 MySQL。即使主机在事务过程中死机，InnoDB 也会恢复。
在这个范围内，驱动器阵列的价格约为 15-20,000 美元。如果您考虑到您需要 2 个（更不用说每个节点都需要同等硬件），那么阵列的成本是合理的。驱动器阵列的另一个好处是速度。就我而言，我使用多路径驱动程序，这样系统就可以同时使用两个控制器。与内部 raid 相比，吞吐量通常要高得多。
Christian 提到了 Galera。请查看 Percona Cluster。它使用 Galera，这是一个非常有希望的补充，可以让 MySQL 的可靠性更上一层楼。