数据库拓扑设计混乱

Question

背景

我运行（阅读：继承）一个设置非常类似于共享主机提供商的网络。基础设施上运行着 300-400 个站点。多年来，数据库拓扑变得非常分散，因为它是从 webserver->database 的 1 对 1 关系。

问题

• 10 个应用程序中有 9 个是由实施了 wordpress/joomla/drupal 等的第三方设计公司设计的。
• 数据库有点随意地分布在 6 个数据库服务器上。它们不会在任何地方复制。
• 应用程序没有单独的数据库句柄的概念来将 INSERT 分离到主服务器和 SELECT 到从服务器。
• 使用单主内置 mysql 复制会产生巨大的瓶颈。插入量会很快降低主数据库。

问题

我的问题是，如何使我的数据库拓扑尽可能平坦，同时为未来的可扩展性留出空间？

将来我想在我的网络中添加更多地理位置，这些地理位置可以跨“后网”复制相同的数据库。

过去我研究过多主复制，但发现了很多与 auto_increment 列冲突等问题有关的问题。

我对企业解决方案持开放态度。类似于用于 Oracle 复制的 Shareplex 产品。

无论解决方案是什么，期望应用程序更改以适应这种新设计是不合理的。因此，像 auto_increment 列之类的东西需要保持不变并在整个集群中形成凝胶。

目标

我的目标是为每个集群都有一个内部负载平衡的主机名，我可以将所有应用程序指向该主机名。我

这也为我提供了我目前没有的容错能力。目前，无法从轮换中删除数据库。

Cassandra 和 Hadoop 等应用程序看起来与我想要实现的目标惊人地相似，但 NoSQL 不是这些应用程序的选择。

非常感谢任何提示/指针/教程/文档/产品推荐。谢谢你。

Answer 1

过去我研究过多主复制，但发现了很多与 auto_increment 列冲突等问题有关的问题。

我们在工作中在生产中使用多主机。不久前，auto_increment_increment and auto_increment_offset 解决了 auto-inc 难题，它允许每个服务器拥有自己的增量 ID 模式。只要应用程序的设计不是盲目地假设所有 ID 都是连续的，它应该可以正常工作。

multi-master 的真正问题是 MySQL 仍然偶尔会损坏二进制日志。这主要是不可靠连接的问题，因此如果所有实例都是本地的，则不会有问题。

多主机的另一个问题是它只是 不随写入扩展，正如您已经体验或假设的那样，在您的答案中给出一个观点。 所有在一个主服务器上的写入必须被其他人复制。即使您正确地分散了读取负载，您最终也会遇到 I/O 瓶颈，只能通过更多硬件、应用程序重新设计或分片（阅读：应用程序重新设计）来解决。现在 MySQL 提供了基于行的复制，情况稍微好一些。

如果您需要地理多样性，多主机可以工作。

还可以查看DRBD 一个磁盘块级复制系统，该系统现已内置于现代 Linux 内核中。以前有人用它来复制 MySQL 和 PostgreSQL，尽管我没有任何个人经验。

我无法从您的问题中看出您是在寻找高可用性，还是只是在寻找（手动或自动）故障转移。如果您只是需要故障转移并且可能会有一些停机时间，那么传统的主/从复制可能对您来说就足够了。麻烦的是把一个成为主人的奴隶变回奴隶。