- redo log的写入策略
- binlog的写入策略
- 生产配置
- 性能瓶颈
InnoDB提供了innodb_flush_log_at_trx_commit参数,它有三种可能取值:
- 设置为
0
的时候,表示每次事务提交时都只是把redo log
留在redo log buffer
中; - 设置为
1
的时候,表示每次事务提交时都将redo log
直接持久化到磁盘; - 设置为
2
的时候,表示每次事务提交时都只是把redo log
写到page cache
。
查看mysql变量:show VARIABLES LIKE 'innodb_flush_log_at_trx_commit'
binlog的写入策略,write 和fsync的时机,是由参数sync_binlog控制的:
sync_binlog=0
的时候,表示每次提交事务都只write
,不fsync
;sync_binlog=1
的时候,表示每次提交事务都会执行fsync
;sync_binlog=N(N>1)
的时候,表示每次提交事务都write
,但累积N
个事务后才fsync
。
因此,在出现IO瓶颈的场景里,将sync_binlog
设置成一个比较大的值,可以提升性能。在实际的业务场景中,考虑到丢失日志量的可控性,一般不建议将这个参数设成0
,比较常见的是将其设置为100~1000中的某个数值。
但是,将sync_binlog
设置为N
,对应的风险是:如果主机发生异常重启,会丢失最近N
个事务的binlog
日志。
通常情况下,生产都是" 双1 "的配置
,也就是sync_binlog
和 innodb_flush_log_at_trx_commit
的配置都是1
,也就是说,一个事务完整提交前,需要等待两次刷盘,一次是redo log
,一次是binlog
。
如果你的MySQL现在出现了性能瓶颈,而且瓶颈在IO上,可以通过哪些方法来提升性能呢?
针对这个问题,可以考虑以下三种方法:
- 设置
binlog_group_commit_sync_delay
和binlog_group_commit_sync_no_delay_count
参数,减少binlog的写盘次数。这个方法是基于“额外的故意等待”来实现的,因此可能会增加语句的响应时间,但没有丢失数据的风险。 - 将
sync_binlog
设置为大于1的值(比较常见是100~1000)。这样做的风险是,主机掉电时会丢binlog日志。 - 将
innodb_flush_log_at_trx_commit
设置为2。这样做的风险是,主机掉电的时候会丢数据。
我不建议你把innodb_flush_log_at_trx_commit
设置成0。因为把这个参数设置成0,表示redo log
只保存在内存中,这样的话MySQL本身异常重启也会丢数据,风险太大。而redo log
写到文件系统的page cache
的速度也是很快的,所以将这个参数设置成2
跟设置成0
其实性能差不多,但这样做MySQL异常重启时就不会丢数据了,相比之下风险会更小。
到此这篇关于Mysql redo log 写入策略和binlog 写入策略的文章就介绍到这了,更多相关Mysq写入策略内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)