我的网站偶尔会有相当可预测的流量突发,吞吐量比平常增加100倍.例如,我们将在电视节目中亮相,我预计在演出后的一小时内,我将获得比正常情况多100倍的流量.
我的理解是MySQL(InnoDB)通常将我的数据保存在一堆不同的地方：
> RAM缓冲区
> commitlog
>二进制日志
>实际表格
>我的DB奴隶上面的所有地方
考虑到我在EC2节点上并且大多数东西都经过相同的网络管道(文件系统是网络连接的),这太“耐用”了.此外,驱动器速度很慢.数据价值不高,我宁愿少花几分钟的数据丢失,而不是在人群到来时很可能发生中断.
在这些流量突发期间,我希望只有在我负担得起的情况下才能完成所有这些I / O.我想尽可能多地保留在RAM中(与一小时内触摸的数据大小相比,我有相当大的RAM空间).如果缓冲区变得稀缺,或者I / O通道没有过载,那么我确定,我希望将事务转到commitlog或二进制日志以发送给slave.如果且仅当I / O通道没有过载时,我想回写实际的表.
换句话说,我希望MysqL / InnoDB使用“回写”缓存算法而不是“直写”缓存算法.我可以说服它这样做吗？
如果这是不可能的,我对一般的MysqL写性能优化技巧感兴趣.大多数文档都是关于优化读取性能的,但是当我收到大量用户时,我正在为所有用户创建帐户,因此这是一个繁重的工作量.
提交数据时,会将其写入日志文件以进行恢复,但对表空间(数据)的修改仅在以后作为后台进程(“检查点”)进行.
您可以在较新的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/