降低MySQL的耐用性以提高性能

Question

我的网站偶尔会有相当可预测的流量突发,吞吐量比平常增加100倍.例如,我们将在电视节目中亮相,我预计在演出后的一小时内,我将获得比正常情况多100倍的流量.

我的理解是MySQL(InnoDB)通常将我的数据保存在一堆不同的地方:

• RAM缓冲区
• commitlog
• 二进制日志
• 实际表格
• 以上所有地方都在我的DB奴隶上

考虑到我在EC2节点上并且大多数东西都经过相同的网络管道(文件系统是网络连接的),这太"耐用"了.此外,驱动器速度很慢.数据价值不高,我宁愿少花几分钟的数据丢失,而不是在人群到来时很可能发生中断.

在这些流量突发期间,我希望只有在我负担得起的情况下才能完成所有这些I/O. 我想尽可能多地保留在RAM中(与一小时内触摸的数据大小相比,我有相当大的RAM空间).如果缓冲区变得稀缺,或者I/O通道没有过载,那么我确定,我希望将事务转到commitlog或二进制日志以发送给slave.如果且仅当I/O通道没有过载时,我想回写实际的表.

换句话说,我希望MySQL/InnoDB使用"回写"缓存算法而不是"直写"缓存算法.我可以说服它这样做吗？

如果这是不可能的,我对一般的MySQL写性能优化技巧感兴趣.大多数文档都是关于优化读取性能的,但是当我收到大量用户时,我正在为所有用户创建帐户,因此这是一个繁重的工作量.

Answer 1

在很大程度上，InnoDB 已经做到了这一点。

当您提交数据时，它会被写入日志文件以用于恢复目的，但对表空间（数据）的修改仅在稍后作为后台进程（“检查点”）完成。

您可以指定要在较新的 InnoDB 版本（innodb_io_capacity）中专用于该后台进程的IOPS（http://en.wikipedia.org/wiki/IOPS ），并且前提是您将 innodb_log_file_size 设置得足够大，InnoDB 就会下降落后一段时间，稍后再赶上。

如果 InnoDB 在后台工作上落后太多，当您到达日志文件末尾时，它可能会导致性能急剧下降，并且必须循环返回。请参阅这些基准测试中的“无”行： http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/