主从复制:主服务器将成为写入的瓶颈

主从复制:主服务器将成为写入的瓶颈

mysql 数据库大约有 2TB 的数据。

我正在运行主从从复制。使用数据库的应用程序只在两个从属服务器中的一个上执行读取(SELECT)查询,并在主服务器上执行写入(DELETE/INSERT/UPDATE)查询。应用程序的读取次数比写入次数多得多。

如果我们在读取(SELECT)查询时遇到问题,我们可以添加另一个从属数据库并告诉应用程序还有另一个从属数据库。因此它可以很好地扩展...

目前,由于写入,主服务器运行的磁盘 io 约为 40%。

所以我正在考虑将来如何扩展数据库。因为有一天主服务器会超载。

有什么解决办法吗?

也许是 mysql 集群?如果是这样,将数据库切换到 ndb 是否存在任何缺陷或限制?

提前致谢...:)

答案1

对于扩展 MySQL,没有一个万能的答案。一些一般建议:

  • 尽可能“对角线”扩展,即,只要您仍能在商用硬件上运行,就将所有内容保留在单个 MySQL 服务器上。这可能意味着 2 个四核 CPU、64+ GB RAM、8 个磁盘 RAID 10 或更高。“商用硬件”的上限每年都在加快。

  • 看看 Brad Fitzpatrick 关于扩展 LiveJournal 的演示文稿。就扩展 LAMP 而言,它们几乎是经典之作。本演示文稿的第 25 - 26 页您会看到最终将在 MySQL 复制中面临的问题:写入消耗了所有可用的磁盘 I/O。

  • 读 ”高性能 MySQL“这是一本非常好的书见过许多高负载 MySQL 安装的作者

  • 尽可能避免分片(将数据分散到多个 MySQL 服务器上)。当你开始分片时,你就放弃了关系数据库的大部分好处,并且减慢了开发速度。如果你必须进行分片,请考虑使用内置多服务器模型的 NoSQL 数据存储 - fx Riak、Cassandra、HBase、MongoDB。理想情况下,在 MySQL 和 NoSQL 之间进行“功能分区”,这样你就可以继续使用 MySQL 来处理不太热的数据,这些数据非常适合 RDBMS,而使用 NoSQL 引擎来处理不需要与 MySQL 数据连接的“热”数据。

也许是 mysql 集群?如果是这样,将数据库切换到 ndb 是否存在任何缺陷或限制?

在 ”Web 操作“Baron Schwartz 有一章关于 MySQL 的内容。他几乎直接说“不!”不要在网站环境中使用 MySQL Cluster/NDB。引用:“.. 它在连接和 GROUP BY 查询方面表现不佳,而 Web 应用程序需要这些。”。

答案2

MySQL 集群将通过将数据库拆分为分布在多台机器上的片段来提高写入的可扩展性。但这会大大降低从多个片段中提取数据的复杂查询速度。只有您才能确定这对应用程序性能的影响。

您可能希望手动对数据进行分片,而不是让集群引擎为您完成。这需要更多配置,但如果您了解应用程序如何使用数据库,您可能能够想出一个分片方案,让大多数查询仅访问一个分片。

答案3

请记住,MySQL 复制是单线程的,因此您的复制可能不受主服务器容量的限制,而是受到从服务器的限制,从服务器无法落后于主服务器并且会不同步。来自这篇文章

复制重放过程在副本服务器上以单个线程执行,因此无法跟上主服务器上哪怕是中等繁忙的写入负载(其中许多更新同时发生)。

答案4

您可以考虑对信息本身进行聚类。如果可能的话,将不同服务器之间的写入消耗表分开。

相关内容