MySQL与Innodb提供了一个很好的通用解决方案，并且可能会在不太昂贵的硬件上很容易地满足您的性能要求。它可以轻松地在具有良好磁盘的双四核盒子上每秒处理数千次更新。内置的异步复制将在很大程度上满足您的可用性要求 - 但如果主数据库发生故障，您可能会丢失几秒钟的数据。修复主数据库时，其中一些丢失的数据可能是可恢复的，或者可以从应用程序日志中恢复：您是否可以容忍这取决于系统的工作方式。一种损耗较小但速度较慢的替代方案是将MySQL Innodb与主磁盘和故障转移单元之间的共享磁盘一起使用：在这种情况下，故障转移单元将在主设备发生故障时接管磁盘而不会丢失数据 - 只要主节点没有某种磁盘灾难。如果共享磁盘不可用，则可以使用 DRBD 通过在写入磁盘块时将磁盘块同步复制到故障转移单元来模拟此操作：这可能会对性能产生影响。
使用Innodb和上面的复制解决方案之一可以将您的数据复制到故障转移单元，这是解决恢复问题的很大一部分，但是需要额外的胶水来重新配置系统以使故障转移单元联机。这通常是使用集群系统执行的，如RHCS或Pacemaker或Heartbeat（在Linux上）或Windows的MS Cluster。这些系统是工具包，您只能亲自动手将它们构建成适合您环境的解决方案。但是，对于所有这些系统，当系统注意到主系统出现故障时，会有一个短暂的中断期，并将系统重新配置为使用故障切换单元。这可能是几十秒：尝试减少这种情况可能会使故障检测系统过于敏感，并且您可能会发现系统不必要地进行了故障转移。
向上移动，MySQL NDB旨在缩短恢复时间，并在一定程度上帮助扩展数据库以提高性能。但是，MySQL NDB的适用范围相当窄。系统将关系数据库映射到分布式哈希表，因此对于涉及跨表的多个联接的复杂查询，MySQL组件和存储组件（NDB节点）之间存在相当多的流量，使得复杂的查询运行缓慢。但是，适合的查询确实运行得非常快。我已经看过这个产品几次了，但我现有的数据库太复杂了，不适合，需要大量的重新设计才能获得良好的性能。但是，如果您处于新系统的设计阶段，那么如果您能够牢记其约束，则NDB将很好地工作。另外，您可能会发现您需要相当多的机器来提供良好的NDB解决方案：几个MySQL节点加上3个或更多NDB节点 - 尽管如果您的性能需求不是太极端，MySQL和NDB节点可以共存。
即使是MySQL NDB也无法应对整个站点的丢失 - 数据中心的火灾，管理错误等。在这种情况下，通常需要运行另一个到 DR 站点的复制流。这通常是异步完成的，以便站点间链接上的连接点不会使整个数据库停止。这是由NDB的地理复制选项（在付费电信版本中）提供的，但我认为MySQL 5.1及更高版本可以在本地提供此功能。
不幸的是，我对Zookeeper和Chubby知之甚少。希望其他人可以掌握这些方面。
