mysql动物信息管理系统_动物园管理员/胖子-vs-mysql ndb

带有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及更高版本可以本机提供。

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