MySQL的扩展解决方案（复制，群集）

Question 1

在启动时，我正在为我们的数据库考虑扩展解决方案。MySQL至少使我感到困惑（至少对我而言），MySQL具有MySQL群集，复制和MySQL群集复制（来自5.1.6版），它是MySQL群集的异步版本。MySQL手册解释了其集群FAQ中的某些差异，但是很难确定何时使用它们中的一种。

我将不胜感激那些熟悉这些解决方案之间的差异以及优点和缺点以及何时建议使用每种解决方案的人的任何建议。

Question 2

我一直在做很多关于可用选项的阅读。我还亲自推荐了高性能MySQL第二版。

这是我设法拼凑而成的：

聚类

一般而言，群集是将负载分布在许多服务器上，这些服务器在外部应用程序中似乎是一台服务器。

MySQL NDB集群

MySQL NDB Cluster是一个具有同步复制和自动数据分区功能的分布式，无内存，无共享的存储引擎（对不起，我从高性能书上借来的字面意思是，但是它们放在那儿非常好）。对于某些应用程序来说，它可能是一种高性能的解决方案，但是Web应用程序通常无法在其上很好地工作。

主要问题在于，除了非常简单的查询（仅涉及一个表）之外，群集通常还必须在多个节点上搜索数据，从而使网络等待时间增加，并显着减慢查询的完成时间。由于该应用程序将群集视为一台计算机，因此无法告诉它从哪个节点获取数据。

此外，内存需求对于许多大型数据库而言并不可行。

连续红杉

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

我读了一些不错的东西，总的来说，这听起来很有希望。

联邦

联合类似于集群，因此我也在这里进行了介绍。MySQL通过联合存储引擎提供联合。与NDB群集解决方案类似，它仅适用于简单查询-但对于复杂查询，群集甚至更糟（因为网络延迟要高得多）。

复制和负载平衡

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

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

每种配置都有其优缺点，但是它们共同面临的一个问题是复制滞后-由于MySQL复制是异步的，因此并非所有节点始终都具有最新数据。这要求应用程序了解复制，并结合复制感知查询才能按预期工作。对于某些应用程序来说，这可能不是问题，但是如果您始终需要最新的数据，事情就会变得有些复杂。

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

分片和分割

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

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

其他

狮身人面像

Sphinx是全文搜索引擎，其功能远不止测试搜索。对于许多查询而言，它比MySQL快得多（特别是对于分组和排序），并且可以并行查询远程系统并汇总结果-这使其在分片中非常有用。

通常，狮身人面像应与其他扩展解决方案一起使用，以获取更多可用的硬件和基础架构。不利的一面是，您再次需要应用程序代码来了解sphinx，以便明智地使用它。

概要

伸缩解决方案根据需要它的应用程序的需求而有所不同。对于我们和大多数Web应用程序，我相信复制（可能是多主服务器）是负载平衡器分配负载的一种方式。为了能够水平扩展，还必须对特定问题区域（巨大的表）进行分片。

我还将对Continentant Sequoia进行一下测试，看看它是否能够真正实现它所承诺的目标，因为它将对应用程序代码进行的更改最少。

Question 3

免责声明：我没有使用过MySQL Cluster，因此仅从我所听到的内容出发。

MySQL Cluster是一种HA（高可用性）解决方案。它很快，因为它全部存储在内存中，但是真正的卖点是可用性。没有单点故障。另一方面，使用复制时，如果主服务器宕机，则必须实际切换到副本，并且可能会有少量的宕机时间。（尽管DRBD解决方案是另一种具有高可用性的解决方案）

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

我认为，除非医管局非常重要（阅读：可能不行），否则麻烦（和金钱）要比其值得。复制通常是更好的方法。

编辑：我也忘了提到集群不允许外键，并且范围扫描比其他引擎上慢。这是一个讨论MySQL群集已知限制的链接

Question 4

关于维护drupal.org的人们如何构造其数据库服务器，存在一些很好的讨论：

两者都是从2007年开始的，因此群集支持现在可能会更强，但是当时他们选择了复制。

Question 5

复制很酷的事情是它很容易。只需设置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

因此，请确保每个从属服务器获取的serverID均增加1（因此下一个从属服务器为3）

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

等等。

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

奴隶起来，开始复制。呵呵！

假定您从2个空服务器开始。然后，您可以将数据库转储到主服务器中，并且在将其加载到主服务器时，它还将在从服务器上加载。

您可以通过运行以下命令检查从站状态：

显示从站状态\ G

玩的开心..太简单了...

Question 6

在进行高可用性研究时，我遇到了许多解决方案，并且在我们的案例中可能是写密集型系统，我发现DRBD集群比NDB集群更好，因为它每秒提供更多的事务数。

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

通过DRBD提供的事务管理的不同模式，您可以降低由网络上设备级数据复制带来的性能下降。对于可靠的系统，在发生故障的情况下不会丢失任何事务，请使用C模式，否则请选择B。

我尝试在http://www.techiegyan.com/?p=132上列出设置DRBD群集期间所做的一些学习。

它在专用于复制的连接上非常有效，即在两台机器上仅为drbd复制保留单独的高速接口。Heartbeat可以通过所有服务（IP地址，分区，drbd和mysql）一对一地很好地控制群集。

我还没有发现DRBD上的Master-Master配置。当我在其中获得成功时，将进行更新。

谢谢。

Question 7

在我看来，这里的混乱使我回到了Mnesia。具有碎片化，声明式和务实的索引处理方式，数据库副本的位置透明性等

在我们的设置中，我们同时运行MySQL Cluster和Mnesia。我们的数据有点季节性。因此，发生的事情是在一段时间之后，我们消除了不再使用的数据的记忆，并将其扔到MYSQL群集中。这样可以保持我们的记忆力。另外，我们还有使用主流语言（Python，Clojure等）实现的应用程序，这些应用程序直接使用来自MySQL的数据。

简而言之，我们在MySQL Cluster之上运行mnesia。MySQL Cluster可以处理大型数据集，而数据库则可以增加到50GB以上。我们为Erlang / OTP应用程序提供了记忆力。Java和PHP使用JSON和XML作为交换格式，通过定制的REST（最近为Thrift）API通过mnesia访问数据。

如果需要，数据访问层已经抽象了对Mnesia中的数据和MySQL Cluster中的旧数据的访问。Mnesia实质上是为Erlang / OTP应用程序提供动力的工具，一旦它陷入数据中，我们会将其放入MYSQL Cluster中。数据访问层可以代表所有应用程序以抽象API访问mnesia和MySQL中的数据。

我在这里可以说的是，对我们来说，Mnesia是最好的选择。这些表高度分散且建立了索引，查询执行得很好，并且数据库在两个通过隧道连接的位置之间进行复制。

早些时候，由于表大小的限制，我们担心失忆症可能无法处理尽可能多的记录。但是我们发现这个说法是错误的。通过良好的调整（碎片化），我们的失忆数据库确实每年平均保存约2.5亿条记录。

我们受益于Erlang复杂的数据结构以及Mnesia可以不加改变地吞并它的事实。Erlang / OTP应用程序是所有其他传统语言应用程序中效率最高的，而我们的系统正计划将其全部迁移到Erlang / OTP技术。从Erlang，我们似乎毫不费力地访问了MySQL Cluster的数据，并非常好地对其服务器执行查询。事实上，我们推断出，由于（Erlang）大量并发，其Erlang / OTP可以充分利用MySQL服务器资源。

Mnesia为我们提供了很好的服务。Mnesia的出色性能完全改变了我们查看数据库的方式。我们的Solaris服务器CPU核心在繁忙时间繁忙，平均使用率约为48％。

我建议您检查一下失忆症，谁知道呢，它可能会满足您的发行或复制需求。

Question 8

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

Question 9

“内存中”限制使我们无法对近50Gb的数据使用MySQL集群，因此我们使用DRBD和linux Heartbeat。

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

Question 10

MySQL集群是一个奇怪的野兽，每当我们评估它时，它要么表现很差，要么变得不可靠。

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

它非常聪明，因为它在主键上执行了自动哈希分区，这使您可以扩展写入，还因为它没有单点故障。

但是我真的认为它更适合于其特殊用途的案例。在大多数情况下，它在性能或功能上都无法替代其他数据库引擎（例如InnoDB）。