我正在研究平衡 MySQL 基础架构负载的方法，但似乎找不到适合我的答案……:)
因此，我有一个大型服务器，它可以处理所有事情。许多数据库、许多读取、许多写入等。它处理得很好，但它是一个单点故障。
我们已经设置了几个从属服务器来将读取操作重定向到它们，但是面临两个问题：重建所有程序以分离读取和写入需要花费很大的精力；有时从属服务器会落后，从而导致应用程序中出现非常有趣的伪影。
从属服务器落后的问题：因为许多数据库是混合的 - 数据挖掘方面既有耗时 10-20 分钟的繁重查询，也有不耗时原子查询。但是从属服务器每次运行一个查询，因此所有原子查询都必须等到繁重查询完成。
为了解决这两个问题，我正在考虑类似代理的东西，它会考虑这一点：
- 自动分割读/写
- 作为单一入口点，然后将请求重定向到需要数据库的适当服务器（例如，在后端分离 db1 和 db2，但对应用程序透明）
- 注意从服务器的延迟，当从服务器延迟发生时，将读取的数据发送到主服务器（如果可以按数据库执行此操作，则是理想的；但服务器范围的操作也非常棒）
- 在所有符合条件的从属服务器之间进行负载平衡读取（通过简单循环或通过监控 LA）
还有一个问题仍然存在，但我想考虑一下 - 那就是故障转移。如果主服务器发生故障 - 如果从服务器能够承担主服务器的责任就好了，而当主服务器恢复时 - 它将成为从服务器。
欢迎任何有关 RTFM 或有关该主题的案例研究的指示 =)
编辑：谷歌搜索了更多内容，除了 Tungsten enterprise，还找到了 dbShards 和 Schooner。深入研究后，有人有使用这些解决方案的经验吗？有什么反馈吗？
答案1
查看钨业
MySQL-MMM 不是推荐的解决方案。请参阅：http://www.xaprb.com/blog/2011/05/04/whats-wrong-with-mmm/甚至其中一位原作者在评论中也表示同意。
干杯
编辑：哎呀，第二个链接与第一个相同。已更正
答案2
两台服务器充当应用数据库，另一台（或两台？）服务器充当数据挖掘层，效果如何？您的两个“应用”数据库不应落后太多，因为它们不处理任何繁重的查询。您还可以设置mysql-mmm来处理故障转移。然后，您可以将应用程序指向您在负载均衡器中设置的 Mysql VIP。此 VIP 中有两个 MMM IP。但 MMM 可能会说“嘿，盒子 2 落后太多，我会将该 IP 移动到盒子 1，以便它赶上来。”
然后，您将拥有两层数据库来处理两种不同的查询类型。这些机器上的缓存将针对其查询类型进行优化（理论上）。
还可以考虑使用 Fusion-IO 卡或 Virident TachIOn。这样也许可以解决问题，而无需添加大量硬件。
答案3
为了解决复制延迟问题，我们在从服务器上实施了 SSD 作为主存储。尽管从服务器上的复制是单线程操作，但更快的写入时间有助于从服务器数据库跟上速度。