Mysql主從複製—binlog二進制日誌 解析

 

 

參考：官方文檔(binlog中的event 結構)：https://dev.mysql.com/doc/internals/en/event-structure.html

           binlog解析：http://blog.itpub.net/7728585/search/%E8%A7%A3%E6%9E%90mysql/

 

 

 

 

實驗目的：通過一個delete語句， 來解析生成的binlog二進制日誌， 分析產生的每一個event事件的信息。

版本信息： mysql5.7  、 gtid開啓 、 row模式

 

 

 

 

--0、測試表的表結構及數據

mysql>  show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
1 row in set (0.00 sec)




mysql> select * from t1 limit 2;
+----+------+------+
| id | a    | b    |
+----+------+------+
|  1 | 1000 |    1 |
|  2 |  999 |    2 |
+----+------+------+
2 rows in set (0.12 sec)

 

 

 

 

 

--1、執行的sql語句   說明：sql語句前後使用flush logs; 使得生成的mysql-bin.000041日誌只有一條sql

mysql> flush logs;

mysql> delete from t1 where id=2;
Query OK, 1 row affected (0.00 sec)

mysql> flush logs;

 

 

 

 

 

 

--2、查看binlog的每個event事件  (其中 一個事務是從gtid事件到xid事件)

mysql> show binlog events in 'mysql-bin.000041';
+------------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                                    |
+------------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| mysql-bin.000041 |   4 | Format_desc    |       222 |         123 | Server ver: 5.7.27-log, Binlog ver: 4                                   |    //第一個event事件
| mysql-bin.000041 | 123 | Previous_gtids |       222 |         194 | f7b23f20-f3ea-11e9-bdb9-080027781379:1183166                            |    //第二個event事件
| mysql-bin.000041 | 194 | Gtid           |       222 |         259 | SET @@SESSION.GTID_NEXT= 'f7b23f20-f3ea-11e9-bdb9-080027781379:1183167' |    //第三個event事件
| mysql-bin.000041 | 259 | Query          |       222 |         332 | BEGIN                                                                   |    //第四個event事件
| mysql-bin.000041 | 332 | Rows_query     |       222 |         381 | # delete from t1 where id=2                                             |    //第五個event事件
| mysql-bin.000041 | 381 | Table_map      |       222 |         429 | table_id: 109 (flydb.t1)                                                |    //第六個event事件
| mysql-bin.000041 | 429 | Delete_rows    |       222 |         477 | table_id: 109 flags: STMT_END_F                                         |    //第七個event事件
| mysql-bin.000041 | 477 | Xid            |       222 |         508 | COMMIT /* xid=39 */                                                     |    //第八個event事件
| mysql-bin.000041 | 508 | Rotate         |       222 |         555 | mysql-bin.000042;pos=4                                                  |    //第九個event事件
+------------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
9 rows in set (0.24 sec)

 

 

 

--3、解析binlog二進制文件

--binlog二進制文件
[root@hostmysql80 mysql]# hexdump -C  mysql-bin.000041
00000000  fe 62 69 6e 6f c7 e9 5d  0f de 00 00 00 77 00 00  |.bino..].....w..|
00000010  00 7b 00 00 00 00 00 04  00 35 2e 37 2e 32 37 2d  |.{.......5.7.27-|
00000020  6c 6f 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |log.............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 13  |................|
00000050  38 0d 00 08 00 12 00 04  04 04 04 12 00 00 5f 00  |8............._.|
00000060  04 1a 08 00 00 00 08 08  08 02 00 00 00 0a 0a 0a  |................|
00000070  2a 2a 00 12 34 00 01 03  91 8e f3 6f c7 e9 5d 23  |**..4......o..]#|
00000080  de 00 00 00 47 00 00 00  c2 00 00 00 80 00 01 00  |....G...........|
00000090  00 00 00 00 00 00 f7 b2  3f 20 f3 ea 11 e9 bd b9  |........? ......|
000000a0  08 00 27 78 13 79 01 00  00 00 00 00 00 00 be 0d  |..'x.y..........|
000000b0  12 00 00 00 00 00 bf 0d  12 00 00 00 00 00 2e 6a  |...............j|
000000c0  9b b4 74 c7 e9 5d 21 de  00 00 00 41 00 00 00 03  |..t..]!....A....|
000000d0  01 00 00 00 00 00 f7 b2  3f 20 f3 ea 11 e9 bd b9  |........? ......|
000000e0  08 00 27 78 13 79 bf 0d  12 00 00 00 00 00 02 00  |..'x.y..........|
000000f0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 8b  |................|
00000100  63 18 cf 74 c7 e9 5d 02  de 00 00 00 49 00 00 00  |c..t..].....I...|
00000110  4c 01 00 00 08 00 07 00  00 00 00 00 00 00 05 00  |L...............|
00000120  00 1a 00 00 00 00 00 00  01 00 00 a0 55 00 00 00  |............U...|
00000130  00 06 03 73 74 64 04 21  00 21 00 53 00 66 6c 79  |...std.!.!.S.fly|
00000140  64 62 00 42 45 47 49 4e  81 46 d6 c5 74 c7 e9 5d  |db.BEGIN.F..t..]|
00000150  1d de 00 00 00 31 00 00  00 7d 01 00 00 80 00 19  |.....1...}......|
00000160  64 65 6c 65 74 65 20 66  72 6f 6d 20 74 31 20 77  |delete from t1 w|
00000170  68 65 72 65 20 69 64 3d  32 7b 0f 12 7b 74 c7 e9  |here id=2{..{t..|
00000180  5d 13 de 00 00 00 30 00  00 00 ad 01 00 00 00 00  |].....0.........|
00000190  6d 00 00 00 00 00 01 00  05 66 6c 79 64 62 00 02  |m........flydb..|
000001a0  74 31 00 03 03 03 03 00  06 43 7f c7 c4 74 c7 e9  |t1.......C...t..|
000001b0  5d 20 de 00 00 00 30 00  00 00 dd 01 00 00 00 00  |] ....0.........|
000001c0  6d 00 00 00 00 00 01 00  02 00 03 ff f8 02 00 00  |m...............|
000001d0  00 e7 03 00 00 02 00 00  00 92 db 84 85 74 c7 e9  |.............t..|
000001e0  5d 10 de 00 00 00 1f 00  00 00 fc 01 00 00 00 00  |]...............|
000001f0  27 00 00 00 00 00 00 00  ca 4b 6d 6a 76 c7 e9 5d  |'........Kmjv..]|
00000200  04 de 00 00 00 2f 00 00  00 2b 02 00 00 00 00 04  |...../...+......|
00000210  00 00 00 00 00 00 00 6d  79 73 71 6c 2d 62 69 6e  |.......mysql-bin|
00000220  2e 30 30 30 30 34 32 8d  46 93 00                 |.000042.F..|
0000022b

 

 

event事件結構如下： 參考官網：https://dev.mysql.com/doc/internals/en/event-header-fields.html

--v4 event structure:
+=====================================+
| event  | timestamp         0 : 4    |    //4字節，時間
| header +----------------------------+
|        | type_code         4 : 1    |    //1字節，log_event_type類型，枚舉詳見如下《附1、log_event_type枚舉》
|        +----------------------------+
|        | server_id         5 : 4    |    //4字節，是mysql的server_id。  和show variables like '%server%';查看一致
|        +----------------------------+
|        | event_length      9 : 4    |    //4字節，整個event的長度，包含固定和非固定長度
|        +----------------------------+
|        | next_position    13 : 4    |    //4字節，下一個event的開始位置
|        +----------------------------+
|        | flags            17 : 2    |    //2字節，詳見如下《附2、flags 標識》
|        +----------------------------+
|        | extra_headers    19 : x-19 |    //
+=====================================+
| event  | fixed part        x : y    |    //
| data   +----------------------------+
|        | variable part              |    //
+=====================================+




--3.1、：第一個event事件解析：FORMAT_DESCRIPTION_EVENT  ，用於描述mysql的基本信息。在binary log切換時候生成。
00000000  fe 62 69 6e 6f c7 e9 5d  0f de 00 00 00 77 00 00  |.bino..].....w..|    //每一個binlog文件都有4字節的魔法數，其值固定爲：fe 62 69 6e
00000010  00 7b 00 00 00 00 00 04  00 35 2e 37 2e 32 37 2d  |.{.......5.7.27-|
00000020  6c 6f 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |log.............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 13  |................|
00000050  38 0d 00 08 00 12 00 04  04 04 04 12 00 00 5f 00  |8............._.|
00000060  04 1a 08 00 00 00 08 08  08 02 00 00 00 0a 0a 0a  |................|
00000070  2a 2a 00 12 34 00 01 03  91 8e f3 6f c7 e9 5d 23  |**..4......o..]#|


--3.1.1、FORMAT_DESCRIPTION_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x6f c7 e9 5d                         小端顯示爲‭5DE9C76F‬，轉換爲十進制是‭1575602031‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602031'
                                                                                                                          Fri Dec  6 11:13:51 CST 2019
type_code            1      0x0f                                  轉換爲十進制是log_event_type爲15，是FORMAT_DESCRIPTION_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x77 00 00 00                         小端顯示爲00000077，轉換爲十進制是119。這個FORMAT_DESCRIPTION_EVENT的事件 從4開始(減去4字節魔法數)，加上119 ，下個事件爲123開始。
next_position        4      0x7b 00 00 00                         小端顯示爲0000007b，轉換爲十進制是123。下個事件從123開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.1.2、FORMAT_DESCRIPTION_EVENT的event data的部分解析如下： 參考官網：https://dev.mysql.com/doc/internals/en/format-description-event.html
Name                Size    16進制                                Remarks
binlog-version       2      0x04 00                               小端顯示爲0004，轉換爲十進制是4。 binlog是v4版本
mysql-server version 50     0x35 2e開始                           16進制轉字符爲：5.7.27-log。  mysql是5.7.27-log版本
create timestamp     4      0x00 00 00 00                         冗餘的timestamp，都是0x00
event_header_length  1      0x13                                  小端顯示爲13，轉換爲十進制是19。是Binlog Event Header的長度
event type header lengths  可變     0x38 0d開始                    顯示了所有event的header的長度。 具體參見官網如上。
CRC32                4      0x03 91 8e f3                         CRC32校驗位


--3.1.3、mysqlbinlog解析的 第一個event事件(4-123字節) 如下：
[root@hostmysql80 mysql]# mysqlbinlog -vv mysql-bin.000041
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#191206 11:13:51 server id 222  end_log_pos 123 CRC32 0xf38e9103        Start: binlog v 4, server v 5.7.27-log created 191206 11:13:51
BINLOG '
b8fpXQ/eAAAAdwAAAHsAAAAAAAQANS43LjI3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AQORjvM=
'/*!*/;
# at 123






--3.2、：第二個event事件解析：PREVIOUS_GTIDS_LOG_EVENT，用於記錄上一個binlog日誌的最後一個gtid，一個binlog中只有一個此event事件
00000070  2a 2a 00 12 34 00 01 03  91 8e f3 6f c7 e9 5d 23  |**..4......o..]#|
00000080  de 00 00 00 47 00 00 00  c2 00 00 00 80 00 01 00  |....G...........|
00000090  00 00 00 00 00 00 f7 b2  3f 20 f3 ea 11 e9 bd b9  |........? ......|
000000a0  08 00 27 78 13 79 01 00  00 00 00 00 00 00 be 0d  |..'x.y..........|
000000b0  12 00 00 00 00 00 bf 0d  12 00 00 00 00 00 2e 6a  |...............j|
000000c0  9b b4 74 c7 e9 5d 21 de  00 00 00 41 00 00 00 03  |..t..]!....A....|


--3.2.1、PREVIOUS_GTIDS_LOG_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x6f c7 e9 5d                         小端顯示爲‭5DE9C76F‬，轉換爲十進制是‭1575602031‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602031'
                                                                                                                          Fri Dec  6 11:13:51 CST 2019
type_code            1      0x23                                  轉換爲十進制是log_event_type爲35，是PREVIOUS_GTIDS_LOG_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x47 00 00 00                         小端顯示爲00000047，轉換爲十進制是71。這個PREVIOUS_GTIDS_LOG_EVENT的事件 從123開始，加上71 ，下個事件爲194開始。
next_position        4      0xc2 00 00 00                         小端顯示爲000000c2，轉換爲十進制是194。下個事件從194開始，和上面的可以對應上
flags                2      0x80 00                               詳見如下《附2、flags 標識》


--3.2.2、PREVIOUS_GTIDS_LOG_EVENT的event data的部分解析如下：
Name                Size    16進制                                Remarks
number of sids       8      0x01 00  00 00 00 00 00 00            小端顯示爲0000000000000001‬，轉換爲十進制是‭1。本Gtid set 有幾個server_uuid
gtid:uuid           16      0xf7 b2 3f ..到..  13 79              gtid:uuid 爲：f7b23f20-f3ea-11e9-bdb9-080027781379
n_intervals          8      0x01 00  00 00 00 00 00 00            小端顯示爲0000000000000001‬，轉換爲十進制是‭1。本server_uuid下的gtid set interval的個數。
gtid:current_gno     8      0xbe 0d 12 00 00 00 00 00             gtid:current_gno 上個binlog最後一次事務的gno 小端爲：0000000000120dbe，十進制爲‭1183166‬
gtid:next_gno        8      0xbf 0d 12 00 00 00 00 00             gtid:next_gno 本次事務的gno 小端爲：0000000000120dbf，十進制爲‭1183167‬
CRC32                4      0x2e 6a 9b b4                         CRC32校驗位


--3.2.3、mysqlbinlog解析的 第二個event事件(123-194字節) 如下：
# at 123
#191206 11:13:51 server id 222  end_log_pos 194 CRC32 0xb49b6a2e        Previous-GTIDs
# f7b23f20-f3ea-11e9-bdb9-080027781379:1183166
# at 194





--3.3、：第三個event事件解析：GTID_LOG_EVENT，用於本次事務的gtid信息的說明(也是事務的第一個事件)。但時間是事務提交的時間。
000000c0  9b b4 74 c7 e9 5d 21 de  00 00 00 41 00 00 00 03  |..t..]!....A....|
000000d0  01 00 00 00 00 00 f7 b2  3f 20 f3 ea 11 e9 bd b9  |........? ......|
000000e0  08 00 27 78 13 79 bf 0d  12 00 00 00 00 00 02 00  |..'x.y..........|
000000f0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 8b  |................|
00000100  63 18 cf 74 c7 e9 5d 02  de 00 00 00 49 00 00 00  |c..t..].....I...|


--3.3.1、GTID_LOG_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x21                                  轉換爲十進制是log_event_type爲33，是GTID_LOG_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x41 00 00 00                         小端顯示爲00000041，轉換爲十進制是65。這個GTID_LOG_EVENT的事件 從194開始，加上65 ，下個事件爲259開始。
next_position        4      0x03 01 00 00                         小端顯示爲00000103，轉換爲十進制是259。下個事件從259開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.3.2、GTID_LOG_EVENT的event data的部分解析如下：
Name                Size    16進制                                Remarks
flags                1      0x00                                  是否爲ROW模式，是則爲0x00，不是爲0x01。 DDL都不是ROW模式，而是statement模式(所以正常的binlog解析 無法閃回DDL操作)。
gtid:uuid           16      0xf7 b2 3f ..到..  13 79              gtid:uuid 爲：f7b23f20-f3ea-11e9-bdb9-080027781379
gtid:next_gno        8      0xbf 0d 12 00 00 00 00 00             gtid:next_gno 本次事務的gno 小端爲：0000000000120dbf，十進制爲‭1183167‬
                            0x02                                  todo...
last_committed       8      0x00 00 00 00 00 00 00 00             last_committed。小端顯示爲0000000000000000，轉換爲十進制是0。
sequence_number      8      0x01 00 00 00 00 00 00 00             sequence_number。小端顯示爲0000000000000001，轉換爲十進制是1。
CRC32                4      0x8b 63 18 cf                         CRC32校驗位


--3.3.3、mysqlbinlog解析的 第二個event事件(194-259字節) 如下：
# at 194
#191206 11:13:56 server id 222  end_log_pos 259 CRC32 0xcf18638b        GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'f7b23f20-f3ea-11e9-bdb9-080027781379:1183167'/*!*/;
# at 259







--3.4、：第四個event事件解析：QUERY_EVENT，用於記錄第一條語句的第一行數據的一些信息。
00000100  63 18 cf 74 c7 e9 5d 02  de 00 00 00 49 00 00 00  |c..t..].....I...|
00000110  4c 01 00 00 08 00 07 00  00 00 00 00 00 00 05 00  |L...............|
00000120  00 1a 00 00 00 00 00 00  01 00 00 a0 55 00 00 00  |............U...|
00000130  00 06 03 73 74 64 04 21  00 21 00 53 00 66 6c 79  |...std.!.!.S.fly|
00000140  64 62 00 42 45 47 49 4e  81 46 d6 c5 74 c7 e9 5d  |db.BEGIN.F..t..]|


--3.4.1、QUERY_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x02                                  轉換爲十進制是log_event_type爲21，是QUERY_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x49 00 00 00                         小端顯示爲00000049，轉換爲十進制是73。這個QUERY_EVENT的事件 從259開始，加上73 ，下個事件爲332開始。
next_position        4      0x4c 01 00 00                         小端顯示爲0000014c，轉換爲十進制是332。下個事件從332開始，和上面的可以對應上
flags                2      0x80 00                               詳見如下《附2、flags 標識》


--3.4.2、QUERY_EVENT的event data的部分解析如下： 參考官網：https://dev.mysql.com/doc/internals/en/query-event.html
Name                Size    16進制                                Remarks
slave_proxy_id       4      0x07 00  00 00                        小端顯示爲00000007‬，轉換爲十進制是‭7。就是thread_id ，爲了創建臨時表名不衝突 而設立的
execution time       4      0x00 00 00 00                         小端顯示爲00000000，轉換爲十進制是‭0。 執行時間是0秒。 對於DML不準確 是第一個語句執行後的時間  而可能會有很多要執行的語句。 對於DDL操作時準確的。
schema length        1      0x05                                  數據庫名字長度，爲5，flydb是5個字符長度
error-code           2      0x00 00                               錯誤代碼
status-vars length   2      0x1a 00                               小端顯示爲001a，轉換爲十進制是‭26。下面status-vars鍵值對的長度是26個字節
status-vars 鍵值對形式   (具體的鍵 - 值對 可參照下面的說明)。如下：
Q_FLAGS2_CODE       1+4     0x00    00 00 00 00                   小端顯示爲00000000，是foreign_key_checks，sql_auto_is_null，unique_checks，autocommit 四個參數的值。
Q_SQL_MODE_CODE     1+8     0x01    00 00 a0 55 00 00 00 00       小端顯示爲0000000055a00000，轉換爲十進制是‭1436549120‬。 爲sql_mode。
Q_CATALOG_NZ_CODE   1+4     0x06    03 73 74 64                   0x03位長度，0x737464 轉換爲字符時 std。 是catalog的字符集  todo...
Q_CHARSET_CODE      1+6     0x04    21 00 21 00 53 00             小端顯示爲0021，0021，,0053。轉換爲十進制是33,33‬，83。對應的字符集。
schema              可變    0x66 6c 79 64 62                      數據庫名字。 16進制轉字符爲flydb
[00]                 1      0x00                                  固定保留0x00
query               可變    0x42 45 47 49 4e                      16進制轉字符爲BEGIN
CRC32                4      0x81 46 d6 c5                         CRC32校驗位


--3.4.3、mysqlbinlog解析的 第四個event事件(259-332字節) 如下：
# at 259
#191206 11:13:56 server id 222  end_log_pos 332 CRC32 0xc5d64681        Query   thread_id=7     exec_time=0     error_code=0
SET TIMESTAMP=1575602036/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549120/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=83/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 332




--status_vars 鍵值對說明(此次binlog 只記錄了以下4個綠色flag， 其他沒記錄的flag就按照默認值來) 如下：
Flag      Value                           Length
0x00      Q_FLAGS2_CODE                   4
0x01      Q_SQL_MODE_CODE                 8
0x02      Q_CATALOG                       1 + n + 1
0x03      Q_AUTO_INCREMENT                2 + 2
0x04      Q_CHARSET_CODE                  2 + 2 + 2
0x05      Q_TIME_ZONE_CODE                1 + n
0x06      Q_CATALOG_NZ_CODE               1 + n
0x07      Q_LC_TIME_NAMES_CODE            2
0x08      Q_CHARSET_DATABASE_CODE         2
0x09      Q_TABLE_MAP_FOR_UPDATE_CODE     8
0x0a      Q_MASTER_DATA_WRITTEN_CODE      4
0x0b      Q_INVOKERS                      1 + n + 1 + n
0x0c      Q_UPDATED_DB_NAMES              1 + n*nul-term-string
0x0d      Q_MICROSECONDS                  3


Q_FLAGS2_CODE 小端顯示
Bitmask of flags that are usually set with SET:
* SQL_AUTO_IS_NULL
* FOREIGN_KEY_CHECKS
* UNIQUE_CHECKS
* AUTOCOMMIT
Hex           Flag
0x00004000    OPTION_AUTO_IS_NULL                 
0x00080000    OPTION_NOT_AUTOCOMMIT               
0x04000000    OPTION_NO_FOREIGN_KEY_CHECKS        
0x08000000    OPTION_RELAXED_UNIQUE_CHECKS        

--舉個例子：   binlog顯示Q_FLAGS2_CODE 爲 00 40 00 0c 的 小端顯示爲0x0c004000 ， 帶入這四個參數是否生效 如下：
                          就是：0x04000000(OPTION_NO_FOREIGN_KEY_CHECKS)+0x08000000(OPTION_RELAXED_UNIQUE_CHECKS)+0x00004000(OPTION_AUTO_IS_NULL) = 0x0c004000
和mysqlbinlog解析一致，如下：
SET @@session.foreign_key_checks=0, @@session.sql_auto_is_null=1, @@session.unique_checks=0, @@session.autocommit=1/*!*/;


Q_SQL_MODE_CODE  具體看官網吧：https://dev.mysql.com/doc/internals/en/query-event.html

Q_CATALOG_NZ_CODE
1-byte length + <length> chars of the catalog

Q_CHARSET_CODE
2-byte character_set_client + 2-byte collation_connection + 2-byte collation_server








--3.5、：第五個event事件解析：ROWS_QUERY_LOG_EVENT，記錄執行sql的完整語句(參數 binlog_rows_query_log_events 控制 是否會有此event。 默認 無)
00000140  64 62 00 42 45 47 49 4e  81 46 d6 c5 74 c7 e9 5d  |db.BEGIN.F..t..]|
00000150  1d de 00 00 00 31 00 00  00 7d 01 00 00 80 00 19  |.....1...}......|
00000160  64 65 6c 65 74 65 20 66  72 6f 6d 20 74 31 20 77  |delete from t1 w|
00000170  68 65 72 65 20 69 64 3d  32 7b 0f 12 7b 74 c7 e9  |here id=2{..{t..|

--3.5.1、ROWS_QUERY_LOG_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x1d                                  轉換爲十進制是log_event_type爲21，是ROWS_QUERY_LOG_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x31 00 00 00                         小端顯示爲00000031，轉換爲十進制是49。這個ROWS_QUERY_LOG_EVENT的事件 從332開始，加上49 ，下個事件爲381開始。
next_position        4      0x7d 01 00 00                         小端顯示爲0000017d，轉換爲十進制是381。下個事件從381開始，和上面的可以對應上
flags                2      0x80 00                               詳見如下《附2、flags 標識》

--3.5.2、ROWS_QUERY_LOG_EVENT的event data的部分解析如下：
Name                Size    16進制                                Remarks
sql                sql長度  0x19 64 65 6c.. 開始                  16進制轉字符爲： delete from t1 where id=2
CRC32                4      0x7b 0f 12 7b                         CRC32校驗位

--3.5.3、mysqlbinlog解析的 第五個event事件(332-381字節) 如下：
# at 332
#191206 11:13:56 server id 222  end_log_pos 381 CRC32 0x7b120f7b        Rows_query
# delete from t1 where id=2
# at 381




--3.6、：第六個event事件解析：TABLE_MAP_EVENT， 用於row模式複製，記錄的是要修改的表的基本信息
00000170  68 65 72 65 20 69 64 3d  32 7b 0f 12 7b 74 c7 e9  |here id=2{..{t..|
00000180  5d 13 de 00 00 00 30 00  00 00 ad 01 00 00 00 00  |].....0.........|
00000190  6d 00 00 00 00 00 01 00  05 66 6c 79 64 62 00 02  |m........flydb..|
000001a0  74 31 00 03 03 03 03 00  06 43 7f c7 c4 74 c7 e9  |t1.......C...t..|


--3.6.1、TABLE_MAP_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x13                                  轉換爲十進制是log_event_type爲19，是TABLE_MAP_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x30 00 00 00                         小端顯示爲00000030，轉換爲十進制是48。這個TABLE_MAP_EVENT的事件 從381開始，加上48 ，下個事件爲429開始。
next_position        4      0xad 01 00 00                         小端顯示爲000001ad，轉換爲十進制是429。下個事件從429開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.6.2、TABLE_MAP_EVENT的event data的部分解析如下：  參考官網：https://dev.mysql.com/doc/internals/en/table-map-event.html
Name                Size    16進制                                Remarks
table id             6      0x6d 00 00 00 00 00                   表ID， 小端顯示爲00000000006d，轉換爲十進制是109。 表id爲109
flags                2      0x01 00                               flags保留
schema name length   1      0x05                                  數據庫名字長度，爲5，flydb是5個字符長度
schema name        可變     0x66 6c 79 64 62                      數據庫名字。 16進制轉字符爲flydb
[00]                 1      0x00                                  固定保留0x00
table name length    1      0x02                                  表名字長度，爲2，t1是2個字符長度
table name         可變     0x74 31                               表名字。 16進制轉字符爲t1
[00]                 1      0x00                                  固定保留0x00
column-count       可變     0x03                                  列的數量 3個列，是id、a、b三個列
column_type_def    可變     0x03 03 03                            列的類型，這裏是id、a、b三個字段都是long int類型。詳見如下《附3、 field_types類型》
column_meta_def    可變     0x00                                  這裏是long int類型，爲0 。詳見如下《附4、column_meta_def》。 也對應msyqlbinlog解析的meta=0
null_bitmap  INT((n+8)/7)   0x06                                  是否可以爲null的位圖。每一位代表一個列。轉換爲bitmap：00000110， 第一列(bit)不能爲null，   二、三列(bit)可以爲null
          n是列的數量，這裏是3                                      對應msyqlbinlog解析的nullable=0
CRC32                4      0x43 7f c7 c4                         CRC32校驗位


--3.6.3、mysqlbinlog解析的 第六個event事件(381-429字節) 如下：
# at 381
#191206 11:13:56 server id 222  end_log_pos 429 CRC32 0xc4c77f43        Table_map: `flydb`.`t1` mapped to number 109
# at 429






--3.7、：第七個event事件解析：DELETE_ROWS_EVENT， 用於row模式的事件，記錄修改的數據的值(如果大於8k，會再生成一個新的DELETE_ROWS_EVENT事件，老的DELETE_ROWS寫入到binlog cache中)
000001a0  74 31 00 03 03 03 03 00  06 43 7f c7 c4 74 c7 e9  |t1.......C...t..|
000001b0  5d 20 de 00 00 00 30 00  00 00 dd 01 00 00 00 00  |] ....0.........|
000001c0  6d 00 00 00 00 00 01 00  02 00 03 ff f8 02 00 00  |m...............|
000001d0  00 e7 03 00 00 02 00 00  00 92 db 84 85 74 c7 e9  |.............t..|


--3.7.1、DELETE_ROWS_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x20                                  轉換爲十進制是log_event_type爲32，是DELETE_ROWS_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x30 00 00 00                         小端顯示爲00000030，轉換爲十進制是48。這個DELETE_ROWS_EVENT的事件 從429開始，加上48 ，下個事件爲477開始。
next_position        4      0xdd 01 00 00                         小端顯示爲000001dd，轉換爲十進制是477。下個事件從477開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.7.2、DELETE_ROWS_EVENT的event data的部分解析如下：  參考官網：https://dev.mysql.com/doc/internals/en/rows-event.html
Name                Size    16進制                                Remarks
table id             6      0x6d 00 00 00 00 00                   表ID， 小端顯示爲00000000006d，轉換爲十進制是109。 表id爲109
flags                2      0x01 00                               flags,參照如下flags：
m_extra_row_data     2      0x02 00                               extra-data-length
column-count       可變     0x03                                  列的數量 3個列，是id、a、b三個列
columns-present-bitmap      0xff                                  列的當前位圖  todo...
null_bitmap   INT((n+8)/7)  0xf8                                  當前值是否爲null的位圖。每一位代表一個列。轉換爲bitmap：‭11111000‬， 目前第一、二、三列的值都不爲null。對應mysqlbinlog的is_null=0
value              可變     0x02 00 00 00                          第一個列的值。小端顯示爲00000002，轉換爲十進制是2。
value              可變     0xe7 03 00 00                          第二個列的值。小端顯示爲000003e7，轉換爲十進制是999。
value              可變     0x02 00 00 00                          第三個列的值。小端顯示爲00000002，轉換爲十進制是2。
CRC32                4      0x92 db 84 85                         CRC32校驗位


flags (2) --
Hex      Name
0x0001   end of statement
0x0002   no foreign key checks
0x0004   no unique key checks
0x0008   row has a columns


--3.7.3、mysqlbinlog解析的 第七個event事件(429-477字節) 如下：
# at 429
#191206 11:13:56 server id 222  end_log_pos 477 CRC32 0x8584db92        Delete_rows: table id 109 flags: STMT_END_F
BINLOG '
dMfpXR3eAAAAMQAAAH0BAACAABlkZWxldGUgZnJvbSB0MSB3aGVyZSBpZD0yew8Sew==
dMfpXRPeAAAAMAAAAK0BAAAAAG0AAAAAAAEABWZseWRiAAJ0MQADAwMDAAZDf8fE
dMfpXSDeAAAAMAAAAN0BAAAAAG0AAAAAAAEAAgAD//gCAAAA5wMAAAIAAACS24SF
'/*!*/;
### DELETE FROM `flydb`.`t1`
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2=999 /* INT meta=0 nullable=1 is_null=0 */
###   @3=2 /* INT meta=0 nullable=1 is_null=0 */
# at 477






--3.8、：第八個event事件解析：XID_EVENT，記錄xid，用於二階段提交時 redo log 來查看binlog的事務是否完成的標識(出現了xid說明存儲引擎redo log已提交完成)。 是事務的最後一個事件
000001d0  00 e7 03 00 00 02 00 00  00 92 db 84 85 74 c7 e9  |.............t..|
000001e0  5d 10 de 00 00 00 1f 00  00 00 fc 01 00 00 00 00  |]...............|
000001f0  27 00 00 00 00 00 00 00  ca 4b 6d 6a 76 c7 e9 5d  |'........Kmjv..]|


--3.8.1、XID_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x74 c7 e9 5d                         小端顯示爲‭5DE9C774‬，轉換爲十進制是‭1575602036‬。查看該時間： [root@hostmysql80 mysql]# date -d'@1575602036'
                                                                                                                                            Fri Dec  6 11:13:56 CST 2019
type_code            1      0x10                                  轉換爲十進制是log_event_type爲16，是XID_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x1f 00 00 00                         小端顯示爲0000001f，轉換爲十進制是31。這個XID_EVENT的事件 從477開始，加上31 ，下個事件爲508開始。
next_position        4      0xfc 01 00 00                         小端顯示爲000001fc，轉換爲十進制是508。下個事件從508開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.8.2、XID_EVENT的event data的部分解析如下：
Name                Size    16進制                                Remarks
xid                  8      0x27 00 00 00 00 00 00 00             xid。 小端顯示爲0000000000000027，轉換爲十進制是39， xid爲39。
CRC32                4      0xca 4b 6d 6a                         CRC32校驗位


--3.8.3、mysqlbinlog解析的 第八個event事件(477-508字節) 如下：
# at 477
#191206 11:13:56 server id 222  end_log_pos 508 CRC32 0x6a6d4bca        Xid = 39
COMMIT/*!*/;
# at 508






--3.9、：第九個event事件解析： ROTATE_EVENT，當前binlog的最後一個event事件 來告知下一個binlog二進制文件的name和pos
000001f0  27 00 00 00 00 00 00 00  ca 4b 6d 6a 76 c7 e9 5d  |'........Kmjv..]|
00000200  04 de 00 00 00 2f 00 00  00 2b 02 00 00 00 00 04  |...../...+......|
00000210  00 00 00 00 00 00 00 6d  79 73 71 6c 2d 62 69 6e  |.......mysql-bin|
00000220  2e 30 30 30 30 34 32 8d  46 93 00                 |.000042.F..|


--3.9.1、ROTATE_EVENT的event header的6個部分解析如下：
Name                Size    16進制                                Remarks
timestamp            4      0x76 c7 e9 5d                         小端顯示爲‭5DE9C776‬，轉換爲十進制是‭‭1575602038‬‬。查看該時間： [root@hostmysql80 mysql]# date -d'@‭1575602038‬'
                                                                                                                                            Fri Dec  6 03:13:58 UTC 2019
type_code            1      0x04                                  轉換爲十進制是log_event_type爲16，是ROTATE_EVENT事件，枚舉詳見如下《附1、log_event_type枚舉》
server_id            4      0xde 00 00 00                         小端顯示爲000000de，轉換爲十進制是222。是mysql的server_id。  show variables like '%server%'; 查看爲222。 相同 沒問題
event_length         4      0x2f 00 00 00                         小端顯示爲0000002f，轉換爲十進制是47。這個ROTATE_EVENT的事件 從508開始，加上47 ，下個事件爲555開始。
next_position        4      0x2b 02 00 00                         小端顯示爲0000022b，轉換爲十進制是555。下個事件從555開始，和上面的可以對應上
flags                2      0x00 00                               詳見如下《附2、flags 標識》


--3.9.2、ROTATE_EVENT的event data的部分解析如下： 參考官網：https://dev.mysql.com/doc/internals/en/rotate-event.html
Name                Size    16進制                                Remarks
pos(next binlog)     8      0x04 00 00 00 00 00 00 00             小端顯示爲0000000000000004，轉換爲十進制是4。下一個binlog二進制日誌的起始字節位置： 4，從第4個字節開始 (前4字節是魔法字)
name(next binlog)   可變    0x6d 79 73 71 ..到.. 30 34 32         下一個binlog二進制日誌的文件名稱：16進制轉字符：mysql-bin.000042
CRC32                4      0x8d 46 93 00                         CRC32校驗位


--3.9.3、mysqlbinlog解析的 第九個event事件(508-555字節) 如下：
# at 508
#191206 11:13:58 server id 222  end_log_pos 555 CRC32 0x0093468d        Rotate to mysql-bin.000042  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

 

 

 

--附1、log_event_type枚舉
參考官網：https://dev.mysql.com/doc/internals/en/event-classes-and-types.html

enum Log_event_type {
  UNKNOWN_EVENT= 0,
  START_EVENT_V3= 1,
  QUERY_EVENT= 2,
  STOP_EVENT= 3,
  ROTATE_EVENT= 4,
  INTVAR_EVENT= 5,
  LOAD_EVENT= 6,
  SLAVE_EVENT= 7,
  CREATE_FILE_EVENT= 8,
  APPEND_BLOCK_EVENT= 9,
  EXEC_LOAD_EVENT= 10,
  DELETE_FILE_EVENT= 11,
  NEW_LOAD_EVENT= 12,
  RAND_EVENT= 13,
  USER_VAR_EVENT= 14,
  FORMAT_DESCRIPTION_EVENT= 15,
  XID_EVENT= 16,
  BEGIN_LOAD_QUERY_EVENT= 17,
  EXECUTE_LOAD_QUERY_EVENT= 18,
  TABLE_MAP_EVENT = 19,
  PRE_GA_WRITE_ROWS_EVENT = 20,
  PRE_GA_UPDATE_ROWS_EVENT = 21,
  PRE_GA_DELETE_ROWS_EVENT = 22,
  WRITE_ROWS_EVENT = 23,
  UPDATE_ROWS_EVENT = 24,
  DELETE_ROWS_EVENT = 25,
  INCIDENT_EVENT= 26,
  HEARTBEAT_LOG_EVENT= 27,
  IGNORABLE_LOG_EVENT= 28,
  ROWS_QUERY_LOG_EVENT= 29,
  WRITE_ROWS_EVENT = 30,
  UPDATE_ROWS_EVENT = 31,
  DELETE_ROWS_EVENT = 32,
  GTID_LOG_EVENT= 33,
  ANONYMOUS_GTID_LOG_EVENT= 34,
  PREVIOUS_GTIDS_LOG_EVENT= 35,
  ENUM_END_EVENT
  /* end marker */
};





--附2、 flags 標識
參考官網：https://dev.mysql.com/doc/internals/en/event-flags.html

Current event flags:

LOG_EVENT_BINLOG_IN_USE_F = 0x1                //這個flags表示是否binlog正確的關閉了，這個標示只出現在Format_description_log_event中
LOG_EVENT_THREAD_SPECIFIC_F = 0x4              //是否查詢基於了臨時表，如果基於了臨時表MYSQLBINLOG必須設置 @@PSEUDO_THREAD_ID=xx
LOG_EVENT_SUPPRESS_USE_F = 0x8                 //和--binlog-do-db 、 --replicated-do-db有關
......等等




--附3、 field_types類型
typedef enum enum_field_types {
  MYSQL_TYPE_DECIMAL, 
  MYSQL_TYPE_TINY,
  MYSQL_TYPE_SHORT, 
  MYSQL_TYPE_LONG,
  MYSQL_TYPE_FLOAT, 
  MYSQL_TYPE_DOUBLE,
  MYSQL_TYPE_NULL, 
  MYSQL_TYPE_TIMESTAMP,
  MYSQL_TYPE_LONGLONG,
  MYSQL_TYPE_INT24,
  MYSQL_TYPE_DATE, 
  MYSQL_TYPE_TIME,
  MYSQL_TYPE_DATETIME, 
  MYSQL_TYPE_YEAR,
  MYSQL_TYPE_NEWDATE, 
  MYSQL_TYPE_VARCHAR,
  MYSQL_TYPE_BIT,
  MYSQL_TYPE_TIMESTAMP2,
  MYSQL_TYPE_DATETIME2,
  MYSQL_TYPE_TIME2,
  MYSQL_TYPE_JSON=245,
  MYSQL_TYPE_NEWDECIMAL=246,
  MYSQL_TYPE_ENUM=247,
  MYSQL_TYPE_SET=248,
  MYSQL_TYPE_TINY_BLOB=249,
  MYSQL_TYPE_MEDIUM_BLOB=250,
  MYSQL_TYPE_LONG_BLOB=251,
  MYSQL_TYPE_BLOB=252,
  MYSQL_TYPE_VAR_STRING=253,
  MYSQL_TYPE_STRING=254,
  MYSQL_TYPE_GEOMETRY=255
} enum_field_types;





--附4、column_meta_def
type-specific metadata for each column

Type                                       meta-len
Protocol::MYSQL_TYPE_STRING                  2
Protocol::MYSQL_TYPE_VAR_STRING              2
Protocol::MYSQL_TYPE_VARCHAR                 2
Protocol::MYSQL_TYPE_BLOB                    1
Protocol::MYSQL_TYPE_DECIMAL                 2
Protocol::MYSQL_TYPE_NEWDECIMAL              2
Protocol::MYSQL_TYPE_DOUBLE                  1
Protocol::MYSQL_TYPE_FLOAT                   1
Protocol::MYSQL_TYPE_ENUM                    2
Protocol::MYSQL_TYPE_SET                     see MYSQL_TYPE_ENUM
Protocol::MYSQL_TYPE_BIT                     0
Protocol::MYSQL_TYPE_DATE                    0
Protocol::MYSQL_TYPE_DATETIME                0
Protocol::MYSQL_TYPE_TIMESTAMP               0
Protocol::MYSQL_TYPE_TIME                    --
Protocol::MYSQL_TYPE_TINY                    0
Protocol::MYSQL_TYPE_SHORT                   0
Protocol::MYSQL_TYPE_INT24                   0
Protocol::MYSQL_TYPE_LONG                    0
Protocol::MYSQL_TYPE_LONGLONG                0

 

 

 

 

 

--4、mysqlbinlog工具解析

[root@hostmysql80 mysql]# mysqlbinlog -vv mysql-bin.000041
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#191206 11:13:51 server id 222  end_log_pos 123 CRC32 0xf38e9103        Start: binlog v 4, server v 5.7.27-log created 191206 11:13:51
BINLOG '
b8fpXQ/eAAAAdwAAAHsAAAAAAAQANS43LjI3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AQORjvM=
'/*!*/;
# at 123
#191206 11:13:51 server id 222  end_log_pos 194 CRC32 0xb49b6a2e        Previous-GTIDs
# f7b23f20-f3ea-11e9-bdb9-080027781379:1183166
# at 194
#191206 11:13:56 server id 222  end_log_pos 259 CRC32 0xcf18638b        GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'f7b23f20-f3ea-11e9-bdb9-080027781379:1183167'/*!*/;
# at 259
#191206 11:13:56 server id 222  end_log_pos 332 CRC32 0xc5d64681        Query   thread_id=7     exec_time=0     error_code=0
SET TIMESTAMP=1575602036/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549120/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=83/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 332
#191206 11:13:56 server id 222  end_log_pos 381 CRC32 0x7b120f7b        Rows_query
# delete from t1 where id=2
# at 381
#191206 11:13:56 server id 222  end_log_pos 429 CRC32 0xc4c77f43        Table_map: `flydb`.`t1` mapped to number 109
# at 429
#191206 11:13:56 server id 222  end_log_pos 477 CRC32 0x8584db92        Delete_rows: table id 109 flags: STMT_END_F
BINLOG '
dMfpXR3eAAAAMQAAAH0BAACAABlkZWxldGUgZnJvbSB0MSB3aGVyZSBpZD0yew8Sew==
dMfpXRPeAAAAMAAAAK0BAAAAAG0AAAAAAAEABWZseWRiAAJ0MQADAwMDAAZDf8fE
dMfpXSDeAAAAMAAAAN0BAAAAAG0AAAAAAAEAAgAD//gCAAAA5wMAAAIAAACS24SF
'/*!*/;
### DELETE FROM `flydb`.`t1`
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2=999 /* INT meta=0 nullable=1 is_null=0 */
###   @3=2 /* INT meta=0 nullable=1 is_null=0 */
# at 477
#191206 11:13:56 server id 222  end_log_pos 508 CRC32 0x6a6d4bca        Xid = 39
COMMIT/*!*/;
# at 508
#191206 11:13:58 server id 222  end_log_pos 555 CRC32 0x0093468d        Rotate to mysql-bin.000042  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;