这篇文章主要讲解了"怎么理解关系型数据库的innodb_flush_method ",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"怎么理解关系型数据库的innodb_flush_method "吧!
官方文档描述如下:
默认情况下,InnoDB使用fsync()系统调用来刷新数据和日志文件。如果
innodb_flush_method选项设置为O_DSYNC时,innodb使用O_SYNC来打开和刷新
日志文件,以及fsync()来刷新数据文件。如果指定了O_DIRECT(在某些角马上可用/
Linux操作系统版本、FreeBSD和Solaris),InnoDBuses O _ DIRECT(或Solaris上的directio())到
打开数据文件,并使用fsync()刷新数据和日志文件。请注意,InnoDB使用
fsync()而不是fdatasync(),默认情况下它不使用O_DSYNC,因为有
它在许多种类的Unix操作系统上都有问题。
innodb_flush_method
常规3个值
1、fdatasync
2、O_DSYNC
3、氧直接
正常的访问方式
用户态缓存- 》内核态缓存- 》磁盘
按照关系型数据库的描述
1、fdatasync
InnoDB使用fsync()系统调用来刷新数据和日志文件。
请注意,InnoDB使用fsync()而不是fdatasync()
虽然关系型数据库可以使用fdatasync为参数但是实际上是调用的系统的fsync()函数,
我们可以看看Linux操作系统操作系统下FSYNC()函数的描述
fsync()传输(刷新)由引用的文件的所有已修改的核心内数据(即已修改的缓冲区缓存页面)
文件描述符软驱到磁盘设备(或其他永久存储设备),以便甚至可以检索所有已更改的信息
系统崩溃或重启后。这包括写入或刷新磁盘缓存(如果存在)。呼叫阻塞
直到设备报告传输已经完成。它还会刷新与文件相关联的元数据信息(请参见
统计(2)).
简单的说这个参数用于同步所有线程修改过的文件,而进程中的印刷电路板中记录了打开文件,他是通过文件描述符进行匹配的
在Linux操作系统操作系统内核中/usr/src/Linux-headers-3。19 .0-25-通用/包含/Linux/sched。h
有如下的印刷电路板结构体
struct task_struct { }
其中有一个文件_结构的结构体,而文件描述符就是这样一个结构体的指针
那么只要关系型数据库线程进行了刷新动作,那么他的这些文件的数据一
定会同步到磁盘
2、O_DSYNC
InnoDB uses O_SYNC to open and flush the log files, and fsync()to flush the data files
当设置为这个选项的时候,当MYSQL线程打开LOGFILE的时候使用的O_SYNC的方式,而对数据文件还是使用的fsync()
我们知道对一个文件进行读,打开是使用LINUX的
open()函数,而其中也就有这样一个选项
O_SYNC The file is opened for synchronous I/O. Any write(2)s on the resulting file descriptor will block the calling process
until the data has been physically written to the underlying hardware.
他描述的是如果这样打开一个文件那么在数据从内核态缓存写到了物理磁盘前,任何试图修改文件描述符的进程都会被堵塞。如此保证了日志文件
最大的安全性
3、O_DIRECT
If O_DIRECT is specified (available on some GNU/Linux versions, FreeBSD, and Solaris), InnoDB
uses O_DIRECT(or directio()on Solaris) to open the data files, and uses
fsync()to flush both the data and log files.
使用这个选项MYSQL使用O_DIRECT方式打开数据文件,而fsync()会最终同步所有的数据和日志文件。
我们同样看看open()函数中关于O_DIRECT描述
O_DIRECT (Since Linux 2.4.10)
Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is use‐
ful in special situations, such as when applications do their own caching. File I/O is done directly to/from user-space
buffers. The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees
of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used
in addition to O_DIRECT.
使用这个选项一般来说会降低性能,但是在特定的情况下比如应用程序有自己的缓存机制。I/O直接来自用户态的缓存,O_DIRECT标识对大量的
数据写有利,因为他绕开了内核态缓存,但是他并同步METADATA(这里占时理解为INODE缓存,也就是文件的基本信息比如打开时间修改时间等)
所以要完成同步必须同时调用O_SYNC。
如此我们也了解为什么为什么使用O_DIRECT还会调用FSYNC()我们知道FSYNC()是全同步的,LINUX上的传统的FDATASYNC()是不同步METADATA的
如INODE缓存,进程描述缓存。但是他能够对大量的数据绕开缓存,提高性能,需要最后同步的只是DATAFILE的METADAT。
MYSQL有自己的缓冲,这种可以使用O_DIRECT比较好
感谢各位的阅读,以上就是“怎么理解MySQL的innodb_flush_method”的内容了,经过本文的学习后,相信大家对怎么理解MySQL的innodb_flush_method这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是,小编将为大家推送更多相关知识点的文章,欢迎关注!
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/104197.html