MySql中Binary Log的流程是什么

Binary Log写入流程

我们首先还是先看看官方文档对sync_binlog配置的描述。

sync_binlog

控制 MySQL 服务器将二进制日志同步到磁盘的频率。

• sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL 服务器依赖操作系统不时将二进制日志刷新到磁盘，就像它对任何其他文件所做的那样。此设置提供了最佳性能，但如果发生电源故障或操作系统崩溃，服务器可能已提交尚未刷盘的事务。

• sync_binlog=1：在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。在电源故障或操作系统崩溃的情况下，二进制日志中丢失的事务仅处于准备状态。这允许常规自动恢复回滚事务，从而保证不会从二进制日志中丢失事务。

• sync_binlog=N, 其中是 0 或 1 以外的值：收集到N个二进制日志提交组后，二进制日志会同步到磁盘。在电源故障或操作系统崩溃的情况下，服务器可能已经提交了尚未刷新到二进制日志的事务。由于磁盘写入次数增加，此设置可能会对性能产生负面影响。较高的值会提高性能，但会增加数据丢失的风险。

InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：

• sync_binlog=1.

• innodb_flush_log_at_trx_commit=1.

警告

许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新，即使它还没有发生。在这种情况下，即使使用推荐的设置也无法保证事务的持久性，在最坏的情况下，断电可能会损坏InnoDB数据。SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可加快文件刷新速度，并使操作更安全。您还可以尝试禁用硬件缓存中磁盘写入的缓存。

小结

• sync_binlog设置类型为unsigned Integer。

• 一般不会设置为0，0依赖系统操作不定时fsync，发生电源故障或者系统崩溃的时候比较危险——事务提交了但是Binary Log缺失了。

• 设置为1比较安全，获得最大可能的持久性和一致性，能保证后面的主从复制、恢复。但是对性能不利，当业务需要的IOPS不高可以设置。

• 设置为大于1的值目的是提高性能不是一个事务提交就fsync下，相当于批量刷盘，是比较聪明的方式，但是如果出现电源故障或者系统崩溃的时候Binary Log缺失的会比较多。如果磁盘本身使用电池支持的磁盘缓存会比较安全。所以当业务需要的IOPS比较高时可以设置，但是一般也不会设置过大，可以在[100,1000]区间中。

另外我们通过sync_binlog=0的描述其实我们也可以大概能感觉到，其实当事务提交的时候虽然没有马上fsync，但是其实是已经write到文件系统的page cache中了，那么其实mysql在事务运行的时候也会有一个cache缓存在事务中产生的Binary Log。

下面我们继续看看Binary Log在事务运行时的cache相关配置。

binlog_cache_size

在事务期间保存二进制日志更改的内存缓冲区的大小。该值必须是 4096 的倍数。

在服务器上启用二进制日志记录（ log_bin系统变量设置为 ON）时，如果服务器支持任何事务存储引擎，则会为每个客户端分配一个二进制日志缓存。如果事务的数据超出内存缓冲区中的空间，超出的数据将存储在临时文件中。当服务器上的二进制日志加密处于活动状态时，内存缓冲区未加密，但（从 MySQL 8.0.17 开始）用于保存二进制日志缓存的任何临时文件都被加密。提交每个事务后，通过清除内存缓冲区并截断临时文件（如果使用）来重置二进制日志缓存。

如果您经常使用大型事务，则可以通过减少或消除写入临时文件的需要来增加此缓存大小以获得更好的性能。 Binlog_cache_use（服务状态变量-使用Binary Log缓存的事务数量）和 Binlog_cache_disk_use （服务状态变量-使用临时二进制日志缓存但超过binlog_cache_size值并使用临时文件存储事务语句的事务数。）状态变量可用于调整此变量的大小。请参阅第 5.4.4 节，“二进制日志”。

binlog_cache_size仅设置事务缓存的大小；语句缓存的大小由 binlog_stmt_cache_size 系统变量控制。

小结

• binlog_cache_size设置类型为unsigned Integer。

• 用来指示每个事务期间用来缓存Binary Log的大小，默认为32k，必须是4096的倍数。如果超过这个值会使用临时文件存储。

• 业务中尽量不要使用大事务，如果事务过大需要考虑是否合理。一般不需要对binlog_cache_size进行修改，32k足够了。

• binlog_cache_size不足够的时候会使用临时文件进行存储，但是性能会变低，我们可以设置max_binlog_cache_size=binlog_cache_size这样就不会使用临时文件，下文会介绍。

max_binlog_cache_size

如果一个事务需要超过这么多字节的内存，服务器会生成一个多语句事务需要超过 'max_binlog_cache_size' 字节的存储错误。最小值为 4096。可能的最大值为 16EiB（exbibytes）。最大推荐值为4GB；这是因为 MySQL 目前无法处理大于 4GB 的二进制日志位置。该值必须是 4096 的倍数。

max_binlog_cache_size仅设置事务缓存的大小；语句缓存的上限由 max_binlog_stmt_cache_size 系统变量控制。

会话的可见性 max_binlog_cache_size匹配 binlog_cache_size系统变量的可见性；换句话说，更改其值只会影响更改值后启动的新会话。

总结

• max_binlog_cache_size是一个安全值，一般根据服务器可分配的内存进行设置。

概述

从上面的配置，我们可以得出，Binary Log大致的写入流程：

1. 事务改在运行时，放入每个事务的Binary Log缓存中。

2. 事务提交后根据配置来进行，如果是sync_binlog=1，则每次进行fsync，缓存会释放。如果是sync_binlog=0，则会直接写入系统文件的page cache，依赖于操作系统不时地将二进制日志刷盘。如果sync_binlog=N(N>1)，则相当于批量刷盘，当然每个事务持有的binlog cache会进行释放。

所以大致流程如下图：