动物园管理员/胖子-vs-mysql ndb

这取决于您所管理的数据类型,以及所需的规模和容错能力。

我可以从动物园管理员的角度回答。在开始之前,我应该提到动物园管理员不是一个胖胖的克隆人。具体来说,它不会直接锁定。它的设计还考虑了不同的订购和性能要求。

在ZooKeeper中,系统状态的整个副本都是内存驻留的。更改使用原子广播协议进行复制,并在处理之前由大多数ZooKeeper服务器同步到磁盘(使用更改日志)。因为这个ZooKeeper具有确定性的性能,只要大多数服务器都启动,它就可以容忍失败。即使出现大停电,如停电,只要大部分服务器恢复正常,系统状态也会保持不变。存储的信息通常被认为是系统的基础真实性,因此这种一致性和耐久性保证非常重要。

动物园管理员给你的其他事情与监控动态协调状态有关。短暂的节点允许您轻松地进行故障检测和组成员身份。订购保证允许您进行领导选择和客户端锁定。最后,监视允许您监视系统状态并快速响应系统状态的变化。

因此,如果您需要管理和响应动态配置、检测故障、选择领导者等,那么ZooKeeper就是您要寻找的。如果需要存储大量数据,或者需要一个关系模型来存储这些数据,那么MySQL是一个更好的选择。

带有InnoDB的MySQL提供了一个很好的通用解决方案,并且在不太昂贵的硬件上很容易满足您的性能需求。它可以很容易地在一个双四核盒上处理每秒数千次的更新,该盒具有相当好的磁盘。内置异步复制将为满足可用性需求提供最大的途径,但如果主服务器出现故障,可能会损失几秒钟的数据。在修复主数据时,其中一些丢失的数据可能是可恢复的,或者可以从应用程序日志中恢复:是否可以容忍这一点取决于系统的工作方式。另一种损失较小但速度较慢的方法是在主设备和故障转移设备之间使用带有共享磁盘的mysql innodb:在这种情况下,只要主设备没有发生某种磁盘灾难,主设备发生故障时,故障转移设备就会接管磁盘,而不会丢失数据。如果共享磁盘不可用,可以使用drbd在写入时将磁盘块同步复制到故障转移单元来模拟:这可能会影响性能。

使用InnoDB和上面的一个复制解决方案可以将数据复制到故障转移单元,这在很大程度上解决了恢复问题,但是重新配置系统以使故障转移单元联机需要额外的胶水。这通常是通过集群系统(如rhcs、pacemaker、heartbeat(在Linux上)或用于Windows的MS集群工具来执行的。这些系统都是工具包,您只需将手弄脏就可以将它们构建成适合您环境的解决方案。但是,对于所有这些系统,都有一个短暂的停机期,而系统会注意到主系统出现故障,并重新配置系统以使用故障转移单元。这可能需要几十秒:尝试减少这一点会使故障检测系统过于敏感,并且您可能会发现系统发生不必要的故障。

向上看,mysql ndb旨在缩短恢复时间,并在某种程度上帮助扩展数据库以提高性能。但是,mysql-ndb的适用范围很窄。系统将一个关系数据库映射到一个分布式哈希表上,因此对于涉及跨表多个联接的复杂查询,mysql组件和存储组件(ndb节点)之间存在大量通信,使得复杂查询运行缓慢。然而,适合的查询确实运行得非常快。我已经看过这个产品几次了,但是我现有的数据库太复杂了,无法很好地适应,需要重新设计才能获得良好的性能。但是,如果您正处于一个新系统的设计阶段,那么如果您能够在执行过程中记住它的约束,那么NDB将工作得很好。另外,您可能会发现需要很多机器来提供一个好的NDB解决方案:几个MySQL节点加上3个或更多的NDB节点-尽管如果您的性能需求不太极端,MySQL和NDB节点可以共存。

即使是mysql-ndb也无法应对整个站点的丢失——数据中心的火灾、管理错误等。在这种情况下,通常需要另一个复制流运行到dr站点。这通常是异步进行的,这样站点间链接上的连接点就不会停止整个数据库。这是随NDB的地理复制选项提供的(在付费电信版本中),但我认为MySQL5.1及更高版本可以本机提供。

不幸的是,我对动物园管理员和胖子知之甚少。希望其他人能了解这些方面。