带有 NetApp 的 NFS 上的 MySQL 5.1.34

Question

这仍然是一个坏主意吗？我知道旧版本的 MySQL 在 NFS 上表现不佳。我想问题在于 fsnc() 和/或 O_DIRECT 的使用。如果问题大部分得到解决，是否存在常见的陷阱/陷阱，特别是在大型（具有数千万条记录的多个表）InnoDB 数据库中，可能会看到每秒 20-50 次读取

Answer 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 已经发布了一些跨所有三种存储协议的 MySQL 5.0 OLTP 基准测试。结果表明 InnoDB 引擎表现良好，符合 Oracle 中看到的协议差异。FCP 在吞吐量方面名列前茅。iSCSI 落后 FCP 9%，NFS 落后 16%。这并不像我们预期的那样显着差异。

更有帮助的是，同一份文档详细说明了他们为实现该基准数据所采取的 NFS 和 InnoDB 特定步骤。这些包括在源卷上修改innodb_buffer_pool_size, innodb_flush_method, NFS 的属性缓存超时no_atime_update和（如 Richard 上面所说）为日志指定不同的挂载点。

我个人不建议将日志完全存储在不同的存储中，例如本地磁盘。日志与任何已经下载到磁盘的数据密切相关。如果您将它们完全分开，那么您可能会跌倒。更重要的是，如果您希望执行快照，请更改运行 MySQL 的机器，否则您的本地磁盘被证明不如文件管理器可靠。

尽管如此，您可以做的下一个最好的事情就是吮吸它并观察。根据文档中的最佳实践设置环境，并使用您自己的数据执行一些基准测试。评估它与您今天的本地磁盘相比的性能。

——

注意：第一个链接现在受到限制。您不会说您是否已经是 Netapp 客户。尽管如此，您应该能够查看第二个链接。