这还是个坏主意吗？我知道
MySQL的旧版本在NFS上表现不佳.我想问题就在于使用fsnc()和/或O_DIRECT.如果问题大多已经解决,是否存在常见的陷阱/问题,特别是在一个大型(具有数千万条记录的多个表)InnoDB数据库中,可能会看到高达20-50次读取/秒
解决方法
对您而言,第一条好消息是,在etherspace中现在有
more information比一年前提出的相同问题.我从痛苦的经历中知道这一点.
- ONTAP MysqL Enterprise NFS iSCSI FCP
- 7G 5.X Supported Supported Supported
- 7G 4.X Supported Supported Supported
- MysqL Enterprise versions 4.X and 5.X are supported on all NetApp fabric
- attached storage models running any release of Data ONTAP 7G for any server
- platform supported by MysqL that is listed in the NetApp host compatibility
- matrix for each protocol.
秒钟的好消息是你没有说MyISAM.否则,这将是一个非常不同和更模糊的故事,包括糟糕的表现和没有支持信息.除了使用基于块的iSCSI或FCP之外,没有太多选择.并不是那些不能很好地工作,但它们是基于文件的略有不同的鱼.
相反,Netapp已经在所有三种存储协议上发布了一些OLTP benchmarks的MysqL 5.0.结果表明,InnoDB引擎表现良好,符合Oracle中的协议差异. FCP在吞吐量方面名列前茅.虽然iSCSI为9％,NFS却比FCP低16％.这与我们预期的差别不大.
更有帮助的是,同一文档详细介绍了NFS和InnoDB为实现该基准数据所采取的具体步骤.这些包括修改innodb_buffer_pool_size,innodb_flush_method,NFS的属性缓存超时,源卷上的no_atime_update以及(如Richard所述)为日志指定不同的挂载点.
我个人不建议将日志存储在不同的存储器上,例如本地磁盘.日志与已经下载到磁盘的任何数据密切相关.如果你将它们完全分开,那么你可能会让自己陷入堕落.如果您希望执行快照,更改运行MysqL的机器或您的本地磁盘证明不如文件管理器可靠.
尽管如此,你可以做的下一个最好的事情就是吸吮并看到.根据文档中的最佳实践设置环境,并使用您自己的数据执行一些基准测试.评估当前与本地磁盘相比的性能.
–
