mysql log-bin开启,mysql binlog设置

　　浅谈MySQL bin日志的编写机制及如何配置在线参数_wx60fa2debb47d1 _博客的技术博客

　　目录

　　第一，binlog的缓存，第二，刷机机制，第三，推荐策略，推荐阅读，问个问题！为什么需要知道binlog的坠落机制？

　　我来回答一下：

　　上一篇文章提到，在生产环境中，可以使用binlog进行数据恢复、审计，构建主从架构的MySQL集群。当你使用这些特性时，你会问自己，binlog安全吗？记录的数据会少吗？因为用有问题的binlog进行数据恢复、审计、搭建主从MySQL集群的结果肯定是错误的！

　　接下来我们来看看binlog在MySQL执行事物的过程中的掉盘机制。MySQL如何保证你使用的binlog是安全的！

　　首先，binlog的缓存。首先介绍一个概念：binlog的缓存。

　　含义：所有未提交的东西生成的binlog都会先记录在binlog缓存中。提交事务时，缓存中的数据将被写入binlog日志文件。

　　默认情况下，缓存大小可以通过参数binlog_chache_size设置为32768，每个会话都有自己独立的缓存。多个对话手指互不影响。

　　Binlog_chache_size不能设置太大，否则很多东西肯定会造成宝贵的内存资源浪费。但是也不要太小，因为当一个东西生成的日志大到超过这个参数设置的值时，MySQL会把缓存中的binlog数据写到一个临时文件中。

　　看到这里我们已经知道binlog会被写入缓存，我们可以通过上面的参数动态调整缓存。别急，继续找。binlog什么时候写到磁盘？

　　第二，刷盘的机理。实际上，binlog写入磁盘的机制是由参数sync_binlog控制的。

　　1:策略：sync_binlog=0。当sync _ binlog=0时，表示innodb不会主动控制binlog脱离磁盘。innodb只会将binlog写入OS缓存，何时将binlog刷入磁盘完全取决于操作系统。采用这种策略，一旦操作系统停机，操作系统缓存中的binlog就会丢失。2:策略：sync_binlog=1当sync _ binlog=1被设置时，意味着事情提交时将丢弃binlog！即使机器宕机，也能保证binlog被写到磁盘。你觉得我说的“当事情发生时放弃binlog”含糊不清吗？

　　是啊！仔细品味的话，这句话真的很含糊！

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

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

　　我打算放在X文章里，“能说说MySQL的两阶段提交吗？”详细展开，欢迎关注，敬请期待！

　　3: sync_binlog=N其中N不是0或1。

　　当n大于1时，表示开始分组提交，即分组提交。如果你之前对group commit不了解，可以这样理解：比如N=5，MySQL会等5个binlog被收集后，再一口气同步到磁盘。优势很明显。一个IO可以刷N个binlog到磁盘，IO效率会提高。缺点也很明显，比如N=5，那么当MySQL收集4个binlog时，服务器宕机，这4个binlog就会丢失。

　　三。推荐策略在线环境下，建议设置如下图所示的刷日志策略。

　　这也是官方推荐的配置策略。这两个参数之前已经提到过了。想必你已经知道他们为什么这么设定了吧！

　　参考：

　　https://dev . MySQL . com/doc/ref man/5.7/en/replication-options-binary-log . html

　　https://dev . MySQL . com/doc/ref man/5.7/en/innodb-parameters . html # sys var _ innodb _ flush _ log _ at _ Trx _ commit

　　版权归作者所有：原创作品来自给我白日梦的博主，转载授权请联系作者，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。