缩放MySQL解决方案（复制，群集）

Question

在我正在工作的初创公司 ，我们正在考虑为我们的数据库扩展解决方案。 事情变得有些令人困惑（至少对我来说）与MySQL，它有MySQL集群 ， 复制和MySQL集群复制 （来自版本5.1.6），这是MySQL集群的异步版本。 MySQL手册解释了其群集常见问题解答中的一些差异，但很难确定何时使用其中一个。

我很感激那些熟悉这些解决方案之间的差异以及优缺点的人的建议，以及您何时建议使用它们。

Answer 1

我一直在阅读有关可用选项的大量内容。 我也得到了高性能MySQL第二版，我强烈推荐。

这就是我成功拼凑的东西：

聚类

一般意义上的群集是将许多服务器上的负载分配给外部应用程序作为一个服务器。

MySQL NDB集群

MySQL NDB Cluster是一个分布式，内存中，无共享的存储引擎，具有同步复制和自动数据分区（请原谅我从高性能书中借用，但是他们非常好地说明了这一点）。 它可以是某些应用程序的高性能解决方案，但Web应用程序通常不能很好地工作。

主要问题是，除了非常简单的查询（只触摸一个表）之外，群集通常必须在多个节点上搜索数据，从而允许网络延迟进入并显着减慢查询的完成时间。 由于应用程序将群集视为一台计算机，因此无法告诉它从哪个节点获取数据。

此外，内存中的要求对许多大型数据库都不可行。

继续红杉

这是MySQL的另一个集群解决方案，它充当MySQL服务器之上的中间件。 它提供同步复制，负载平衡和故障转移。 它还确保请求始终从最新副本获取数据，自动选择具有最新数据的节点。

我已经阅读了一些有关它的好东西 ，总的来说听起来非常有前景。

联邦

联合类似于聚类，所以我也在这里拉扯它。 MySQL通过联合存储引擎提供联合。 与NDB集群解决方案类似，它仅适用于简单查询 - 但更糟糕的是复杂的集群（因为网络延迟要高得多）。

复制和负载平衡

MySQL具有内置的能力，可以在不同的服务器上创建数据库的复制。 这可用于许多事情 - 在服务器之间分配负载，热备份，创建测试服务器和故障转移。

复制的基本设置涉及一个主服务器主要处理写操作，一个或多个从服务器只处理读操作。 更高级的变体是主 - 主配置，它允许通过让多个服务器同时写入来扩展写入。

每种配置都有它的优点和缺点，但它们共享的一个问题是复制滞后 - 因为MySQL复制是异步的，并非所有节点都始终拥有最新的数据。 这要求应用程序了解复制并合并复制感知查询以按预期工作。 对于某些应用程序，这可能不是问题，但如果您总是需要最新鲜的数据，那么事情会变得有些复杂。

复制需要一些负载平衡来分割节点之间的负载。 这可以像对应用程序代码的一些修改或使用专用软件和硬件解决方案一样简单。

分片和分区

分片是用于扩展数据库解决方案的常用方法。 您将数据拆分为较小的分片，并将它们分布在不同的服务器节点上。 这要求应用程序了解对数据存储的修改以便有效地工作，因为它需要知道在哪里可以找到所需的信息。

有一些抽象框架可用于帮助处理数据分片，例如Hibernate Shards ，Hibernate ORM的扩展（不幸的是在Java中。我正在使用PHP）。 HiveDB是另一种支持分片重新平衡的解决方案。

其他

狮身人面像

Sphinx是一个全文搜索引擎，可用于测试搜索。 对于许多查询，它比MySQL快得多（特别是对于分组和排序），并且可以并行查询远程系统并聚合结果 - 这使得它在使用分片时非常有用。

通常，sphinx应与其他扩展解决方案一起使用，以获得更多可用的硬件和基础架构。 缺点是你需要应用程序代码才能知道sphinx明智地使用它。

摘要

扩展解决方案根据需要的应用程序的需求而有所不同。 对于我们和大多数Web应用程序，我认为复制（可能是多主机）是分配负载的负载均衡器的方法。 特定问题区域（大表）的分割也是能够水平扩展的必要条件。

我还要给Continuent Sequoia一个镜头，看看它是否能真正做到它所承诺的，因为它将涉及对应用程序代码的最少量更改。

Answer 2

免责声明：我没有使用MySQL Cluster，所以我只是从我所听到的。

MySQL Cluster是一种HA（高可用性）解决方案。 这很快，因为它全部都在内存中，但真正的卖点是可用性。 没有单一的失败点。 另一方面，通过复制，如果主机发生故障，您必须切换到副本，并且可能会有少量停机时间。 （尽管DRBD解决方案是另一种具有高可用性的替代方案）

群集要求整个数据库适合内存。 这意味着集群中的每台机器都需要有足够的内存来存储整个数据库。 因此，这对于非常大的数据库来说不是一个可行的解决方案（或者至少它是一个非常昂贵的解决方案）。

我认为除非HA非常重要（读：可能不是），否则它比它的价值更麻烦（和金钱）。 复制通常是更好的方法。

编辑：我忘了还提到Cluster不允许外键，范围扫描比其他引擎慢。 这是一个关于MySQL Cluster的已知限制的链接

Answer 3

关于维护drupal.org的人如何构建他们的数据库服务器，有一些很好的讨论：

• Dries Buytaert的博客
• WorkHabits博客

两者都来自2007年，因此Clustering支持现在可能更强大，但当时他们选择了复制。

Answer 4

做复制的好处是它很容易。 只需设置2个mysql框，在第二个框中更改serverID，然后使用change master to命令将第二个框指向第一个框。

这是相关的示例slave my.cnf配置

#
#       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）

设置从站可以连接的用户名和密码，然后运行change master to MASTER_HOST ='xxxx'; 将master更改为MASTER_PASSWORD =“xxxxx”;

等等。

最后，运行“启动奴隶”;

你的奴隶来了，开始复制。 甜蜜啊！

假设您从2个空服务器开始。 然后你可以将你的数据库转储到主服务器，当它加载到那里时，它也会加载到从服务器上。

您可以通过运行来检查从站状态：

显示奴隶状态\\ G.

玩得开心......太容易了......

Answer 5

在进行高可用性研究时，我遇到了许多解决方案，可能在我们的情况下，这是一个更密集的写入系统，我发现DRBD集群比NDB集群更好，因为它每秒提供更多的事务。

Mysql Replication可以为您提供备份机器，可以将其用作读取从站，也可以在灾难恢复时使用。

通过DRBD提供的不同交易管理模式，您可以通过网络降低设备级数据复制的性能。 对于在发生故障时不应丢失任何事务的可靠系统，使用C模式，否则转到B.

我试图列出我在设置DRBD群集期间所做的一些学习， 网址是http://www.techiegyan.com/?p=132

它在复制的专用连接上工作得很好，即在两台机器上保留单独的高速接口，仅用于drbd复制。 Heartbeat可以通过所有服务逐个控制集群，即IP地址，分区，drbd和mysql。

我还没有发现DRBD上的Master-Master配置。 当我获得成功的时候会更新。

谢谢。

Answer 6

在我看来，这里的困惑只会让我回到Mnesia。 使用碎片，声明和实用的方法处理索引，数据库副本的位置透明度等

在我们的设置中，我们运行MySQL Cluster和Mnesia。 我们的数据有点季节性。 所以发生的事情是在一段时间之后，我们解除了不再使用的数据的mnesia并将其扔进MYSQL集群。 这使我们的mnesia保持高效。 我们还有以主流语言（Python，Clojure等）实现的应用程序，它们直接使用来自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，谁知道，它可以回答你的一些分发或复制需求。

Answer 7

MySQL集群是一个奇怪的野兽，每次我们评估它时，它表现得非常糟糕或者不可靠。

设置起来非常复杂（至少需要三个节点，可能还需要更多节点）。 此外，没有规定让客户端进行故障转移，因此您必须自己执行此操作（或使用其他内容作为代理等）。

它非常聪明，因为它在主键上执行自动散列分区，允许您缩放写入，还因为它没有单点故障。

但我真的认为它更适合它所设计的特殊用途案例。 在大多数情况下，它无法在性能或功能中替换另一个数据库引擎（例如InnoDB）。

Answer 8

我没有使用它们，但是从文档中我会说如果最大的负载是从数据库读取的话，复制是首选的解决方案。

Answer 9

“内存中”限制阻止我们使用MySQL集群来获取近50Gb的数据，因此我们使用的是DRBD和Linux Heartbeat 。

它有点像两个（或更多）盒子之间的raid数组，它使数据库/日志/配置保持同步（但一次只能有一个服务器“活动”）。 故障转移是自动的，使用相同的IP地址，并且像mysql重启一样快，所以这对我们来说是一个很好的解决方案。