回顾 - MySQL 5.1 与 5.5

回顾 - MySQL 5.1 与 5.5

几个月前,当 MySql 5.5 还在测试版时,这个问题就被问过了。现在它已经发布,并且有一些维护更新,大家觉得怎么样?

答案1

问题#1)半同步复制

具有多个从属的主服务器并不是那么好,因为只有第一个从属服务器会快速复制,并且所有后续从属服务器有时会根据查询运行的时间切换到异步模式。就第一个从属服务器而言,这是设计使然。我猜无法保证后续从属服务器及时运行。

另一方面,在我看来,简单的主从、循环复制和多主复制的工作速度非常快。

问题 #2) 多个 InnoDB 缓冲池

我有一个客户端,其中有 3 个数据库服务器,配置如下:
双 HexaCore(12 个 CPU)
192GB RAM
2 TB SAS RAID10

客户端有 480GB 的数据分布在 780 个数据库中。
三个数据库服务器之间正在运行循环复制。

毫无疑问,我为 InnoDB 激活的最强大的功能之一如下:

innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_io_capacity=65536
innodb_buffer_pool_instances=1
(默认) innodb_bufer_pool_size=162G

对于该客户来说,MySQL 5.5 就像梦一样。所有客户的客户数据实际上都缓存在内存中。由于 InnoDB 活动繁重,所有 12 个 CPU 都完全投入使用。一切都快得惊人。缓冲池的 InnoDB 脏页非常少,而且换页非常快。

我确实尝试过这样设置缓冲池(160GB)

innodb_buffer_pool_instances=64(最大值)
innodb_buffer_pool_size=2560M(2.5 GB)

这导致了大量线程锁定。我怀疑这是由于相关数据缓存在不同的缓冲池中。尝试访问这些数据段会导致缓冲池之间出现某种互斥。我工作中的一位同事(他是 Oracle 认证大师)告诉我,Oracle 有一个类似的基础架构可供使用,线程锁定也是一个问题,所以他们不推销它的用途。

当我设置以下内容时,所有客户端的线程锁定问题完全消失:

innodb_buffer_pool_instances=1
(默认)innodb_bufer_pool_size=162G

我对多个 InnoDB 缓冲池的结论

我原本期待使用这个功能,但结果却令人失望。如果您拥有大量相关但分散在缓冲池中的数据集,那么拥有多个缓冲池对您来说并没有多大帮助,从而增加了线程锁定。我希望您可以将数据分配给特定的缓冲池,就像您可以预加载 MyISAM 密钥缓存一样。只有这样,多个缓冲池才会非常方便。

如果您的租户数据库很小但数量很多,则可以使用多个缓冲池。仍然会有线程锁定问题,但不会那么严重。

在我看来,对于大型安装,我会避免使用多个缓冲池。具有大量线程的大型缓冲池工作效率更高。我肯定会专注于使用更多 innodb 线程并利用更多 CPU,这比 MySQL 5.0/5.1 具有明显的优势。

答案2

回复:有关 innodb_buffer_pool_size 和 innodb_buffer_pool_instances 的问题:

我认为这些变量之间的关系存在脱节。innodb_buffer_pool_size 是全部的缓冲池可用。然后将其分配给 innodb_buffer_pool_instances 中引用的线程数。

在上述性能不佳的示例中,2.5GB 被分配给 64 个实例,每个实例剩下 40MB。建议的最低配置(如果您使用这些选项)是每个实例 1GB。我完全明白每个实例 40MB 会导致性能不佳。

在我们的生产环境中,我们运行的服务器有 3 个实例、3GB 池,每个实例 1GB,没有过多的分页。我们还运行 4 个实例、10GB 池,同样没有过多的分页(较新的硬件,为什么不利用这些内存呢)。

希望有所帮助。

相关内容