什么时候更喜欢主从，什么时候集群？答案

【问题标题】：When to prefer master-slave and when to cluster?什么时候更喜欢主从，什么时候集群？
【发布时间】：2016-06-26 09:16:11
【问题描述】：

我知道有很多关于数据库复制的文章。相信我，我花了一些时间阅读这些文章，包括 this SO 一篇，其中解释了复制的优缺点。 This SO 文章深入探讨了复制和集群，但没有回答我的这些简单问题：

提前致谢。

【问题讨论】：

【解决方案1】：

MySQL 目前支持两种不同的解决方案来创建高可用性环境和实现多服务器可扩展性。

MySQL 复制

第一种形式是复制，MySQL 从 MySQL 3.23 版本开始就支持这种形式。 MySQL 中的复制目前是作为异步主从设置实现的，它使用逻辑日志传送后端。

主从设置意味着指定一台服务器作为主服务器。然后需要接收所有的写查询。然后主服务器执行并记录查询，然后将其发送到从服务器执行，从而在所有复制成员中保持相同的数据。

复制是异步的，这意味着当主服务器执行更改时，从服务器不能保证有数据。通常，复制将尽可能实时。但是，无法保证更改传播到从站所需的时间。

可以出于多种原因使用复制。一些更常见的原因包括可扩展性、服务器故障转移和备份解决方案。

可以实现可扩展性，因为您现在可以跨任何从属设备执行 SELECT 查询。但是，由于必须在每个复制成员上进行写入，因此写入语句通常不会得到改进。

使用外部监控实用程序可以相当容易地实现故障转移，该实用程序使用心跳或类似机制来检测主服务器的故障。 MySQL 目前不进行自动故障转移，因为逻辑通常非常依赖于应用程序。请记住，由于复制是异步的，因此可能并非所有在主服务器上所做的更改都会传播到从服务器。

即使在较慢的连接和不连续的连接上，MySQL 复制也能很好地工作。它还能够跨不同的硬件和软件平台使用。大多数存储引擎都可以使用复制，包括 MyISAM 和 InnoDB。

MySQL 集群

MySQL 集群是一个无共享的分布式分区系统，它使用同步复制来保持高可用性和性能。

MySQL 集群是通过称为 NDB 集群的单独存储引擎实现的。该存储引擎将自动跨多个数据节点对数据进行分区。数据的自动分区允许执行的查询并行化。读取和写入都可以通过这种方式进行扩展，因为写入可以分布在许多节点上。

在内部，MySQL Cluster 还使用同步复制来消除系统中的任何单点故障。由于始终保证两个或多个节点具有数据片段，因此至少一个节点可以失败而不会影响正在运行的事务。故障检测是自动处理的，死节点被删除，对应用程序透明。节点重启后，它会自动重新集成到集群中，并尽快开始处理请求。

目前存在许多限制，在确定 MySQL Cluster 是否适合您的情况时，必须牢记这些限制。

目前存储在 MySQL Cluster 中的所有数据和索引都存储在整个集群的主内存中。这确实会根据集群中使用的系统限制数据库的大小。

MySQL 集群设计用于内部网络，因为延迟对于响应时间非常重要。

因此，不可能在很远的地理距离上运行单个集群。此外，虽然 MySQL 集群将在商品网络设置上工作，但为了获得可能的最高性能，可以使用特殊的集群互连。

【讨论】：

【解决方案2】：

在主从配置中，写操作由主设备执行，读取由从设备执行。所以所有的 SQL 请求首先到达 Master 并维护一个请求队列，只有在写入完成后才会执行读取操作。我还目睹了 Master-Salve 配置中的一个常见问题是，当队列变得太大而无法由 master 维护时，这个架构就会崩溃，slave 开始表现得像 master。对于集群，我在 Cassandra 上工作过，其中请求到达节点（表）并维护提交哈希，该哈希注意到对节点所做的差异并根据该提交哈希更新其他节点。所以这里所有的操作都不依赖于单个节点。

当写入数据的大小和数量不大时，我们使用 Master-Salve，否则我们使用集群。集群在空间上很昂贵，而 Master-Salve 在时间上很昂贵，因此您对选择什么的决定取决于您要保存什么。

我们也可以同时使用这两种方法，我在我现在的公司已经这样做了。我们将写入操作最多的表移至 Cassandra，并编写了 4 个 API 来对 Cassandra 中的表执行 CRUD 操作。每当 HTTP 请求到达时，它首先会到达我们的 Web 服务器，并且从我们的 Web 服务器上运行的代码中，我们可以决定必须执行哪个操作（在 CRUD 中），然后我们调用该特定 API 来更改 cassandra 数据库。

【讨论】：