innodb_flush_log_at_trx_commit:
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次;1,则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的ACID;设置为2,每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。显然,设置为0或2可以减小系统的io压力,特别是0时,速度最快,提高mysql写操作的吞吐量,但mysql或操作系统的崩溃、断电都可能会引起数据的丢失,设置为2时os的崩溃和断电可能会引起数据的丢失。
innodb_flush_method:
影响了服务器flush数据或日志文件的方法。具体有三个选值:默认的default,innodb使用fsync()函数flush数据和日志文件;O_DIRECT,innodb使用O_DIRECT的方式打开数据文件,并使用fsync()函数flush数据和日志文件;O_DSYNC,innodb使用O_SYNC打开并flush日志文件,使用fsync()函数flush数据文件。
注:在类unix操作系统中,文件的打开方式为O_DIRECT会最小化缓冲对io的影响,该文件的io是直接在用户空间的buffer上操作的,并且io操作是同步的,因此不管是read()系统调用还是write()系统调用,数据都保证是从磁盘上读取的;O_SYNC方式表示以同步io的方式打开文件,任何写操作都将阻塞到数据写入物理磁盘后才返回。fsync(int filedes)函数只对由文件描述符filedes指定的单一文件起作用,并且等待写磁盘操作结束,然后返回。fdatasync(int filedes)函数类似于fsync,但它只影响文件的数据部分。而除数据外,fsync还会同步更新文件的元信息到磁盘。
sync_binlog:
影响了binary log的fllush,当为1时,每个事物提交后,mysql将用fdatasync()函数将二进制日志同步到磁盘上;当为0时,mysql不会做额外的flush,而是依靠os的flush。
做过一些相应的测试,获得一些以上三参数搭配使用的结论:
1)O_DIRECT的flush_method更适合于操作系统内存有限的情况下(可以避免不必要的对交换空间的读写操作),否则,它会由于禁用了os的缓冲降低对数据的读写操作的效能。
2)Sync_binlog为1时,每个含有修改操作的事物提交后,mysql将把二进制日志同步到磁盘上,增大了io压力,引起相应瓶颈,会降低对数据写操作的效率。而select操作不写入binary log,所以不受任何影响。
3)对于innodb_flush_log_at_trx_commit与innodb_flush_method的不同组合(0|1|2,default|O_DSYNC)(对于O_DIRECT的情况特殊,已经在1)中单独做了总结在此不累述)分析得:
①(0, default)每秒钟调用fsync()同步一次innodb logfile,io压力小,性能高,但可能损失数据;
②(1, default)每秒钟和每次commit调用fsync()同步一次innodb logfile,保证数据完整的同时,加大了io压力,吞吐量相对低;
③(2, default)速度介于前两者之间,也不能完全保证数据的安全;
④(0,O_DSYNC)每秒同步日志及数据文件,吞吐量等情况应与(0, default)基本一致;
⑤(1,O_DSYNC)每秒钟和每次commit同步数据及日志文件,相应于(1, default)情况一致;
⑥(2,O_DSYNC)虽然innodb_flush_log_at_trx_commit设置为2,innodb被告知每次事务提交引起写入日志文件的动作,每秒钟完成一次flush磁盘操作,但由于O_DSYNC的设置使得os对日志自动做了同步工作,所以吞吐量等情况与(1, default)和(1,O_DSYNC)相一致。
分享到:
相关推荐
这样的好处,减少了事务数据丢失的概率,而对底层硬件的 IO 要求也没有那么高(log buffer 写到文件系统中,一般只是从 log buffer 的内存转移
可以看到,只有1才能真正地保证事务的持久性,但是由于刷新操作 fsync() 是阻塞的,直到完成后才返回,我们知道写磁盘的速度是很慢的,因此 MySQL 的性能
在网上看了无数的my....结果是只有innodb_flush_log_at_trx_commit可以提高性能,对于1,2,3参数无论是开其中某一个,还是三个同时调节都没有影响到测试性能。我想了下,可能是我的测试数据量还不够大造成的,后续有条
[client] port=3306 [mysql] no-beep default-character-set=utf8 [mysqld] datadir=D:/Data port=3306 server-id=...log_file_size=1G innodb_log_buffer_size=8M innodb_flush_log_at_trx_commit=2 innodb_file_per_t
query_cache_size、query_cache_type、innodb_buffer_pool_size、innodb_log_file_size、innodb_log_buffer_size、innodb_flush_logs_at_trx_commit、transaction_isolation、innodb_file_per_table、innodb_open_...
在Windows下安装MySQL ,用了官方的配置... 后来又看到一个设置innodb_flush_log_at_trx_commit innodb_flush_log_at_trx_commit (这个很管用) 抱怨Innodb比MyISAM慢 100倍?那么你大概是忘了调整这个值。默
默认为2402,调到512-1024最佳 innodb_additional_mem_pool_size=4M 默认为2M innodb_flush_log_at_trx_commit=1 (设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1) innodb_log_buffer_size=2M ...
上篇blog《InnoDBselect性能拐点测试》测试了InnoDBselect的性能拐点,... 1、调整my.cnf的参数如下: innodb_file_per_table=0 innodb_flush_log_at_trx_commit=2 innodb_buffer_pool_size=8G innodb_file_i
这次修改了下面四个配置项: 1)将 innodb_flush_log_at_trx_commit 配置设定为0;按过往经验设定为0,插入速度会有很大提高。 0: Write the log buffer to the log file and flush the log file every second, but ...
安装环境 centos 5.4 mysql 5.1.xx 采用rpm直接安装 xtrabackup 1.2.22 采用rpm直接安装 代码如下: [mysqld] server-id = 1 log-bin innodb_flush_log_at_trx_commit=1 sync_binlog=1 datadir=/var/lib/mysql ...
Master:/etc/my.cnf [mysqld] server-id = 1 log-bin innodb_flush_log_at_trx_commit=1 sync_binlog=1 datadir=/var/lib/mysql character-set-server=utf8 init_connect=’SET NAMES utf8’设定了默认字符集为utf8...
Master:/etc/my.cnf 代码如下:[mysqld] server-id = 1log-bin innodb_flush_log_at_trx_commit=1 sync_binlog=1 datadir=/var/lib/mysql character-set-server=utf8 init_connect=’SET NAMES utf8′ 设定了默认...
# 0:如果innodb_flush_log_at_trx_commit的值为0,log buffer每秒就会被刷写日志文件到磁盘,提交事务的时候不做任何操作(执行是由mysql的master thread线程来执行的。 # 主线程中每秒会将重做日志缓冲写入磁盘的...