为何Binlog中同一个事务的event时间点会乱序？

最新推荐文章于 2023-07-27 11:29:03 发布
最新推荐文章于 2023-07-27 11:29:03 发布
阅读量1k 收藏
点赞数

导 读

作者：罗小波·沃趣科技高级数据库技术专家

IT从业多年，历任运维工程师、高级运维工程师、运维经理、数据库工程师，曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，追求完美。

这个问题，很久以前，笔者只是大概知道其中的原理，知道它就是长这样的，但并没有做过具体的案例分析。

直到最近，有某客户问起这个问题的时候，才发觉空口无凭讲不太清楚，遂现场给客户演示了一番才松了口气，也顺便把演示过程记录了下来，整理成文，下面，请跟随我们一起来一探究竟吧！

一、服务器环境

1、操作系统版本：CentOS release 6.5 (Final)

2、MySQL 版本：Oracle MySQL 5.7.20

3、MySQL 关键参数：innodb_flush_log_at_trx_commit=1; sync_binlog=1; binlog_format=row; gtid_mode=on; enforce_gtid_consistency=on

4、验证所需数据：sysbench压测之后遗留的测试数据（可自行造数，只需要一张表中有一条数据即可）

二、验证准备

登录到数据库中，手动滚动一下binlog文件

 
 
  1. root@localhost : sbtest 03:27:34> flush binary logs;select now();
  2. Query OK, 0 rows affected (0.01 sec)
  4. +---------------------+
  5. | now() |
  6. +---------------------+
  7. | 2018-10-04 15:31:55 |  # 滚动binlog的时间点为2018-10-04 15:31:55
  8. +---------------------+
  9. 1 row in set (0.00 sec)
 
 
解析一下最新的Binlog文件中的内容及其对应的时间点信息
 
 
 
 
  1. [root@localhost binlog]# mysqlbinlog -vv mysql-bin.000460 
  2. mysqlbinlog: [Warning] unknown variable 'loose_default-character-set=utf8'
  3. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
  4. /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
  5. DELIMITER /*!*/;
  6. # at 4
  7. #181004 15:31:55 server id 3306111 end_log_pos 123 CRC32 0x9cc61928 Start: binlog v 4, server v 5.7.20-log created 181004 15:31:55
  8. # Warning: this binlog is either in use or was not closed properly.
  9. BINLOG '
  10. 68G1Ww9/cjIAdwAAAHsAAAABAAQANS43LjIwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  11. AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
  12. ASgZxpw=
  13. '/*!*/;
  14. # at 123
  15. #181004 15:31:55 server id 3306111 end_log_pos 194 CRC32 0xc34422d7 Previous-GTIDs
  16. # ec123678-5e26-11e7-9d38-000c295e08a0:182318-199336
  17. SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
  18. DELIMITER ;
  19. # End of log file
  20. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
  21. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
 
 
从上述binlog的解析内容来看，当前最新的binlog中，除了文件头的event之外，并没有其他用户数据产生的event数据，且文件头的所有event的时间点都为2018-10-04 15:31:55，这个时间点也是在数据库中手动执行binlog滚动语句的时间点，也就是说：binlog文件头的event是在binlog滚动时就已经产生且写入到了最新的binlog中，且这些event与用户数据无关。
 
 
三、验证过程
 
 
接下来我们模拟用户对数据执行update操作，且为了验证需要，我们使用了显式事务，且在事务执行过程中人为加入了停顿，以便更清晰地看到binlog中的event是如何记录的。
 
 
首先，登录到数据库中，显式开启一个事务。
 
 
 
 
  1. # 查询测试数据，以便后续编写update语句
  2. root@localhost : sbtest 03:31:55> select * from sbtest1 limit 1;
  3. +----+---------+-------------------------------------------------------------------------------------------------------------------------+-----+
  4. | id | k | c | pad |
  5. +----+---------+-------------------------------------------------------------------------------------------------------------------------+-----+
  6. | 21 | 2483477 | 09279210219-37745839908-56185699327-79477158641-86711242956-61449540392-42622804506-61031512845-36718422840-11028803849 | xxx |
  7. +----+---------+-------------------------------------------------------------------------------------------------------------------------+-----+
  8. 1 row in set (0.00 sec)
  10. # 显式开启一个事务
  11. root@localhost : sbtest 03:32:17> begin;select now();
  12. Query OK, 0 rows affected (0.00 sec)
  14. +---------------------+
  15. | now() |
  16. +---------------------+
  17. | 2018-10-04 15:33:02|  # begin语句时间点为 2018-10-04 15:33:02
  18. +---------------------+
  19. 1 row in set (0.00 sec)
 
 
这个时候，binlog中还未记录新事务的binlog日志，等待几十秒之后，再在数据库中执行update语句修改k列值（这里是单行修改，且sbtest1表的id列为主键，所以update语句执行时间在这里是极小的，可以忽略不计）
 
 
 
 
  1. root@localhost : sbtest 03:33:02> update sbtest1 set k=k+1 where id=21;select now();
  2. Query OK, 1 row affected (0.00 sec)
  3. Rows matched: 1 Changed: 1 Warnings: 0
  5. +---------------------+
  6. | now() |
  7. +---------------------+
  8. | 2018-10-04 15:35:21 |  # update语句执行的时间点为 2018-10-04 15:35:21
  9. +---------------------+
  10. 1 row in set (0.00 sec)
 
 
这个时候，binlog中仍然还未记录新事务的binlog日志（因为事务并没有提交，binlog只会在事务提交时才会写入binlog文件中），现在，我们对该显式事务执行commit语句提交事务。
 
 
 
 
  1. root@localhost : sbtest 03:35:21> commit;select now();
  2. Query OK, 0 rows affected (0.01 sec)
  4. +---------------------+
  5. | now() |
  6. +---------------------+
  7. | 2018-10-04 15:36:42 | # commit语句执行的时间点为 2018-10-04 15:36:42
  8. +---------------------+
  9. 1 row in set (0.00 sec)
 
 
 
 
现在，我们解析最新的binlog文件，查看此时binlog中是如何记录该事务产生的event数据的（注意：binlog 中每个event的时间点信息是在生成event的时候产生的），为了方便大家阅读，后续内容将对binlog做分段说明。
 
 
（1）解析binlog
 
 
 
 
  1. [root@localhost binlog]# mysqlbinlog -vv mysql-bin.000460 
  2. ......
 
 
（2）以下内容为binlog文件头，event 时间点为手工滚动binlog的时间点2018-10-04 15:31:55，这里并未有任何变化。
 
 
 
 
  1. mysqlbinlog: [Warning] unknown variable 'loose_default-character-set=utf8'
  2. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
  3. /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
  4. DELIMITER /*!*/;
  5. # at 4
  6. #181004 15:31:55 server id 3306111 end_log_pos 123 CRC32 0x9cc61928 Start: binlog v 4, server v 5.7.20-log created 181004 15:31:55
  7. # Warning: this binlog is either in use or was not closed properly.
  8. BINLOG '
  9. 68G1Ww9/cjIAdwAAAHsAAAABAAQANS43LjIwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  10. AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
  11. ASgZxpw=
  12. '/*!*/;
  13. # at 123
  14. #181004 15:31:55 server id 3306111 end_log_pos 194 CRC32 0xc34422d7 Previous-GTIDs
  15. # ec123678-5e26-11e7-9d38-000c295e08a0:182318-199336
 
 
（3) at 194 position，事务的第一个event，也就是用于记录事务的GTID的event，时间点为15:36:42，通过我们事务操作时记录的时间信息，该时间为执行commit语句的时间点15:36:42。
 
 
 
 
  1. # at 194
  2. #181004 15:36:42 server id 3306111 end_log_pos 259 CRC32 0x7971213c GTID last_committed=0   sequence_number=1   rbr_only=yes
  3. /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
  4. SET @@SESSION.GTID_NEXT= 'ec123678-5e26-11e7-9d38-000c295e08a0:199337'/*!*/;
 
 
（4) at 259 position，事务的第二个event，也就是用于记录事务的begin;语句的event，时间点为15:35:21，通过我们事务操作时记录的时间信息，该时间为执行update语句的时间点 15:35:21，并不是执行begin;语句的时间点15:33:02，说明该event是在执行update语句时产生，并不是在执行begin;语句时产生的。
 
 
 
 
  1. #181004 15:35:21 server id 3306111 end_log_pos 338 CRC32 0x4d3af767 Query thread_id=3   exec_time=0 error_code=0
  2. SET TIMESTAMP=1538638521/*!*/;
  3. SET @@session.pseudo_thread_id=3/*!*/;
  4. SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
  5. SET @@session.sql_mode=1436549152/*!*/;
  6. SET @@session.auto_increment_increment=2, @@session.auto_increment_offset=1/*!*/;
  7. /*!\C utf8 *//*!*/;
  8. SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=83/*!*/;
  9. SET @@session.lc_time_names=0/*!*/;
  10. SET @@session.collation_database=DEFAULT/*!*/;
  11. BEGIN
  12. /*!*/;
 
 
（5）at 338 position，事务的第三个event，用于记录事务执行的原始SQL语句(需要启用参数：binlog_rows_query_log_events=ON)，时间点仍然是执行update语句的时间点(15:35:21)，说明该event也是在执行update语句时产生。
 
 
 
 
  1. # at 338
  2. #181004 15:35:21 server id 3306111 end_log_pos 398 CRC32 0x066200c5 Rows_query
  3. # update sbtest1 set k=k+1 where id=21
 
 
（6）at 398 position，事务的第四个event，用于记录事务对应的操作表在内存中的映射ID，时间点仍然是执行update语句的时间点(15:35:21)，说明该event也是在执行update语句时产生。
 
 
 
 
  1. # at 398
  2. #181004 15:35:21 server id 3306111 end_log_pos 457 CRC32 0x020d3fcf Table_map: `sbtest`.`sbtest1` mapped to number 143
 
 
（7) at 457 position，事务的第五个event，用于记录事务的完整操作语句和数据记录，也就是真正在执行update语句做数据修改（时间点仍然是 15:35:21），说明该event也是在执行update语句时产生。
 
 
 
 
  1. # at 457
  2. #181004 15:35:21 server id 3306111 end_log_pos 761 CRC32 0xdcfd94ba Update_rows: table id 143 flags: STMT_END_F
  4. BINLOG '
  5. ucK1Wx1/cjIAPAAAAI4BAACAACR1cGRhdGUgc2J0ZXN0MSBzZXQgaz1rKzEgd2hlcmUgaWQ9MjHF
  6. AGIG
  7. ucK1WxN/cjIAOwAAAMkBAAAAAI8AAAAAAAEABnNidGVzdAAHc2J0ZXN0MQAEAwP+/gTuaP60AM8/
  8. DQI=
  9. ucK1Wx9/cjIAMAEAAPkCAAAAAI8AAAAAAAEAAgAE///wFQAAABXlJQB3ADA5Mjc5MjEwMjE5LTM3
  10. NzQ1ODM5OTA4LTU2MTg1Njk5MzI3LTc5NDc3MTU4NjQxLTg2NzExMjQyOTU2LTYxNDQ5NTQwMzky
  11. LTQyNjIyODA0NTA2LTYxMDMxNTEyODQ1LTM2NzE4NDIyODQwLTExMDI4ODAzODQ5A3h4ePAVAAAA
  12. FuUlAHcAMDkyNzkyMTAyMTktMzc3NDU4Mzk5MDgtNTYxODU2OTkzMjctNzk0NzcxNTg2NDEtODY3
  13. MTEyNDI5NTYtNjE0NDk1NDAzOTItNDI2MjI4MDQ1MDYtNjEwMzE1MTI4NDUtMzY3MTg0MjI4NDAt
  14. MTEwMjg4MDM4NDkDeHh4upT93A==
  15. '/*!*/;
  16. ### UPDATE `sbtest`.`sbtest1`
  17. ### WHERE
  18. ### @1=21 /* INT meta=0 nullable=0 is_null=0 */
  19. ### @2=2483477 /* INT meta=0 nullable=0 is_null=0 */
  20. ### @3='09279210219-37745839908-56185699327-79477158641-86711242956-61449540392-42622804506-61031512845-36718422840-11028803849' /* STRING(360) meta=61032 nullable=0 is_null=0 */
  21. ### @4='xxx' /* STRING(180) meta=65204 nullable=0 is_null=0 */
  22. ### SET
  23. ### @1=21 /* INT meta=0 nullable=0 is_null=0 */
  24. ### @2=2483478 /* INT meta=0 nullable=0 is_null=0 */
  25. ### @3='09279210219-37745839908-56185699327-79477158641-86711242956-61449540392-42622804506-61031512845-36718422840-11028803849' /* STRING(360) meta=61032 nullable=0 is_null=0 */
  26. ### @4='xxx' /* STRING(180) meta=65204 nullable=0 is_null=0 */
 
 
（8）at 761 position，事务的第六个event，用于记录事务的commit语句，时间点为15:36:42，通过我们事务操作时记录的时间信息，该时间为执行commit语句的时间点15:36:42，说明该event是在执行commit语句时产生的。
 
 
 
 
  1. # at 761
  2. #181004 15:36:42 server id 3306111 end_log_pos 792 CRC32 0x3ad66423 Xid = 30
  3. COMMIT/*!*/;
  4. SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
  5. DELIMITER ;
  6. # End of log file
  7. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
  8. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
 
 
综上所述，在上述binlog解析内容中，用户事务的event有GTID(记录事务GTID)、Query（记录事务begin;语句）、Rows_query(在row格式下记录事务原始SQL语句)、Table_map（记录事务操作表在内存中的映射ID）、Update_rows（记录事务真正操作的语句和修改的具体数据记录）、xid（记录事务commit；语句）几种类型，其中：
 
 
（1）GTID和xid类型的event是在事务执行commit语句时产生的
 
 
（2）Query、Rows_query、Table_map、Update_rows 类型的event是在事务执行update 语句时产生的
 
 
（3）执行begin;语句时未产生任何event
 
 
本案例分析到此结束，留一个思考题给大家吧(大家可以依样画葫芦)。如果是主从架构，那么：
 
 
（1）从库的relay log中的event时间点会不会与主库binlog中记录的相同事务（这里指GTID相同）event时间点不同？
 
 
（2）从库如果启用了log_slave_updates=ON参数，从库自身的binlog中记录的复制事务的event会不会与主库binlog中记录的相同事务（这里指GTID相同） event时间点不同？
 
 
（3）如果主库存在并发事务，那么主库的binlog中记录的event时间点又是怎样的呢？
 
 

 
 
640.gif?
 
 

 
 
加入知数堂
 
 
挑战40万+年薪！
 
 

 
 

 
 
640?640?640?640?
 
 

 
 
知数堂
 
 
叶金荣与吴炳锡联合打造
 
 
领跑IT精英培训
 
 
行业资深专家强强联合，倾心定制
 
 
MySQL实战/MySQL优化/MongoDB/
 
 
Python/ SQL优化/Hadoop+ELK
 
 
数门精品课程
 
 
“阅读原文”可获更多正课试听视频
 
 
密码：hg3h
 
 
紧随技术发展趋势，定期优化培训教案
 
 
融入大量生产案例，贴合企业一线需求
 
 
社群陪伴学习，一次报名，可学1年
 
 
DBA、开发工程师必修课
 
 
上千位学员已华丽转身，薪资翻番，职位提升
 
 
改变已悄然发生，你还在等什么？
 
 
640.png?
 
 

 
 

 
 640?wx_fmt=gif 
 扫码加入QQ技术交流群 
 
MySQL 8.0|MGR研究院-ZST
 
 
（QQ群号：650149401）    
 
 
640?wx_fmt=jpeg
 
 

 


                

        

        

    

  


    

      

        

            

              
                
                  老叶茶馆_
                
              
            

            

                关注
              
            

        

        

          
      

      









                



	

		

			

				
					
mysql  binlog 保存日志顺序

				
			

			

				

					敖尔其楞的专栏
				

				

					01-10
					
					2269
					
				

			

		

		

			
				
先测试下mysql的



session1:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into bai values(1,'a',10);
Query OK, 1 row affected (0.00 sec)
不提交，开始等待会话2提交
mysql> commit;
Query OK, 0 rows

			
		

	



                

              
                



	

		

			

				
					
mysql binlog 时间 set_MySQL数据库binlog记录的时间戳失序的原因

				
			

			

				

					weixin_34582773的博客
				

				

					01-19
					
					543
					
				

			

		

		

			
				
MySQL数据库操作中，在做mysql binlog解析的时候，发现dump出来的数据出现严重的失序情况，时差差不多为1s，如下所示：SETTIMESTAMPE=1SETTIMESTAMPE=0SETTIMESTAMPE=1……在写binlog头时：log_event.ccLog_event::write_headernow=(ulong)get_time();//querysta...

			
		

	



                


  
              

                


	

		

			

				
					
解决 MySQL binlog 同步时出现的乱序

					
最新发布

				
			

			

				

					npk191954的专栏
				

				

					07-27
					
					758
					
				

			

		

		

			
				
要实现将MySQL的binlog日志发送到RocketMQ，可以使用Canal作为中间件来监听MySQL的binlog，并将监听到的数据发送到RocketMQ。1. 安装Canal：首先，需要在服务器上安装Canal。可以从Canal的官方网站下载并安装Canal Server。2. 配置Canal：在Canal Server的配置文件（conf/canal.properties）中，配置MySQL的连接信息，包括MySQL的地址、端口、用户名和密码。3. 配置RocketMQ：在Canal Server的

			
		

	





	

		

			

				
					
Flink之数据乱序处理

				
			

			

				

					datacreating的博客
				

				

					03-14
					
					2721
					
				

			

		

		

			
				
理想情况下，数据都是严格有序的，但现实中的数据往往都存在乱序的情况。

			
		

	



		

			
		



	

		

			

				
					
mysql一个事务多个log_MySQL识别一个binlog中的一个事物

				
			

			

				

					weixin_28851659的博客
				

				

					01-20
					
					433
					
				

			

		

		

			
				
MySQL测试版本5.7.14设置GTID_MODE=ONON(3): Both new and replicated transactions must be GTID transactions(生成的是GTID事物，slave也只能应用GTID事物)设置binlog格式为row模式做如下操作mysql> insert into test values(1,2);Query OK, 1 r...

			
		

	





	

		

			

				
					
mysql binlog events_MySQL binlog event 详解

				
			

			

				

					weixin_39768247的博客
				

				

					01-19
					
					613
					
				

			

		

		

			
				
我也是只菜鸡，blog写的不对或者不严谨的地方还请大伙指出来，我及时改正，免得误人子弟。实验环境：CentOS7.3.1611 + MySQL社区版 5.7.19参考：小菜鸟DBA的微信公众号推送官方文档：3个在线工具：binlog实际上由一个个不同类型的binlog event组成，每个binlog event还包含了event header部分和event data部分(可选)。【注意：每个e...

			
		

	





	

		

			

				
					
MySQL深入-binlog日志及事务日志

				
			

			

				

					ljxbbss的博客
				

				

					08-09
					
					6752
					
				

			

		

		

			
				
1.什么是binlog？
	binlog是一个二进制格式的文件，用于记录用户对数据库更新的SQL语句信息，例如更改数据库表和更改内容的SQL语句都会记录到binlog里，但是对库表等内容的查询不会记录。 - 触发变更的操作，增删改都算；
		二进制格式的，所以无法使用cat或者vi等去查看，需要使用mysqlbinlog去查看
	
	2.binlog干吗使？
	主从复制；
		数据库宕机时候用...

			
		

	





	

		

			

				
					
Linux下查看binlog文件创建时间的命令

				
			

			

				

					09-15
				

			

		

		

			
				
 `debugfs`是Linux内核提供的一个实用程序，用于直接操作文件系统的inode。要获取binlog文件的创建时间，首先需要找到文件的inode号，然后使用`debugfs`的`stat`命令。例如：  ```  ls -i mysql-bin.016127  ```  这...

			
		

	





	

		

			

				
					
mysql里主从同步时如果出现事务的乱序问题解决方案

				
			

			

				

					浪淘沙的专栏
				

				

					07-22
					
					494
					
				

			

		

		

			
				
是MySQL在5.7.17版本中推出的一种新的数据复制技术，这种复制技术是基于paxos协议的状态机复制，多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层（Consensus）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应Node节点）的同意，大多数指的是同意的节点数量要大于N/2+1，这样才可以进行提交，而不是一方说了算。如果将这个参数调大，可以提升数据一致性的强度，但也会增加主库等待从库响应的时间。所以，这种复制模式下的数据一致性是最弱的。...

			
		

	





	

		

			

				
					
binlog关闭事务记录_BinLog日志

				
			

			

				

					weixin_42255222的博客
				

				

					01-26
					
					363
					
				

			

		

		

			
				
一、概述binlog 二进制日志文件,可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。DDL----Data Definition Language 数据库定义语言主要的命令有CREATE、ALTER、DROP等，DDL主要是用在定义或改变表(TABLE)的结构，数据类型，表...

			
		

	





	

		

			

				
					
MySQL中Redo 和 Binlog 顺序一致性问题！！！

				
			

			

				

					LYK_for_dba的博客
				

				

					03-15
					
					4384
					
				

			

		

		

			
				
首先，我们知道在MySQL中，二进制日志是server层的，主要用来做主从复制和即时点恢复时使用的。而事务日志（redo log）是InnoDB存储引擎层的，用来保证事务安全的。现在我们来讨论一下MySQL主从复制过程中的一些细节问题，有关于主从复制可以看具体的章节。在了解了以上基础的内容后，我们可以带着以下的几个问题去学习复制到底是怎样工作的。为什么MySQL有binlog，还有redo log...

			
		

	





	

		

			

				
					
mysql gtid binlog_MySQL binlog中at position、gtid、sequence_number、last_committed、xid的区别...

				
			

			

				

					weixin_39693437的博客
				

				

					02-17
					
					1181
					
				

			

		

		

			
				
MySQL binlog中的点如此之多,很容易让人疑惑:有人误解binlog里的at position  的每个position代表一个事务、有人误解组提交的一组事务gtid都相同...下面是个人整理的binlog中各个点的用途:1.at position用mysqlbinlog解析出来的binlog很容易看到如下内容:# at 259#161028 16:56:20 server id 1591...

			
		

	





	

		

			

				
					
MySQL binlog时间异常分析

				
			

			

				

					m0_73257876的博客
				

				

					08-24
					
					864
					
				

			

		

		

			
				
本文简单介绍了binlog中时间的来源，解释了binlog中时间不一定有序的原因，感兴趣的读者可以自行学习binlog相关的代码。腾讯数据库研发部数据库技术团队对内支持微信支付、微信红包、腾讯广告、腾讯音乐等公司自研业务，对外在腾讯云上支持 TencentDB 相关产品，如 CynosDB、CDB、TDSQL等。本公众号旨在推广和分享数据库领域专业知识，与广大数据库技术爱好者共同成长。

			
		

	





	

		

			

				
					
mysql binlog详细介绍

				
			

			

				

					weixin_40524659的博客
				

				

					04-17
					
					1346
					
				

			

		

		

			
				
MySQL binlog记录的所有操作实际上都有对应的事件类型的，STATEMENT格式中的DML操作对应的是QUERY_EVENT类型，ROW格式下的DML操作对应的是ROWS_EVENT类型。



下面就挑几个重点的说一下：



QUERY_EVENT

QUERY_EVENT以文本的形式来记录事务的操作。

QUERY_EVENT类型的事件通常在以下几种情况下使用：

1. 事务开始...

			
		

	





	

		

			

				
					
简明的binlog event解析

				
			

			

				

					GreatSQL2021的博客
				

				

					10-26
					
					353
					
				

			

		

		

			
				
GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。

用一个简明、清晰的步骤来解析一下DML操作产生的binlog event。主要是 TABLE_MAP_EVENT 和 UPDATE_ROWS_EVENT 类型的event。使用语法简单易上手的Golang来编码。数据库使用的是MySQL 5.7.34版本， Golang 1.15版本。
获取binlog event
获取binlog一般是模拟成从库封装通讯 

			
		

	





	

		

			

				
					
简明binlog event解析

				
			

			

				

					老叶茶馆
				

				

					12-06
					
					754
					
				

			

		

		

			
				
用一个简明、清晰的步骤来解析一下DML操作产生的binlog event。主要是 TABLE_MAP_EVENT 和 UPDATE_ROWS_EVENT 类型的event。使用语法简单易上手的Golang来编码。数据库使用的是MySQL 5.7.34版本， Golang 1.15版本。获取binlog event获取binlog一般是模拟成从库封装通讯 package 向主库发送binlog du...

			
		

	





	

		

			

				
					
MySQL binlog event 详解

				
			

			

				

					weixin_33940102的博客
				

				

					11-21
					
					2165
					
				

			

		

		

			
				
我也是只菜鸡，blog写的不对或者不严谨的地方还请大伙指出来，我及时改正，免得误人子弟。

实验环境：
CentOS7.3.1611 + MySQL社区版 5.7.19
参考：
  小菜鸟DBA的微信公众号推送

官方文档：
https://dev.mysql.com/doc/internals/en/binary-log-versions.htm...

			
		

	





	

		

			

				
					
为什么binlog没有达到上限就切换了？

				
			

			

				

					06-09
				

			

		

		

			
				
Binlog是MySQL中的二进制日志，用于记录数据库的修改操作。当Binlog达到设定的上限时，MySQL会自动切换到下一个Binlog文件进行记录。这是因为Binlog文件的大小是可以配置的，一旦达到设定的大小，MySQL就会自动切换到下一个Binlog文件，以便继续记录数据库的修改操作。这样可以保证Binlog文件不至于过大，同时也有利于后续的备份和恢复操作。

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值