当前位置：首页 > 文章列表 > 数据库 > MySQL > 快速带你读懂MySQL的Binlog写入机制

快速带你读懂MySQL的Binlog写入机制

来源：51cto 2023-06-08 17:04:20 0浏览收藏

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《快速带你读懂MySQL的Binlog写入机制》，这篇文章主要会讲到MySQL、机制、binlog等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

深入讲解MySQL中的重要日志 binlog 的写入机制以及影响IO性能的关键配置，并且介绍了如何利用binlog去恢复数据，保证MySQL的可靠性。

Q：binlog写入时机

binlog 的写入逻辑并不复杂：事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到 binlog 文件中。

什么是binlog cache？

binlog cache 在事务的运行期间暂存着binlog的数据，binlog cache 是在每个线程内空间独立的。如果启用了bin log日志，MySQL 会为每个客户端分配一个二进制日志缓存。如果您经常使用大型事务，则可以增加此缓存大小以获得更好的性能，可通过 binlog_cache_size 配置其大小，默认 32768 bytes。

如果binlog cache空间足够，在事务提交的时候，cache中的内容会被清空，同时这些数据会被写入到 binlog files 中；因为 bin log内容无论多大在事务提交时都需要一次性写入，所以当 bin log cache放不下的时候，就需要暂存到磁盘，然后提交被写入到 binlog files。

参数 binlog_cache_size:控制单个线程内 binlog cache 所占内存的大小

上面说的写入到 bin log 中其实又拆为两部分：

write首先会写入 page cache 中的 binlog files 中，page cache 就是一块内存。（不占用磁盘IOPS）
fsync然后操作系统执行 fsync 时 bin log 才会从 page cache 中真正持久化到磁盘。（占用磁盘IOPS）

write 和 fsync写入时机

关于write和fsync 的时机，是通过参数 sync_binlog 控制：

sync_binlog=0：表示每次提交事务只是 write，不执行 fsync，也就是binlog不做持久化。（不建议）
sync_binlog=1：表示每次提交事务都要发生 fsync。
sync_binlog=N：表示每次事务都会write，但是N次事务提交会执行fsync进行持久化。

通常来说，为了提高IOPS，会将这个参数设为100-1000。缺点是如果还没有执行fsync就宕机，最多会丢失最近N个事务的binlog日志。如果为了保证数据安全，就设为1。

如果binlog内容缺失怎么办？

对于通过 redo log 可以恢复数据，我们都已经知道了，但是如果 binlog 内容缺失呢？

根据 sync_binlog 参数描述，如果设置为大于一，就代表N次事务才会将log持久化到磁盘中。而与此同时，redo log 的 innodb_flush_log_at_trx_commit 参数设置为1，表示每次事务提交都会执行 fsync。

这就产生了一种可能，如果发生mysql服务器了crash，此时redolog已经做持久化，但是binlog还有事务仍保存在page cache中，没有来得及执行fsync。宕机后重启服务，依赖redolog恢复数据，就会出现binlog 长度比真实数据所应该需要的长度短的情况。

面对数据完整但是binlog缺失，这种情况下会出现什么异样呢？

如果 MySQL 服务器在崩溃恢复时发现二进制日志比应有的短，则它至少缺少一个成功提交的 InnoDB 事务。如果 sync_binlog=1 并且磁盘/文件系统在请求时进行实际同步（有些则没有），则不会发生这种情况，所以服务器打印一条错误消息日志。在这种情况下，此二进制日志不正确，应从源数据的新快照重新启动复制。

按照官方描述，如果将 sync_binlog设为1不会出现这种情况，如果出现了binlog比预期少，则会在服务器打印一条binlog日志的异常log：The binary log xxx is shorter than its expected size.

所以这种情况需要去人为干预处理，从最新的快照数据源重新复制。