在我正在工作的startup我们正在考虑为我们的数据库扩展解决方案。事情变得有些令人困惑（至少对我来说）与MySQL，它有MySQL cluster，replication和MySQL cluster replication（来自版本5.1.6），这是MySQL的异步版本簇。 MySQL手册解释了cluster FAQ中的一些差异，但很难确定何时使用其中一个。
我很感激那些熟悉这些解决方案之间差异以及优缺点的人的建议，以及您何时建议使用它们。
答案 0 :(得分：100)
我一直在阅读有关可用选项的大量内容。我也得到了高性能MySQL第二版，我强烈推荐。
这是我设法拼凑的：
一般意义上的群集是将许多服务器上的负载分配给外部应用程序作为一个服务器。
MySQL NDB Cluster是一个分布式，内存中，无共享的存储引擎，具有同步复制和自动数据分配功能（请原谅我从高性能书中借用，但他们在那里非常好）。它可以是某些应用程序的高性能解决方案，但Web应用程序通常不能很好地工作。
主要问题是，除了非常简单的查询（仅触及一个表）之外，群集通常必须在多个节点上搜索数据，从而允许网络延迟进入并显着减慢查询的完成时间。由于应用程序将群集视为一台计算机，因此无法告诉它从哪个节点获取数据。
此外，内存中的要求对许多大型数据库都不可行。
这是MySQL的另一个集群解决方案，它充当MySQL服务器之上的中间件。它提供同步复制，负载平衡和故障转移。它还确保请求始终从最新副本获取数据，自动选择具有最新数据的节点。
我已经阅读了一些good things，总的来说这听起来很有希望。
联盟类似于群集，所以我也在这里拉扯它。 MySQL通过联合存储引擎提供联合。与NDB集群解决方案类似，它仅适用于简单查询 - 但更糟糕的是复杂的集群（因为网络延迟要高得多）。
MySQL具有内置的能力，可以在不同的服务器上创建数据库的复制。这可用于许多事情 - 在服务器之间分配负载，热备份，创建测试服务器和故障转移。
复制的基本设置涉及一个主服务器主要处理写操作，一个或多个从服务器只处理读操作。更高级的变体是master-master配置，它允许通过让多个服务器同时写入来扩展写入。
每个配置都有它的优点和缺点，但它们共享的一个问题是复制滞后 - 因为MySQL复制是异步的，并非所有节点都始终拥有最新的数据。这要求应用程序了解复制并合并复制感知查询以按预期工作。对于某些应用程序，这可能不是问题，但如果您总是需要最新鲜的数据，那么事情会变得有些复杂。
复制需要一些负载平衡来分割节点之间的负载。这可以像对应用程序代码的一些修改或使用专用软件和硬件解决方案一样简单。
Sharding是扩展数据库解决方案的常用方法。您将数据拆分为较小的分片，并将它们分布在不同的服务器节点上。这要求应用程序了解对数据存储的修改以便有效工作，因为它需要知道在哪里可以找到所需的信息。
有一些抽象框架可用于帮助处理数据分片，例如Hibernate Shards，Hibernate ORM的扩展（不幸的是在Java中。我正在使用PHP）。 HiveDB是另一种支持分片重新平衡的解决方案。
Sphinx是一个全文搜索引擎，可用于远远超过测试搜索。对于许多查询，它比MySQL快得多（特别是对于分组和排序），并且可以并行查询远程系统并聚合结果 - 这使得它在使用分片时非常有用。
通常，sphinx应与其他扩展解决方案一起使用，以获得更多可用的硬件和基础架构。缺点是你需要应用程序代码才能明智地使用sphinx。
扩展解决方案根据需要的应用程序的需求而有所不同。对于我们和大多数Web应用程序，我认为复制（可能是多主机）是分配负载的负载均衡器的方法。特定问题区域（大表格）的分片也是能够水平扩展的必要条件。
我还要给“继续红杉”一下，看看它是否能真正做到它所承诺的，因为它将涉及对应用程序代码的最少量更改。
答案 1 :(得分：12)
免责声明：我没有使用过MySQL Cluster，所以我只是从我听过的内容开始。
MySQL Cluster是一种HA（高可用性）解决方案。这很快，因为它全部都在内存中，但真正的卖点是可用性。没有单一的失败点。另一方面，通过复制，如果主机发生故障，您必须切换到副本，并且可能会有少量停机时间。 （尽管DRBD解决方案是另一种具有高可用性的替代方案）
群集要求整个数据库适合内存。这意味着集群中的每台机器都需要有足够的内存来存储整个数据库。因此，这对于非常大的数据库来说不是一个可行的解决方案（或者至少它是一个非常昂贵的解决方案）。
我认为除非HA非常重要（读：可能不是），否则它的价值（和金钱）比它的价值更高。复制通常是更好的方法。
编辑：我忘了提到群集不允许外键，并且范围扫描比其他引擎慢。这是一个谈论Known Limitations of MySQL Cluster
的链接答案 2 :(得分：4)
关于维护drupal.org的人如何构建他们的数据库服务器，有一些很好的讨论：
两者都来自2007年，因此群集支持现在可能更强大，但当时他们选择了复制。
答案 3 :(得分：2)
做复制的好处是它很容易。只需设置2个mysql框，在第二个框中更改serverID，然后使用change master to命令将第二个框指向第一个框。
以下是相关示例slave my.cnf config
#
# Log names
#
log-bin=binlog
relay-log=relaylog
log-error=errors.log
#
# Log tuning
#
sync_binlog = 1
binlog_cache_size = 1M
#
# Replication rules (what are we interested in listening for...)
#
# In our replicants, we are interested in ANYTHING that isn't a permission table thing
#
replicate-ignore-db = mysql
replicate-wild-ignore-table=mysql.%
#
# Replication server ID
#
server-id = 2
因此，请确保每个slave都获得一个递增1的serverID（所以下一个slave是服务器3）
设置从属设备可以连接的用户名和密码， 然后跑 将master更改为MASTER_HOST ='x.x.x.x'; 将master更改为MASTER_PASSWORD =“xxxxx”;
等等。
最后，运行“start slave;”
Up来自你的奴隶并开始复制。甜蜜啊！
这假设您从2个空服务器开始。然后你可以将你的数据库转储到主服务器中，当它加载到那里时，它也会加载到从服务器上。
您可以通过运行以下方式检查从站状态：
显示奴隶状态\ G
玩得开心..太容易了......
答案 4 :(得分：1)
“内存中”限制阻止我们将MySQL群集用于近50Gb的数据，因此我们使用 DRBD加上Linux Heartbeat 。
它有点像两个（或更多）框之间的raid数组，它使数据库/日志/配置保持同步（但一次只能有一个服务器“活动”）。故障转移是自动的，使用相同的IP地址，并且在mysql重启时很快，因此对我们来说这是一个很好的解决方案。
答案 5 :(得分：1)
在进行高可用性研究时，我遇到了许多解决方案，可能在我们的情况下，这是一个更密集的写入系统，我发现DRBD集群比NDB集群更好，因为它每秒提供更多的事务。
Mysql Replication可以为您提供备份机器，可以将其用作读取从站，也可以在灾难恢复时使用。
通过DRBD提供的不同交易管理模式，您可以通过网络降低设备级数据复制的性能。对于在发生故障时不应丢失任何交易的可靠系统，使用C模式，否则转到B.
我试图列出我在http://www.techiegyan.com/?p=132设置DRBD群集期间所做的一些学习
它非常适用于复制的专用连接，即在两台机器上保留单独的高速接口，仅用于drbd复制。 Heartbeat可以很好地控制集群的所有服务，即IP地址，分区，drbd和mysql。
我还没有发现DRBD上的Master-Master配置。当我获得成功的时候会更新。
感谢。
答案 6 :(得分：1)
在我看来，这里的混乱只是让我回到了Mnesia。使用碎片，声明和实用的方法处理索引，数据库副本的位置透明度e.t.c
在我们的设置中，我们同时运行MySQL Cluster和Mnesia。我们的数据有点季节性。所以发生的事情是在一段时间之后，我们解除了不再使用的数据的mnesia并将其扔进MYSQL集群。这使我们的mnesia保持高效。我们还有以主流语言（Python，Clojure e.t.c）实现的应用程序，这些语言直接使用来自MySQL的数据。
简而言之，我们在MySQL Cluster上运行mnesia。 MySQL Cluster可以处理大型数据集，数据库可以增长到50GB以上。我们有mnesia为 Erlang / OTP 应用程序供电。 Java 和 PHP 使用JSON和XML作为交换格式，通过定制的 REST （最近 Thrift ）API从mnesia访问数据
如果需要，数据访问层可以抽象访问Mnesia中的数据和MySQL Cluster中的旧数据。 Mnesia在这里主要是为Erlang / OTP应用程序提供支持。一旦它被数据占用，我们就把它扔进了MYSQL Cluster。数据访问层可以代表所有应用程序以抽象的API访问mnesia和MySQL中的数据。
我在这里可以说的是，Mnesia一直是我们的最佳选择。这些表是高度分散和索引的，查询执行得非常好，数据库在两个位置上复制，通过隧道连接。
早些时候，我们担心由于表格大小限制，mnesia可能无法处理尽可能多的记录。但我们发现这种说法是错误的。通过良好的调整（碎片化），我们的mnesia数据库每年平均拥有大约2.5亿条记录。
我们从Erlang复杂的数据结构中获益，并且Mnesia可以不加改变地将其吞没。 Erlang / OTP应用程序在遗留语言中的所有其他应用程序中效率最高，而我们的系统计划将其全部迁移到Erlang / OTP技术。从Erlang我们无可非议地从MySQL Cluster访问数据并在其服务器上执行查询非常奇妙。实际上，我们已经推断出它的Erlang / OTP可以完全使用MySQL服务器资源，因为它的（Erlang）大规模并发。
Mnesia非常适合我们.Mnesia因其惊人的表现完全改变了我们对数据库的看法。我们的Solaris服务器CPU内核在高峰时段的使用率平均保持在48％左右。
我建议你查看mnesia，谁知道，它可以回答你的一些分发或复制需求。
答案 7 :(得分：0)
我没有使用它们，但是从文档中我会说如果最大负载是从数据库读取的话，复制是首选解决方案。
答案 8 :(得分：0)
MySQL群集是一个奇怪的野兽，每当我们评估它时，它表现得非常糟糕或者不可靠。
设置非常复杂（至少需要三个节点，可能更多）。此外，没有规定让客户端进行故障转移，因此您必须自己执行此操作（或使用其他内容作为代理等）。
它非常聪明，因为它在主键上执行自动散列分区，允许您缩放写入，还因为它没有单点故障。
但我真的认为它更适合它所设计的特殊用途案例。在大多数情况下，它无法在性能或功能中替换另一个数据库引擎（例如InnoDB）。