解析MYSQL BINLOG二進位制格式(10)--問題解答

gaopengtttt發表於2017-02-14

原創轉發請註明出處
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二進位制格式(1)--準備工作 
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENT 
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENT 
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENT 
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENT 
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二進位制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT  
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二進位制格式(7)--Xid_log_event/XID_EVENT 
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG二進位制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他 
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG二進位制格式(9)--infobin解析binlog幫助文件

本文解析全部使用工具infobin 
參考
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG二進位制格式(9)--infobin解析binlog幫助文件

最後我們來回答最開始提出的問題

1、為什麼說row格式較statement更佔空間
   在前面所述 因為row格式記錄了真正的資料,比單純的語句要大得多,
   其binlog生成量大約為修改資料量的2/3。如果是update則更大,因為有
   前後印象大約為修改資料量的4/3
2、為什麼說row格式的binlog更加安全
   在前面所述,因為row格式加入了map event,使用table_id進行復制,同時
   記錄是真正的記錄,那麼複製是解析的其真正的資料做到了更加安全,
   換句話說他是真正的二進位制的包含了修改的資料
3、INSERT/UPDATE/DELETE是生成的row binlog如何直接看懂二進位制格式
   如前面各個文章所描述,並且程式我已經寫好了,可以使用參考前面的文章
4、DDL生成的binlog是怎麼樣的
   DDL生成的binlog是語句模式,只有DML操作可以記錄行格式。
5、INSERT SELECT/CREATE TABLE 如何生成的row binlog
   insert select 生成是binlog是一個事物中的多個event,但是並不是每條資料一個event
   而是多條資料生成一個event,一個event大小大約為8K左右。
 但是這也有例外就是一行資料本來就超過了8K如下:
 insert into testb values(repeat('A',19999));
------>Insert Event:Pos:563(0X233) N_pos:20600(0X5078) Time:1487042557 Event_size:20037(bytes) 
   create table as 生成的binlog比insert selcet多了一個create table的過程,但是在開啟
   gtid的情況是不能使用的create table as。
我做了語句:
mysql> insert into testkk select * from test limit 40000;
Query OK, 40000 rows affected (2.52 sec)
Records: 40000  Duplicates: 0  Warnings: 0

如下:
使用
 ./infobin test.000202|more

>Gtid Event:Pos:356(0X164) N_pos:421(0X1a5) Time:1487040273 Event_size:65(bytes) 
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1100471
-->Query Event:Pos:421(0X1a5) N_Pos:493(0X1ed) Time:1487040273 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:1100471
---->Map Event:Pos493(0X1ed) N_pos:666(0X29a) Time:1487040273 Event_size:173(bytes) 
TABLE_ID:350 DB_NAME:test TABLE_NAME:testkk Gno:1100471
------>Insert Event:Pos:666(0X29a) N_pos:8822(0X2276) Time:1487040273 Event_size:8156(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:8822(0X2276) N_pos:16982(0X4256) Time:1487040273 Event_size:8160(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:16982(0X4256) N_pos:25143(0X6237) Time:1487040273 Event_size:8161(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:25143(0X6237) N_pos:33304(0X8218) Time:1487040273 Event_size:8161(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:33304(0X8218) N_pos:41455(0Xa1ef) Time:1487040273 Event_size:8151(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:41455(0Xa1ef) N_pos:49572(0Xc1a4) Time:1487040273 Event_size:8117(bytes) 
....
------>Insert Event:Pos:5602407(0X557c67) N_pos:5610568(0X559c48) Time:1487040273 Event_size:8161(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:5610568(0X559c48) N_pos:5618719(0X55bc1f) Time:1487040273 Event_size:8151(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
------>Insert Event:Pos:5618719(0X55bc1f) N_pos:5624075(0X55d10b) Time:1487040273 Event_size:5356(bytes) 
Dml on table: test.testkk  table_id:350 Gno:1100471 
>Xid Event:Pos:5624075(0X55d10b) N_Pos:5624106(0X55d12a) Time:1487040273 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:1100471

可以看到大小大約為8K,當然如果不嫌麻煩用mysqlbinlog也行但是event_size需要自己減一下。

6、如果一個delete大表先開始,然後不斷有insert小表進入,他是如何生成binlog的。gtid又是按什麼順序生成

我透過分析 delete大表的binlog會在commit後寫到binlog中,之前binlog記錄在快取或者臨時檔案中
但是binlog中的時間記錄為事務開始時間為delete發起時間,其gtid生成順序
是按照commit的時候生成的,同時一個事物的binlog一定是連續的。
如下:
>Gtid Event:Pos:120314(0X1d5fa) N_pos:120379(0X1d63b) Time:1487032811 Event_size:65(bytes)  --小事物開始
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000922
-->Query Event:Pos:120379(0X1d63b) N_Pos:120451(0X1d683) Time:1487032811 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:1000922
---->Map Event:Pos120451(0X1d683) N_pos:120503(0X1d6b7) Time:1487032811 Event_size:52(bytes) 
TABLE_ID:343 DB_NAME:test TABLE_NAME:testloop1 Gno:1000922
------>Insert Event:Pos:120503(0X1d6b7) N_pos:120543(0X1d6df) Time:1487032811 Event_size:40(bytes) 
Dml on table: test.testloop1  table_id:343 Gno:1000922 
>Xid Event:Pos:120543(0X1d6df) N_Pos:120574(0X1d6fe) Time:1487032811 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:1000922 --小事物結束
>Gtid Event:Pos:120574(0X1d6fe) N_pos:120639(0X1d73f) Time:1487032783 Event_size:65(bytes) --大事物開始
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000923
-->Query Event:Pos:120639(0X1d73f) N_Pos:120711(0X1d787) Time:1487032783 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:1000923
---->Map Event:Pos120711(0X1d787) N_pos:120888(0X1d838) Time:1487032783 Event_size:177(bytes) 
TABLE_ID:342 DB_NAME:test TABLE_NAME:test100009 Gno:1000923
------>Delete Event:Pos:120888(0X1d838) N_pos:129044(0X1f814) Time:1487032783 Event_size:8156(bytes) 
Dml on table: test.test100009  table_id:342 Gno:1000923 
------>Delete Event:Pos:129044(0X1f814) N_pos:137204(0X217f4) Time:1487032783 Event_size:8160(bytes) 
Dml on table: test.test100009  table_id:342 Gno:1000923 
------>Delete Event:Pos:137204(0X217f4) N_pos:145365(0X237d5) Time:1487032783 Event_size:8161(bytes) 
Dml on table: test.test100009  table_id:342 Gno:1000923 
.................
Dml on table: test.test100009  table_id:342 Gno:1000923 
------>Delete Event:Pos:102028245(0X614d3d5) N_pos:102036403(0X614f3b3) Time:1487032783 Event_size:8158(bytes) 
Dml on table: test.test100009  table_id:342 Gno:1000923 
------>Delete Event:Pos:102036403(0X614f3b3) N_pos:102040255(0X61502bf) Time:1487032783 Event_size:3852(bytes) 
Dml on table: test.test100009  table_id:342 Gno:1000923 
>Xid Event:Pos:102040255(0X61502bf) N_Pos:102040286(0X61502de) Time:1487032783 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:1000923 ---大事物結束
>Gtid Event:Pos:102040286(0X61502de) N_pos:102040351(0X615031f) Time:1487032811 Event_size:65(bytes) --小事物開始
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000924
-->Query Event:Pos:102040351(0X615031f) N_Pos:102040423(0X6150367) Time:1487032811 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:1000924
---->Map Event:Pos102040423(0X6150367) N_pos:102040475(0X615039b) Time:1487032811 Event_size:52(bytes) 
TABLE_ID:343 DB_NAME:test TABLE_NAME:testloop1 Gno:1000924
------>Insert Event:Pos:102040475(0X615039b) N_pos:102040515(0X61503c3) Time:1487032811 Event_size:40(bytes) 
Dml on table: test.testloop1  table_id:343 Gno:1000924 
>Xid Event:Pos:102040515(0X61503c3) N_Pos:102040546(0X61503e2) Time:1487032811 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:1000924 --小事物結束


      會話 A                                                                                                       會話B
delete 事物 1487032783開始                                     
        +                                                                                             insert 事物開始 1487032811 
        +                                                                                            commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000922 
        +
delete 事物結束commit 生成
commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000923
                                                                                                      insert 事物開始 1487032811
                                                                                                     commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000924
                                                       


實際上記錄binlog的順序為
insert   commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000922 
delete commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000923
insert  commit gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000924


也就是說delete記錄到了第一個insert之後,按照是commit的順序來記錄和分配gtid的
也就是上面解析出來的結果。

至此mysql binlog 二進位制格式解析系列文章告於段落

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-2133537/,如需轉載,請註明出處,否則將追究法律責任。

相關文章