简体繁体 English

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

[英]Why MySQL still uses fsync() to flush the data when the option is O_DIRECT?

原文 2017-01-03 09:42:52 9 2 mysql

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

Based on the article description above, if we choose the option O_DIRECT, it describes as below:根据上面的文章描述，如果我们选择 O_DIRECT 选项，它的描述如下：

O_DIRECT: InnoDB uses O_DIRECT (or directio() on Solaris) to open the data files, and uses fsync() to flush both the data and log files. O_DIRECT：InnoDB 使用 O_DIRECT（或 Solaris 上的 directio()）打开数据文件，并使用 fsync() 刷新数据和日志文件。

As option O_DIRECT means no\minimizing data would be cached in the OS page cache, however fsync() is used to flush the data from the page cache to device, so my question is why MySQL still use fsync() to flush both the data when the option is O_DIRECT?由于选项 O_DIRECT 意味着 no\minimizing 数据将缓存在 OS 页面缓存中，但是 fsync() 用于将数据从页面缓存刷新到设备，所以我的问题是为什么 MySQL 仍然使用 fsync() 来刷新数据何时选项是o_direct？

2 个解决方案

Actually, the explanation is added in the documentation you linked in the paragraph following O_DIRECT option's description (highlighting is mine):实际上，解释已添加到您在O_DIRECT选项描述之后的段落中链接的文档中（突出显示是我的）：

O_DIRECT_NO_FSYNC: InnoDB uses O_DIRECT during flushing I/O, but skips the fsync() system call afterward. O_DIRECT_NO_FSYNC：InnoDB 在刷新 I/O 期间使用 O_DIRECT，但之后跳过 fsync() 系统调用。 This setting is suitable for some types of file systems but not others.此设置适用于某些类型的文件系统，但不适用于其他类型。 For example, it is not suitable for XFS.例如，它不适合 XFS。 If you are not sure whether the file system you use requires an fsync(), for example to preserve all file metadata, use O_DIRECT instead.如果您不确定您使用的文件系统是否需要 fsync()，例如保留所有文件元数据，请改用 O_DIRECT。 This option was introduced in MySQL 5.6.7 (Bug #11754304, Bug #45892).此选项是在 MySQL 5.6.7 中引入的（错误 #11754304，错误 #45892）。

MySQL bug #45892 contains additional information: MySQL 错误#45892包含附加信息：

Some testing by Domas has shown that some filesystems (XFS) do not sync metadata without the fsync. Domas 的一些测试表明，某些文件系统 (XFS) 在没有 fsync 的情况下不会同步元数据。 If the metadata would change, then you need to still use fsync (or O_SYNC for file open).如果元数据会发生变化，那么您仍然需要使用 fsync（或 O_SYNC 来打开文件）。

For example, if a file grows while O_DIRECT is enabled it will still write to the new part of the file, however since the metadata doesn't reflect the new size of the file the tail portion can be lost in the event of a crash.例如，如果在启用 O_DIRECT 时文件增长，它仍将写入文件的新部分，但是由于元数据不反映文件的新大小，因此在发生崩溃时尾部部分可能会丢失。

Solution:解决方案：

Continue to use fsync when important metadata changes or use O_SYNC in addition to O_DIRECT.当重要的元数据发生变化时继续使用 fsync 或在 O_DIRECT 之外使用 O_SYNC。

To sum it up: not using fsync() with certain file systems would cause MySQL to fail.总结一下：不对某些文件系统使用 fsync() 会导致 MySQL 失败。 However, MySQL offers the option from v5.6.7 to configure MySQL (well, innodb) tailored to your own OS' capabilities in this aspect by adding O_DIRECT_NO_FSYNC option.但是，MySQL 提供了 v5.6.7 中的选项，通过添加O_DIRECT_NO_FSYNC选项来配置 MySQL（好吧，innodb）以适应您自己的操作系统在这方面的能力。

O_DIRECT skips OS cache but it does not ensure that data is persisted on disk. O_DIRECT 会跳过操作系统缓存，但不能确保数据持久保存在磁盘上。 O_DIRECT writes only to drive write cache. O_DIRECT 仅写入驱动器写入缓存。 Once drive write cache is disabled the rate falls down to fsync level.一旦驱动器写入缓存被禁用，速率就会下降到 fsync 级别。 O_DIRECT could be a good option if drive write is crash safe (backed by a battery).如果驱动器写入是崩溃安全的（由电池支持），O_DIRECT 可能是一个不错的选择。

Check this blog for a very thorough analysis检查此博客以获得非常彻底的分析