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

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

(资料图片)

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和fsync 的时机，是通过参数 sync_binlog 控制：

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

对于通过 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.

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

binlog 会记录所有的逻辑操作，并且是采用“追加写”的形式，不会像redolog一样去覆盖日志文件。binlog 里面的数据是可靠的，一定是事务提交后的数据，这就全靠 redolog 来保证。

众所周知，我们可以通过 binlog恢复任意时间点的数据，如何做到呢？

其实这是有前提的，我们必须要有定期备份全量数据的机制，比如半个月、每周、或者每天。

假定场景：比如今天中午12点有一次误删表数据，需要找回数据，如何做？

这样临时库就到达了误删数据之前的状态，然后可以把表数据从临时库取出来，按需求恢复到线上正式数据库。