在 startup我正在工作，我们现在正在考虑为我们的数据库扩展解决方案。 MySQL 的情况有些令人困惑(至少对我而言)，它有 MySQL cluster , replication和 MySQL cluster replication (从 5.1.6 版开始)，这是 MySQL 集群的异步版本。 MySQL 手册解释了其 cluster FAQ 中的一些差异。 ，但很难从中确定何时使用其中之一。
我很感激那些熟悉这些解决方案之间的差异和优缺点的人的任何建议，以及您建议何时使用每种解决方案。
最佳答案
我一直在阅读有关可用选项的大量内容。我还接触了 High Performance MySQL 2nd edition，我强烈推荐它。
这是我设法拼凑起来的:
聚类
一般意义上的集群是在许多服务器之间分配负载，这些服务器对于外部应用程序来说是一台服务器。
MySQL NDB 集群
MySQL NDB Cluster 是一个分布式的、内存中的、无共享的存储引擎，具有同步复制和自动数据分区(对不起，我从高性能书中借用了字面意思，但他们在那里写得很好)。对于某些应用程序来说，它可以是一种高性能的解决方案，但 Web 应用程序通常不能很好地在它上面工作。
主要问题是，除了非常简单的查询(仅接触一张表)之外，集群通常必须在多个节点上搜索数据，从而导致网络延迟蔓延并显着减慢查询的完成时间。由于应用程序将集群视为一台计算机，因此无法告诉它从哪个节点获取数据。
此外，内存要求对于许多大型数据库来说是不可行的。
连续红杉
这是 MySQL 的另一个集群解决方案，它充当 MySQL 服务器之上的中间件。它提供同步复制、负载平衡和故障转移。它还确保请求始终从最新副本中获取数据，自动选择具有最新数据的节点。
我读过一些 good things在它上面，总的来说听起来很有希望。
联邦
联邦类似于聚类，所以我也把它拉到了这里。 MySQL 通过联合存储引擎提供联合。与 NDB 集群解决方案类似，它仅适用于简单查询 - 但对于复杂查询的集群更糟糕(因为网络延迟要高得多)。
复制和负载平衡
MySQL 具有在不同服务器上创建数据库复制的内置能力。这可以用于许多事情 - 在服务器之间分配负载、热备份、创建测试服务器和故障转移。
复制的基本设置涉及一台主服务器处理主要写入和一个或多个从服务器只处理读取。更高级的变体是 master-master配置，它允许通过同时写入多个服务器来扩展写入。
每种配置都有其优点和缺点，但它们共有的一个问题是复制延迟 - 由于 MySQL 复制是异步的，并非所有节点始终拥有最新数据。这要求应用程序知道复制并合并复制感知查询以按预期工作。对于某些应用程序，这可能不是问题，但如果您总是需要最新的数据，事情就会变得有些复杂。
复制需要一些负载平衡来在节点之间分配负载。这可以像对应用程序代码进行一些修改一样简单，或者使用专用的软件和硬件解决方案。
分片和分区
分片是扩展数据库解决方案的常用方法。您将数据拆分为更小的碎片，并将它们分布在不同的服务器节点上。这需要应用程序知道对数据存储的修改才能有效地工作，因为它需要知道在哪里可以找到它需要的信息。
有一些抽象框架可以帮助处理数据分片，例如 Hibernate Shards ，Hibernate ORM 的扩展(不幸的是它是用 Java 编写的。我使用的是 PHP)。 HiveDB是另一个这样的解决方案，它也支持分片重新平衡。
其他
狮身人面像
Sphinx是一个全文搜索引擎，可用于远不止测试搜索。对于许多查询，它比 MySQL 快得多(尤其是在分组和排序方面)，并且可以并行查询远程系统并聚合结果 - 这使得它在与分片一起使用时非常有用。
一般来说，sphinx 应该与其他扩展解决方案一起使用，以获得更多可用的硬件和基础设施。缺点是您再次需要应用程序代码来了解 sphinx 才能明智地使用它。
总结
扩展解决方案因需要它的应用程序的需求而异。对于我们和大多数 Web 应用程序，我相信复制(可能是多主)是负载均衡器分配负载的方式。特定问题区域(大表)的分片也是能够水平扩展的必要条件。
我还将试一试Continent Sequoia，看看它是否真的能做到它所 promise 的，因为它将对应用程序代码进行最少的更改。
关于mysql - MySQL 的扩展解决方案(复制、集群)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/189903/