mysql中sync_binlog和innodb_flush_log_at_trx_commit怎么用

这篇文章主要介绍了mysql中sync_binlog和innodb_flush_log_at_trx_commit怎么用，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

sync_binlog：

其值默认为0，范围为0~4294967295（mysql 5.6）
〇 为0时，即mysqld不去控制磁盘的同步，而是等待操作系统的fdatasync从内存flush到磁盘。（与操作系统同步）。在复制结构中，dump线程会在flush阶段进行binlog传输。
〇 最安全的设置为1，在开启了autocommit的情况下，如果mysqld或者os此时crash掉，会至多遗失一个事务。（同时也是最慢的设置）。在复制结构中，dump线程会在sync阶段进行binlog传输。
〇 当值为范围内其他值时，如100，即意味着mysql在写100次binlog时，再将缓存刷到磁盘。在复制结构中，dump线程会在flush阶段进行binlog传输。

将该值设置为稍大的情况下，可以提高tps，并且需要使用battery-backed cache防止异常断电。




innodb_flush_log_at_trx_commit：
（控制REDO log刷盘策略）
其默认值为1，其他可取值为0和2。
〇 当为1时，每个事务提交，将会使log buffer的内容写到log file中，同时将被flush到磁盘，这也是最安全的做法。可以完全遵从ACID。（the contents of the InnoDB log buffer are written out to the log file at each transaction commit and the log file is flushed to disk.）
〇 当为0时，每个事务提交，会写入mysqld自己的log buffer中，每隔1秒将log buffer的内容写到log file中，然后flush到磁盘。
〇 当为2时，每个事务提交，就会被写到log file(OS cache)，但是log file每隔1秒才会被flush到磁盘，当操作系统crash或断电时，此时至多丢失1秒的事务。


0和2的区别是，
为0时，mysqld或操作系统crash则会导致1秒内的事务被丢失。
为2时，当操作系统crash或断电会导致1秒内的事务被丢失。

性能而言（由快至慢）：
0>2>1
安全性而言（由好至差）：
1>2>0

感谢你能够认真阅读完这篇文章，希望小编分享的"mysql中sync_binlog和innodb_flush_log_at_trx_commit怎么用"这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!