Rails 3 应用程序的 MySQL 集群 (NDB) 与 MySQL 复制 (InnoDB) : pros/cons?

Question

我们正在对我们当前的系统进行概述，试图弄清楚我们是否可以提高性能和可靠性。

目前，我们运行大量内部 Rails 应用程序和基于 Rails 的网站。有些已经是 Rails 3，有些正在转换为 Rails 3。它们都连接到以下 MySQL 设置。

mysql01(主服务器)=> mysql02(从属服务器) =>(每日数据库备份到驱动器，每天、每周、每月和每半年备份一次)。

所有写入都发生在 mysql01 上，并且大多数短读取也会转到它，一些“更消耗资源的读取”(例如需要 3-10 分钟运行并将数据转储到 csv 或备份中的每月/每周报告)转到 mysql02服务器。我们的网站每天有大约 3-5K 次访问，并且有大约 20-30 个内部用户，他们每天使用各种应用程序进行库存、订单处理等。因此，除了那些报告之外，这些服务器的负载并不特别重，无论如何都要运行奴隶。

所有服务器都在 Debian Lenny VM 上的 virtualized XEN 池中运行。

所以我们正在对系统进行审查，有人提出了切换到 MySQL Cluster (NDB) 设置的建议。我理论上知道它，但从未真正运行过它。那么，有经验的人是否知道我们当前设置的优缺点，以及涉及 Ruby/Rails 应用程序时的任何特别注意事项？

Answer 1

最近在文档中发布了对 InnoDB 和 MySQL Cluster (ndb) 的很好比较...值得一看:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

集群架构由应用程序访问的 MySQL 服务器池组成；这些 MySQL 服务器实际上并不存储集群数据，数据在下面的数据节点池中进行分区。每个 MySQL 服务器都可以访问所有数据节点中的数据。如果一个 MySQL 服务器更改了一条数据，那么它会立即对所有其他 MySQL 服务器可见。

显然，这种架构使得扩展数据库变得非常容易。与分片不同，应用程序不需要知道数据保存在哪里——它可以在所有可用的 MySQL 服务器之间进行负载平衡。与 MySQL 复制集群的横向扩展不同，您可以像扩展读取一样扩展写入。新的数据节点或 MySQL 服务器可以添加到现有的集群中，而不会丢失应用程序的服务。

MySQL Cluster 的无共享架构意味着它可以提供极高的可用性 (99.999%+)。每次更改数据时，都会同步复制到第二个数据节点；如果一个数据节点发生故障，则应用程序的读写请求由备份数据节点自动处理。

由于 MySQL 集群的分布式特性，一些操作可能会更慢(例如，具有数千个中间结果的 JOIN - 尽管有一个原型(prototype)解决方案可以解决这个问题)，但其他操作可能非常快并且可以很好地扩展(例如主键读取和写入)。您可以选择将表(甚至列)存储在内存或磁盘上，并通过选择内存选项(在后台将更改检查点到磁盘)事务可以非常快速进行。

MySQL 集群的设置可能比单个 MySQL 服务器更复杂，但它可以防止您必须在应用程序中实现分片或读/写拆分。秋千和环形交叉路口。

要从 MySQL 集群中获得最佳性能和可扩展性，您可能需要调整您的应用程序(请参阅集群性能调整白皮书:http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php)。如果您拥有该应用程序，这通常不是什么大问题，但如果您使用的是其他人的应用程序而您无法修改，那么这可能是个问题。

最后一点是，它不需要全部或全部 - 您可以选择将一些表存储在集群中，而另一些则使用其他存储引擎，这是一个针对每个表的选项。您还可以在 Cluster 和其他存储引擎之间进行复制(例如，将 Cluster 用于您的运行时数据库，然后复制到 InnoDB 以生成复杂的报告)。