这是仍然一个坏主意?我知道旧版本的 MySQL 在 NFS 上表现不佳。我猜问题在于使用 fsnc() 和/或 O_DIRECT。如果问题大部分得到解决,是否存在常见的陷阱/问题,特别是在大型(多个表包含数千万条记录)InnoDB 数据库周围,每秒的读取次数可能高达 20-50 次
答案1
对你来说第一个好消息是现在更多信息在以太空间,你问同样的问题要比一年前早得多。我从痛苦的经历中知道这一点。
Netapp 的官方说法是,MySQL 支持这三种协议。
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 基准MySQL 5.0 在所有三种存储协议上的性能测试结果。结果表明,InnoDB 引擎性能良好,与 Oracle 中看到的协议差异一致。FCP 在吞吐量方面名列前茅。而 iSCSI 落后 FCP 9%,NFS 落后 16%。这并不像我们预期的那样有显著差异。
更有帮助的是,同一篇文档详细介绍了他们为实现该基准数字而采取的 NFS 和 InnoDB 特定步骤。这些步骤包括修改innodb_buffer_pool_size
源卷上的innodb_flush_method
NFS 属性缓存超时,no_atime_update
以及(如 Richard 上面所述)为日志指定不同的挂载点。
我个人不建议将日志存储在不同的存储设备(例如本地磁盘)上。日志与已存储到磁盘上的任何数据密切相关。如果将它们完全分开,那么你可能会陷入困境。如果你想执行快照、更换运行 MySQL 的机器,或者你的本地磁盘被证明不如文件管理器可靠,那就更是如此了。
综上所述,您接下来要做的就是尝试一下。根据文档中的最佳实践设置环境,并使用您自己的数据执行一些基准测试。评估它与您当前的本地磁盘相比的性能。
--
注意:第一个链接现在已受限制。您没有说明自己是否已经是 Netapp 客户。但无论如何,您都应该能够查看第二个链接。
答案2
如果您可以使用 NFS4,那将是最佳选择。我至少会使用 noatime 进行挂载。您还应该考虑在本地磁盘上指定日志文件位置。如果您没有本地存储(这在 VM 中很常见),您可以尝试将日志存储在通过与主存储不同的网络接口路由的挂载点上。
答案3
就我个人而言,在为 MySQL 安装 NetApp 磁盘时,我会使用 iSCSI 而不是 NFS。效率极高,而且您可以直接访问 LUN 的文件系统。
答案4
只要您不使用 berkleydb,MySQL/InnoDB 就可以很好地用于 NFS。我不确定 Netapp NFS 文档中说了什么,但如果您使用“异步”选项安装 NFS 卷,则应用程序将不会被阻止等待写入磁盘。