为什么 MySQL 在选项为 O_DIRECT 时仍然使用 fsync() 来刷新数据？

Question

http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_method

根据上面的文章描述，如果我们选择 O_DIRECT 选项，它的描述如下：

O_DIRECT：InnoDB 使用 O_DIRECT（或 Solaris 上的 directio()）打开数据文件，并使用 fsync() 刷新数据和日志文件。

由于选项 O_DIRECT 意味着 no\minimizing 数据将缓存在 OS 页面缓存中，但是 fsync() 用于将数据从页面缓存刷新到设备，所以我的问题是为什么 MySQL 仍然使用 fsync() 来刷新数据何时选项是o_direct？

Answer 1

实际上，解释已添加到您在O_DIRECT选项描述之后的段落中链接的文档中（突出显示是我的）：

O_DIRECT_NO_FSYNC：InnoDB 在刷新 I/O 期间使用 O_DIRECT，但之后跳过 fsync() 系统调用。 此设置适用于某些类型的文件系统，但不适用于其他类型。 例如，它不适合 XFS。 如果您不确定您使用的文件系统是否需要 fsync()，例如保留所有文件元数据，请改用 O_DIRECT。 此选项是在 MySQL 5.6.7 中引入的（错误 #11754304，错误 #45892）。

MySQL 错误#45892包含附加信息：

Domas 的一些测试表明，某些文件系统 (XFS) 在没有 fsync 的情况下不会同步元数据。 如果元数据会发生变化，那么您仍然需要使用 fsync（或 O_SYNC 来打开文件）。

例如，如果在启用 O_DIRECT 时文件增长，它仍将写入文件的新部分，但是由于元数据不反映文件的新大小，因此在发生崩溃时尾部部分可能会丢失。

解决方案：

当重要的元数据发生变化时继续使用 fsync 或在 O_DIRECT 之外使用 O_SYNC。

总结一下：不对某些文件系统使用 fsync() 会导致 MySQL 失败。 但是，MySQL 提供了 v5.6.7 中的选项，通过添加O_DIRECT_NO_FSYNC选项来配置 MySQL（好吧，innodb）以适应您自己的操作系统在这方面的能力。

Answer 2

O_DIRECT 会跳过操作系统缓存，但不能确保数据持久保存在磁盘上。 O_DIRECT 仅写入驱动器写入缓存。 一旦驱动器写入缓存被禁用，速率就会下降到 fsync 级别。 如果驱动器写入是崩溃安全的（由电池支持），O_DIRECT 可能是一个不错的选择。

检查此博客以获得非常彻底的分析