共计 3298 个字符，预计需要花费 9 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“MySql 中 Binary Log 的流程是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“MySql 中 Binary Log 的流程是什么”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
Binary Log 写入流程
我们首先还是先看看官方文档对 sync_binlog 配置的描述。
sync_binlog
命令行格式 –sync-binlog=# 系统变量 sync_binlog 影响范围 Global 动态的 YesSET_VAR 提示适用 No 类型 Integer 默认值 1 最小值 0 最大值 2^32=4294967295
控制 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
命令格式 –binlog-cache-size=# 系统变量 binlog_cache_size 范围 Golbal 动态的 YesSET_VAR 提示适用 No 类型 Integer 默认值 32768 最小值 4096 最大值(64 位平台)2^64=18446744073709547520 最大值(32 位平台)2^32=4294967295 块大小 4096
在事务期间保存二进制日志更改的内存缓冲区的大小。该值必须是 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=# 系统变量 max_binlog_cache_size 范围 Golbal 动态的 YesSET_VAR 提示适用 No 类型 Integer 默认值 2^64=18446744073709547520 最小值 4096 最大值 2^64=18446744073709547520 块大小 4096
如果一个事务需要超过这么多字节的内存，服务器会生成一个多语句事务需要超过 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 大致的写入流程：
事务改在运行时，放入每个事务的 Binary Log 缓存中。
事务提交后根据配置来进行，如果是 sync_binlog=1，则每次进行 fsync，缓存会释放。如果是 sync_binlog=0，则会直接写入系统文件的 page cache，依赖于操作系统不时地将二进制日志刷盘。如果 sync_binlog=N(N 1)，则相当于批量刷盘，当然每个事务持有的 binlog cache 会进行释放。
所以大致流程如下图：
读到这里，这篇“MySql 中 Binary Log 的流程是什么”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
