负载平衡MySql服务器？

在一个非常简单的幼儿园级别上，他是对的 – 你不能只在一堆MySQL服务器前面粘贴一个4层负载平衡器，并期望它能够工作，就像你在一堆Web服务器上工作一样。

但是，有一些技术可以将负载分散到许多MySQL服务器中，比如分片和多主复制，从这个意义上讲，你所说的那个人是错误的。

至于“这些停机时间”，我不确定你的意思 – 负载均衡不是（必然）高可用性，如果你想正确使用这些技术，了解两者之间的关系和差异是很重要的。

一般来说，您可以通过向用户提供歉意的抱歉页面来处理存储层的停机时间，然后通过随时待命的系统pipe理员尖叫寻求帮助。

检查MySQL代理和读/写分裂。 基本上写入去主，你可以负载平衡从主和一个或多个奴隶读取。

查看： http : //agiletesting.blogspot.com/2009/04/mysql-load-balancing-and-read-write.html

干杯

那么你可以负载平衡任何types的服务器，你可能不会得到你想要的结果。

例如，如果数据库应用程序是一个纯粹的只读查询系统，那么为什么不呢，你可以从LB中得到很大的好处，但是你遇到的问题是写入，因为它们不能很好地/恰当地集群 – 它只是被devise对于这样的事情，除非你认真地从头开始devise你的系统，以这种方式工作。

所以我回到你的问题是你想如何工作？

与MS SQL的企业版本不同，MySQL没有传统意义上的内置负载平衡规定。 这可能是你的朋友使用第4层和类似的LBing解决scheme，从这个意义上讲，这是真的。

但是， MySQL分片可以提供高负载下的高可用性，我认为这是您正在寻找的。

可以完成对MySQL数据库环境的负载平衡，但是不能通过在应用程序服务器和数据库服务器之间放置LB设备来完成。 这是完全错误的地方。

在MySQL连接级别做这件事的问题是知识之一。 SQL是针对单个存储“数据库”的本质。 原始SQL没有足够的关于不同types数据的关系的信息，也没有关于数据所需的有效性。 相反，它必须猜测为什么未知的数据正在被访问，看它是如何被访问的。 这就是MySQL Proxy的工作原理。 而且它仍然需要额外configuration数据库实例本身。

真正的集群感知负载均衡要求数据库实例能够相互交stream，以便在数据库引擎和存储级别上对访问的序列化和比较负载的知识进行分类。 我还没有研究过它们，但据我所知，这是DB2和Oracle在集群设置中所做的事情。 MySQL不 – 它没有devise的体系结构。

所以你必须在SQL发送之前在应用程序中进行更高的负载平衡。 这是一个好得多的地方，因为这就是关于数据相关性的所有知识的地方。 这是代码可以知道它需要查看该表中的一个数据库，并在这里查看另一个表的数据库之一。 它可以知道它可以读取这个表的数据库，因为它是一个复制品，但是它必须写在那里。 它甚至可以决定数据在不再有用之前可以存在多久，从而允许智能caching策略。 这也意味着许多数据库实例。 这就是LiveJournal在过去几年中所发现的。

这种方法的缺点是你失去了什么。 没有（或很less）存储过程，约束是困难的，跨不同数据库的报告是困难的。 它使你复杂的SQL引擎简单的存储。 但他们擅长这一点！ 这也意味着您的DBA必须成为数据库程序员，或者您的数据库程序员必须成为DBA。 到过那里。 做到了。 我在对象层做了这种可伸缩性。 它真的很好。 这是非常非常规的。