MySQL 重要参数 innodb_flush_log_at_trx_commit 和 sync_binlog
innodb_flush_log_at_trx_commit
提交事务的时候将 redo 日志写入磁盘中,所谓的 redo 日志,就是记录下来你对数据做了什么修改,比如对 “id=10 这行记录修改了 name 字段的值为 xxx”,这就是一个日志。如果我们想要提交一个事务了,此时就会根据一定的策略把 redo 日志从 redo log buffer 里刷入到磁盘文件里去。此时这个策略是通过 innodb_flush_log_at_trx_commit 来配置的,他有几个选项。
值为0 : 提交事务的时候,不立即把 redo log buffer 里的数据刷入磁盘文件的,而是依靠 InnoDB 的主线程每秒执行一次刷新到磁盘。此时可能你提交事务了,结果 mysql 宕机了,然后此时内存里的数据全部丢失。
值为1 : 提交事务的时候,就必须把 redo log 从内存刷入到磁盘文件里去,只要事务提交成功,那么 redo log 就必然在磁盘里了。注意,因为操作系统的“延迟写”特性,此时的刷入只是写到了操作系统的缓冲区中,因此执行同步操作才能保证一定持久化到了硬盘中。
值为2 : 提交事务的时候,把 redo 日志写入磁盘文件对应的 os cache 缓存里去,而不是直接进入磁盘文件,可能 1 秒后才会把 os cache 里的数据写入到磁盘文件里去。
可以看到,只有1才能真正地保证事务的持久性,但是由于刷新操作 fsync() 是阻塞的,直到完成后才返回,我们知道写磁盘的速度是很慢的,因此 MySQL 的性能会明显地下降。如果不在乎事务丢失,0和2能获得更高的性能。
# 查询
select @@innodb_flush_log_at_trx_commit;
sync_binlog
该参数控制着二进制日志写入磁盘的过程。
该参数的有效值为0 、1、N:
0:默认值。事务提交后,将二进制日志从缓冲写入磁盘,但是不进行刷新操作(fsync()),此时只是写入了操作系统缓冲,若操作系统宕机则会丢失部分二进制日志。
1:事务提交后,将二进制文件写入磁盘并立即执行刷新操作,相当于是同步写入磁盘,不经过操作系统的缓存。
N:每写N次操作系统缓冲就执行一次刷新操作。
将这个参数设为1以上的数值会提高数据库的性能,但同时会伴随数据丢失的风险。
二进制日志文件涉及到数据的恢复,以及想在主从之间获得最大的一致性,那么应该将该参数设置为1,但同时也会造成一定的性能损耗。
最新文章
- 【腾讯Bugly干货分享】微信Tinker的一切都在这里,包括源码(一)
- iOS - Swift NSRect 位置和尺寸
- Microsoft-pubs(图书馆管理系统)-数据库设计
- 转:PHP – Best Practises
- hdu4758 Walk Through Squares (AC自己主动机+DP)
- svn删除用户
- TCP/IP(一)之初识计算机网络
- ASP.net core 2.0.0 中 asp.net identity 2.0.0 的基本使用(一)—修改数据库连接
- LDA实现
- 读《图解HTTP》有感-(简单的HTTP协议)
- bzoj1692
- MySQL的瑞士军刀
- C#Redis集合set
- Linux 下如何安装 .rpm 文件
- 快速SQL调优/优化(SQL TUNING)——1分钟搞定超慢SQL
- nodejs express 学习
- Castle ActiveRecord学习(三)数据映射及特性描述
- (转)Mysql技术内幕InnoDB存储引擎-表&;索引算法和锁
- oracle最大连接数相关
- iOS 关于时间天数星期月份的总结