MySQL的扩展解决方案(复制、集群)

我已经做了很多关于可用选项的阅读。我还拿到了高性能MySQL第二版,我强烈推荐。

这就是我设法拼凑起来的:

聚类

一般意义上的集群是将负载分布在许多服务器上,这些服务器在外部应用程序看来就像一个服务器。

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快得多(特别是对于分组和排序),并且可以并行查询远程系统并聚合结果,这使得它在分片中非常有用。

一般来说,斯芬克斯应该与其他扩展解决方案一起使用,以获得更多可用的硬件和基础设施。缺点是,你需要应用程序代码了解斯芬克斯,才能明智地使用它。

总结

扩展解决方案因需要它的应用程序的需求而异。对我们和大多数web应用程序来说,我认为复制(可能是多主机)是负载均衡器分配负载的方法。为了能够水平扩展,特定问题区域(巨大的表格)的分割也是必须的。

我还将给Continent Sequoia一个机会,看看它是否真的能做到它所承诺的,因为它对应用程序代码的更改最少。

免责声明:我没有使用过MySQL Cluster,所以我只是根据我所听到的。

MySQL集群是一种高可用性(HA)解决方案。它很快,因为它都在内存中,但它的真正卖点是可用性。没有单点故障。另一方面,对于复制,如果主设备发生故障,您必须实际切换到副本,并且可能会有少量的停机时间。(尽管DRBD解决方案是另一种具有高可用性的替代方案)

集群要求您的整个数据库都能容纳在内存中。这意味着集群中的每台机器都需要有足够的内存来存储整个数据库。因此,对于非常大的数据库来说,这不是一个可行的解决方案(或者至少是一个非常昂贵的解决方案)。

我认为,除非HA非常重要(阅读:可能不是),否则它比它的价值更麻烦(和金钱)。复制往往是更好的选择。

编辑: 我还忘了提到Cluster不允许使用外键,而且距离扫描比其他引擎慢。以下是一个关于 Known Limitations of MySQL Cluster

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

• Dries Buytaert's blog
• WorkHabits blog

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

做复制的酷之处在于它很容易。只需设置2个mysql框,更改第二个框上的服务器ID,然后使用change master命令将第二个盒指向第一个。

这是相关的示例从属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

因此,请确保每个从属服务器都获得一个递增1的服务器ID(因此下一个从属服务器是服务器3)

设置从属设备可以连接的用户名和密码, 然后运行 将master更改为master_HOST=“x.x.x.x”; 将master更改为master_PASSWORD=“xxxxx”;

等等。

最后,运行“启动奴隶”

你的奴隶上来了,开始复制。好甜啊!

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

您可以通过运行以下命令来检查从属状态:

显示从属状态\G

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

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

Mysql复制可以为您提供一个备份机器,它既可以用作读从机,也可以在灾难恢复时使用。

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

我试图列出我在建立DRBD集群时学到的一些东西 http://www.techiegyan.com/?p=132

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

我还没有发现DRBD上的Master配置。当我在这方面取得成功时,我会及时更新。

谢谢。

在我看来,这里的混乱只会让我回到Mnesia。具有碎片化、声明性和实用的索引处理方式,数据库副本的位置透明性等

在我们的设置中,我们运行MySQL Cluster和Mnesia。我们的数据有点季节性。所以,一段时间后,我们会解除对不再使用的数据的记忆,并将其放入MYSQL集群。这使我们的记忆保持高效。此外,我们还使用主流语言(Python、Clojure e.t.c)实现了直接使用MySQL数据的应用程序。

简而言之,我们在MySQL集群之上运行mnesia。MySQL集群可以处理大型数据集,数据库可以增长到50GB以上。我们有mnesia为 Erlang/OTP 应用。 Java 和 PHP程序 通过定制从mnesia访问数据 休息 (最近 节俭 )使用JSON和XML作为交换格式的API。

数据访问层对Mnesia中的数据和MySQL集群中的旧数据进行了抽象访问(如果需要)。Mnesia在这里主要是为Erlang/OTP应用程序提供动力。一旦它被数据填满,我们就把它扔进MYSQL集群。数据访问层可以代表所有应用程序在抽象的API中访问mnesia和MySQL中的数据。

我可以在这里说的是,Mnesia对我们来说是最好的选择。这些表是高度碎片化和索引的,查询执行得很好,数据库在两个位置复制,通过隧道连接。

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

我们受益于Erlang复杂的数据结构,以及Mnesia可以不加改变地将其吞下的事实。Erlang/OTP应用程序是所有其他遗留语言应用程序中效率最高的,我们计划通过我们的系统将其全部迁移到Erlang/OPT技术。从Erlang中,我们可以无缝地访问MySQL集群的数据,并在其服务器上非常出色地执行查询。事实上,我们推断出,由于其(Erlang)的大规模并发性,其Erlang/OTP可以充分利用MySQL服务器资源。

Mnesia为我们工作得很好。Mnesia的惊人性能彻底改变了我们看待数据库的方式。我们的Solaris服务器CPU内核在高峰时段保持繁忙,平均使用率约为48%。

我建议您查看mnesia,谁知道呢,它可能会满足您的许多分发或复制需求。

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

“内存”限制使我们无法使用MySQL集群来处理近50Gb的数据,因此我们正在使用 DRBD加linux心跳 .

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

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

设置起来非常复杂(您至少需要三个节点,可能更多)。此外,没有关于让客户端进行故障转移的规定,所以你必须自己做(或者使用其他东西作为代理等)。

它非常聪明,因为它在主键上进行自动哈希分区,允许您扩展写入,而且它没有单点故障。

但我真的认为它更适合它设计的非常特殊的情况。在大多数情况下,它不能在性能或功能上取代另一个数据库引擎(例如InnoDB)。