为什么有时候binlog文件会很大于max_binlog_size以及max_binlog_cache_size

问题描述

线上一个很有意思的现象,发现binlog文件大小是15G,查看了参数max_binlog_size是1073741824[1G], max_binlog_cache_size是21474836480[20G]。那么为什么会文件大小会超过max_binlog_file_size的设置。这个问题比较好理解,如果是大事务呢?那么这里有一个小问题,binlog里面是以event为单位来记录的,那么事务有可能跨binlog吗?使用BEGIN;***;***;commit进行测试

第二个问题,以上面的设置为例,在文件快到1G的时候,如果来了一个大事务,这个大事务接近20G,那么是不是可以任务binlog文件的最大可能值是接近1G+20G=21G呢,因为超过max_binlog_cache_size就会报错了。这个也是可以测试下的。

实验证明

  问题1:实验测试

root@test10:39:24>set global max_binlog_size=4096;

root@test10:48:23>begin;
Query OK, 0 rows affected (0.00 sec)

root@test10:48:39>insert into testb select * from testa limit 32;
Query OK, 32 rows affected (0.00 sec)
Records: 32  Duplicates: 0  Warnings: 0

root@test10:49:05>insert into testb select * from testa limit 32;
Query OK, 32 rows affected (0.00 sec)
Records: 32  Duplicates: 0  Warnings: 0

root@test10:49:10>insert into testb select * from testa limit 32;
Query OK, 32 rows affected (0.00 sec)
Records: 32  Duplicates: 0  Warnings: 0

root@test10:49:14>insert into testb select * from testa limit 32;
Query OK, 32 rows affected (0.00 sec)
Records: 32  Duplicates: 0  Warnings: 0

root@test10:49:18>commit;
Query OK, 0 rows affected (0.00 sec)

# at 3994  -- 上一个event结束的地方
#190130 10:49:14 server id 21036055 end_log_pos 4064 CRC32 0x64e8a1c6 Rows_query
# insert into testb select * from testa limit 32
# at 4064
#190130 10:49:14 server id 21036055 end_log_pos 4113 CRC32 0x7ef21b8c Table_map: `test`.`testb` mapped to number 11496
# at 4113
#190130 10:49:14 server id 21036055 end_log_pos 4692 CRC32 0xfc3f78bd Write_rows: table id 11496 flags: STMT_END_F  -- 这已经是下一个insert 语句了,在一个binlog文件中,说明binlog是以事务为单位来进行切割的,不是事务里面的单个sql语句,这也是比较好理解的,因为事务只有执行完了, 才能在内存中生成完整的binlog,才存在刷盘的操作。

问题2:实验测试

root@test11:01:52>set global  max_binlog_cache_size=4096;[email protected]:15:20>insert into testb select * from testb limit 200;   --  3.9K Jan 30 11:15 mysql-bin.003691[email protected]:15:28>insert into testb select * from testb limit 460;   --  12K Jan 30 11:16 mysql-bin.003691[email protected]:17:34>insert into testb select * from testb limit 470;   --  最大就是在460到470之间   ERROR 1197 (HY000): Multi-statement transaction required more than ‘max_binlog_cache_size‘ bytes of storage; increase this mysqld variable and try again这个实验说明binlog文件最大应该是max_binlog_size + max_binlog_cache_size的和,但是max_binlog_cache_size在文件大小上可能比实际设置的值要大,见下问题。所有严格来讲应该是大于两者的和的。

在实验的过程中遇见一个新问题

root@test11:07:21>insert into testb select * from testb limit 400;

# at 331
#190130 11:07:32 server id 21036055 end_log_pos 402 CRC32 0x62bb0a5e Rows_query
# insert into testb select * from testb limit 400
# at 402
#190130 11:07:32 server id 21036055 end_log_pos 451 CRC32 0x3177b22e Table_map: `test`.`testb` mapped to number 11496
# at 451
#190130 11:07:32 server id 21036055 end_log_pos 7286 CRC32 0x35efff16 Write_rows: table id 11496 flags: STMT_END_F

能正常插入证明内存中产生的binlog应该是小于4096的,但是实际在binlog中看见的确实7286,明显是比4094大的,为啥会这样呢,在从内存中把binlog落盘的过程中做了什么处理吗?

root@test11:21:01>show create table testb\G
*************************** 1. row ***************************
       Table: testb
Create Table: CREATE TABLE `testb` (
  `a` bigint(20) DEFAULT NULL,
  `b` bigint(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.00 sec)

[email protected]:24:10>select version();
+---------------+
| version() |
+---------------+
| 5.7.21-21-log |
+---------------+
1 row in set (0.00 sec)

 以上是表结构以及MySQL的版本

如有任何问题,欢迎指正。

参考文献:

https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_max_binlog_size

原文地址:https://www.cnblogs.com/Alpes/p/10337346.html

时间: 2024-10-18 10:32:42

为什么有时候binlog文件会很大于max_binlog_size以及max_binlog_cache_size的相关文章

如何生成一个 WinCE 下文件全路径大于 MAX_PATH(260) 字节的文件路径?

大家都知道,在 Windows 系统中文件名的路径最大值是 MAX_PATH.例如:Windows XP 系统,对文件名的长度进行测试: (1) 在分区 E:\ 的根目录新建一个文件,其文件名最大长度为: 255.---全路径长度>>> 258(2) 在分区 E:\ 子目录 Program Files\ 中新建一个文件,其文件名的最大长度为: 242. ---全路径长度>>>259在 WinCE 系统下,也有一定的限制.另外,如果试图将在 E:\ 根目录新建的最大文件名

查看binlog文件的2种方式

1.使用show binlog events a.获取binlog文件列表 mysql> show binary logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000005 | 1288 | | mysql-bin.000006 | 120 | +------------------+-----------+ mysql>

Python 查找binlog文件

经常需要在 binlog 中查找一些日志信息,于是写了一个简单的脚本.对于非常巨大的 binlog 文件,该脚本可能会速度慢,毕竟还是用的 list,暂时没想到好办法. 详细看代码: #/usr/bin/python #2016-04-12 #search string in the binlogs #usage: #put this file into binlog-dir,exec as: #"python test.py 111 123 update" or #"pyt

文件搜索(很实用)

搜索文件名 首先介绍一下软件吧 光速搜索,有绿色版,很小巧.NTFS格式的磁盘,秒搜,搜索文件名,支持模糊搜索.(第一次打开需要创建索引,需要3.4秒) 看图: 搜索说明的文件 文件太多,可以搜索 说明.txt ,    知道后缀. D:\  说明.txt    知道那个盘 D:\*         *.txt          *.pdf        *表示统配符 还有很多需要自己摸索一下. 搜索文本.Word内容 可是光速搜索只能搜文件名,介绍一下windows自带的,可以搜索 文本内部内

mysql5.5 物理删除binlog文件导致的故障

故障现象: 中午12点多,一套主从集群的主库因为没有配置大页内存,发布时导致OOM,MYSQL实例重启了,然后MHA发生了切换.切换过程正常.切换后需要把原master配置成新master的slave,在manager.log文件里面找到change master to ....命令,执行后发现复制状态一直停留在connectiong .名称定:OOM的是M1,挂掉后顶替的是S1. mysql> show slave status\G *************************** 1.

mysql 删除多余的bin-log文件

今天上班发现zabbix报警,打开报警页面看了下,说的是服务器的/分区低于20%. ssh到服务器上,查看结果发现是mysql的bin-log文件导致使用率低于20% mysql> system ls -lh total 8.5G -rw-rw---- 1 mysql mysql 1.6G May 21 10:09 ibdata1 -rw-rw---- 1 mysql mysql 5.0M May 21 10:09 ib_logfile0 -rw-rw---- 1 mysql mysql 5.0

Linux 如何用命令查看binlog文件的创建时间

目录 背景 分析 方法 注意 背景 MySQL在26日 16:23:49产生了大量的慢查询,在这段时间内,binlog文件刷新的很快(查看慢日志是mysql DML并发比较多),想知道写完一个binlog文件究竟花了几分钟时间? 分析 三个binlog文件的最后修改间隔时间分别是2 分钟和1 分钟 同一个事务只能写同一个binlog文件 mysql-bin.016126文件的最后修改时间16:22不一定是mysql-bin.016127 文件创建的时间(存在大事务的情况下,大事务还在写上一个bi

查看mysql二进制文件(binlog文件)

1.获取binlog文件列表 mysql> show binary logs;  2.查看当前正在写入的binlog文件 mysql>show master status: 3.查看指定binlog文件的内容 mysql>show binlog events [in 'log_name'] [FROM pos] [limit [offset,] row_count] 使用mysqlbinlog查看binlog 1.输出指定binlog文件内容 mysqlbinlog binlog文件 2

为什么单个binlog会大于max_binlog_size设置

查看参数设置mysql> show global variables like '%max_binlog_size%';+-----------------+------------+| Variable_name   | Value      |+-----------------+------------+| max_binlog_size | 1073741824 |+-----------------+------------+ 1 row in set (0.00 sec) 查看产生的