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

Question

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

1. 当你复制你的数据库，当你集群？
2. 两者都可以同时执行吗？如果是的话，每个人的灵感是什么？

在此先感谢。

Answer 1

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

MySQL复制

第一种形式的复制，因为MySQL版本3.23其中MySQL已经支持。 MySQL中的复制目前作为使用逻辑日志传送后端的异步主从设置来实现。

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

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

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

由于您现在可以通过任何从站执行SELECT查询，所以可以实现可扩展性。但是写入语句通常并未得到改进，因为写入必须发生在每个复制成员上。

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

即使在较慢的连接和连接不连续的情况下，MySQL复制也可以很好地工作。它也可以用于不同的硬件和软件平台。可以使用包括MyISAM和InnoDB在内的大多数存储引擎进行复制。

MySQL簇

MySQL簇是不共享的，分布式的，使用同步复制，以保持高的可用性和性能分区系统。

MySQL集群通过称为NDB集群的独立存储引擎实现。该存储引擎将自动在多个数据节点上分区数据。数据的自动分区允许执行的查询的并行化。由于写入可以分布在多个节点上，所以读取和写入都可以按照这种方式进行缩放。

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

目前存在许多限制，必须牢记在决定MySQL Cluster是否适合您的情况的正确解决方案。

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

MySQL集群设计用于内部网络，因为延迟对响应时间非常重要。因此，无法跨越广泛的地理距离运行单个群集。另外，虽然MySQL Cluster将通过商品网络设置工作，但为了实现最高性能，可能会使用特殊群集互连。

Answer 2

1. 在Master-Salve配置中，写操作由主设备执行，由从设备读取。因此，所有的SQL请求都首先到达主设备，并且维持一个请求队列，只有在完成写操作后才能执行读操作。 Master-Salve配置中存在一个常见问题，我也看到，当队列变得太大而不能被主人维护时，这个架构就崩溃了，奴隶开始表现得像主人一样。 对于我在Cassandra工作的集群，请求到达节点（表）并且维护了一个提交哈希，它注意到与节点的差异并基于该提交哈希更新其他节点。所以这里所有的操作都不依赖于单个节点。

我们在写入数据不是很大的时候使用了Master-Salve，否则我们使用簇。 集群空间和Master-Salve在时间上很昂贵，所以你选择什么取决于你想要保存的东西。

1. 我们也可以同时使用两者，我已经在我目前的公司中完成了这项工作。 我们将大部分写入操作的表移动到Cassandra，并且我们编写了4个API来对Cassandra中的表执行CRUD操作。每当发出HTTP请求时，它首先会触发我们的Web服务器，并从运行在我们Web服务器上的代码中决定执行哪些操作（在CRUD中），然后调用特定的API来更改cassandra数据库。