在这篇文章中，我们将学习“MySQL中Binary Log写入流程是怎样的呢”的相关知识，下文有详细的介绍及示例，小编觉得挺不错的，有需要的朋友可以借鉴参考，希望对大家阅读完这篇能有所获。

Binary Log写入流程

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

sync_binlog

命令行格式	--sync-binlog=#
系统变量	sync_binlog
影响范围	Global
动态的	Yes
SET_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
动态的	Yes
SET_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
动态的	Yes
SET_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大致的写入流程：

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

所以大致流程如下图：

总结

至此我们大致了解了Mysql写入Binary的流程，需要经过：每个事务持有的binlog cache -> 文件系统的page cache -> 磁盘。可以通过sync_binlog进行控制具体执行策略。

使用

• sync_binlog：如果需要获得最大的持久性和一致性的话就设置成1，至于性能问题可以调整硬件等其他方式；如果运行binary log允许丢失或者丢失通过其他方式控制又想基于目前服务器资源进行优化就设置在[100,1000]区间中。
• binlog_cahe_size：前面已经提到过在实际业务中需要注意对事务粒度进行把控，绝大情况默认的32k足够了。

以上就是关于MySQL中Binary Log写入流程是怎样的呢的介绍啦，需要的朋友可以参考上述内容，希望对大家有帮助，欢迎关注群英网络，小编将为大家输出更多高质量的实用文章！

免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：mmqy2019@163.com进行举报，并提供相关证据，查实之后，将立刻删除涉嫌侵权内容。