mysql binlog写频率_谈谈MySQL bin log的写入机制、以及线上的参数是如何配置的

问个问题吧！为什么你需要了解binlog的落盘机制呢？

我来回答一下：

​上一篇文章提到了生产环境中你可以使用binlog做数据的恢复、审计、以及搭建主从架构的MySQL集群。那你使用这些特性优势的时候有没有问自己一下，你使用的binlog是安全的吗？会不会少记录了一部分数据呢？因为使用一个有问题的binlog去做数据恢复、审计、搭建主从MySQL集群的结果肯定是错误的！

​下面，我们一起来看一下MySQL执行事物的过程中 binlog 的落盘机制。MySQL是如何保证你使用的binlog是安全的！

一、binlog 的高速缓存

首先为大家介绍一个概念：binlog的高速缓存

意思是：所有未commit的事物产生的binlog，都会被先记录到binlog的高速缓存中。等该事物被commit时，再将缓存中的数据写入binlog日志文件中。

高速缓存的大小可以由参数binlog_chache_size 默认大小为：32768 ，并且每个session都有自己的独立的缓存。多个会话指间彼此不影响。

binlog_chache_size不能设置太大，否则大量事物打来后肯定会造成宝贵的内存资源被浪费。但是也别太小，因为当一个事物产生的日志足够大超过该参数设置的值时，MySQL会将缓存中的binlog数据写到临时文件中去。

看到这里我们已经知道了binlog会写入缓存中，并且我们可以通过上述参数动态调整该缓冲。别急，继续往看下，binlog何时被写入磁盘呢？

二、刷盘机制

其实binlog写入磁盘的机制由参数sync_binlog控制。

策略1:sync_binlog = 0

当设置sync_binlog = 0时，表示innodb不会主动控制将binlog落盘，innodb仅仅会将binlog写入到OS Cache中，至于什么时间将binlog刷入磁盘中完全依赖于操作系统。选这种策略，一旦操作系统宕机，OS Cache中的binlog就会丢失。

策略2:sync_binlog = 1

设置sync_binlog = 1时，表示事物commit时将binlog落盘！这样哪怕机器宕机了，也能确保binlog会被写入到磁盘中。

你有没有觉得当我说：“当事物commit时将binlog落盘” ，这句话很模糊？？？

是的！如果你仔细品一品，这句话真的很模糊！

当然了，虽然模糊，但是上面说的策略2并没有错误(MySQL官网也是这样描述的)

为了不偏离本篇文章的主线，本篇暂时不详细展开讲 sync_binlog=1 的细节。

我计划放在第 X 篇文章，“能谈谈MySQL的两阶段提交吗？” 详细展开，欢迎关注，敬请期待！

策略3:sync_binlog=N

这里的N不是0，也不是1。

当N大于1时，表示开启组提交，也就是group commit，如果你之前不层了解组提交的话，你可以这样理解它：比如N=5，那MySQL就会等收集5个binlog后再将这5个binlog一口气同步到磁盘上。好处很明显，一次IO可以往磁盘上刷入N个binlog，IO效率会有所提升。坏处也很明显，比如N=5，那当MySQL收集了4个binlog时，服务器宕机，这4个binlog就会丢失。

三、推荐的策略

线上环境中，推荐将日志的刷盘策略设置成下图这这样。

这是也官方推荐的配置策略。这两个参数前面都已经提到过了，想必为什么这么设置，你已经很清楚了！

参考：

推荐阅读