本篇文章给大家带来了关于mysql中写入Binary Log流程的相关知识,其中包括“sync_binlog”、“binlog_cache_size”和“max_binlog_cache_size”的相关问题,希望对大家有帮助。
我们首先还是先看看官方文档对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
为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性,请使用以下设置:
警告
许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新,即使它还没有发生。在这种情况下,即使使用推荐的设置也无法保证事务的持久性,在最坏的情况下,断电可能会损坏
InnoDB
数据。SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可加快文件刷新速度,并使操作更安全。您还可以尝试禁用硬件缓存中磁盘写入的缓存。
另外我们通过sync_binlog=0的描述其实我们也可以大概能感觉到,其实当事务提交的时候虽然没有马上fsync,但是其实是已经write到文件系统的page cache中了,那么其实mysql在事务运行的时候也会有一个cache缓存在事务中产生的Binary Log。
下面我们继续看看Binary Log在事务运行时的cache相关配置。
命令格式 | --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 系统变量控制。
命令格式 | --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系统变量的可见性;换句话说,更改其值只会影响更改值后启动的新会话。
从上面的配置,我们可以得出,Binary Log大致的写入流程:
所以大致流程如下图:
至此我们大致了解了Mysql写入Binary的流程,需要经过:每个事务持有的binlog cache -> 文件系统的page cache -> 磁盘。可以通过sync_binlog进行控制具体执行策略。
推荐学习:mysql视频教程
以上就是完全掌握MySql之写入Binary Log的流程的详细内容,更多请关注php中文网其它相关文章!
已抢48380个
抢已抢3561个
抢已抢1412个
抢已抢1533个
抢已抢2202个
抢已抢2948个
抢