解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENT
原創:轉載請說明出處謝謝!
上接
http://blog.itpub.net/7728585/viewspace-2133188/
參考源:
1、原始碼log_event.h log_event.cc
2、internals-en.epub
class:Format_description_log_event
event:FORMAT_DESCRIPTION_EVENT
mysql 5.0後所有的binlog 檔案都是以FORMAT_DESCRIPTION_EVENT(FED) event開始的,其typecode=15
及0X0F
它的格式為:
1、fixed data part
2 bytes:binlog 的格式版本,我們看到5.6,5.7肯定都是v4
50 bytes:這是一個固定50位元組的字串,顯示了mysql server的版本,用0X00補足
也就是第一個0X00表示結尾
4 bytes: 這4個位元組文件上說是冗餘的,在event header顯示,這裡看到全是0X00
1 bytes:這個位元組直接說明了我們event header的長度,V4為19
var-size:這些位元組由已經定義的event的個數定義5.6,5.7為40個,也就是40個位元組
說明了他們fixed data(posted header)的長度
2、variable data
無
我們來解析一個實際的二進位制格式檔案
00000000 fe 62 69 6e bc df 98 58 0f 01 00 00 00 77 00 00 |.bin...X.....w..|
00000010 00 7b 00 00 00 00 00 04 00 35 2e 37 2e 31 34 2d |.{.......5.7.14-|
00000020 37 2d 64 65 62 75 67 2d 6c 6f 67 00 00 00 00 00 |7-debug-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 55 88 2c 87
mysqlbinlog輸出為:
# at 4
#170207 4:42:36 server id 1 end_log_pos 123 CRC32 0x872c8855 Start: binlog v 4, server v 5.7.14-7-debug-log created 170207 4:42:36
BINLOG '
vN+YWA8BAAAAdwAAAHsAAAAAAAQANS43LjE0LTctZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AVWILIc=
'/*!*/;
fe 62 69 6e:binlog開頭魔法數 4位元組
event header
bc df 98 58:timestamp,小端顯示,及0X5898DFBC十進位制1486413756,用命令
[root@testmy mysqld.1]# date -d'@1486413756'
Tue Feb 7 04:42:36 CST 2017
可以看見時間和mysqbinlog解析的一致4:42:36
0f:event_type為15
01 00 00 00:service_id,小端顯示 0X00000001及1
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
和mysqlbinlog中的server id 1也是一致的
77 00 00 00:event長度及0X00000077及119,剛好是下一個event 123-4(魔法數)=119
7b 00 00 00:下一個event位置0X0000007b及123,和mysqlbinlog解析的end_log_pos 123一致
00 00:flags,如果為0X0001那麼會在MYSQLBINLOG輸出中報一個警告說本binlog沒有關閉
04 00:binlog 版本,小端顯示及0X0004,和mysqlbinlog中的解析Start: binlog v 4一致
35 2e 37 2e 31 34 2d 37 2d 64 65 62 75 67 2d 6c
6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 :
這部分就是50位元組的字串了其ASCII值是5.7.14-7-debug-log和mysqlbinlog中的解析
server v 5.7.14-7-debug-log一致
00 00 00 00:冗餘的timestamp,全是0X00
13 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f
00 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a
0a 2a 2a 00 12 34 00 01:
這部分是一個陣列,表現了已知的40個event的fixed data(posted header)的長度
打個比方說0a 0a 0a 這裡剛好array[30],array[31],array[32](C語言以[0]作為數
組的開始)就是我們最要的
WRITE_ROWS_EVENT
UPDATE_ROWS_EVENT
DELETE_ROWS_EVENT
的fixed data(posted header)的長度0X0A也就是10,以後會詳細解釋
55 88 2c 87: CRC32校驗位,小端顯示及0X872C8855和mysqlbinlog中的CRC32 0x872c8855一致
到這裡FORMAT_DESCRIPTION_EVENT解析完畢
上接
http://blog.itpub.net/7728585/viewspace-2133188/
參考源:
1、原始碼log_event.h log_event.cc
2、internals-en.epub
class:Format_description_log_event
event:FORMAT_DESCRIPTION_EVENT
mysql 5.0後所有的binlog 檔案都是以FORMAT_DESCRIPTION_EVENT(FED) event開始的,其typecode=15
及0X0F
它的格式為:
1、fixed data part
2 bytes:binlog 的格式版本,我們看到5.6,5.7肯定都是v4
50 bytes:這是一個固定50位元組的字串,顯示了mysql server的版本,用0X00補足
也就是第一個0X00表示結尾
4 bytes: 這4個位元組文件上說是冗餘的,在event header顯示,這裡看到全是0X00
1 bytes:這個位元組直接說明了我們event header的長度,V4為19
var-size:這些位元組由已經定義的event的個數定義5.6,5.7為40個,也就是40個位元組
說明了他們fixed data(posted header)的長度
2、variable data
無
我們來解析一個實際的二進位制格式檔案
00000000 fe 62 69 6e bc df 98 58 0f 01 00 00 00 77 00 00 |.bin...X.....w..|
00000010 00 7b 00 00 00 00 00 04 00 35 2e 37 2e 31 34 2d |.{.......5.7.14-|
00000020 37 2d 64 65 62 75 67 2d 6c 6f 67 00 00 00 00 00 |7-debug-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 55 88 2c 87
mysqlbinlog輸出為:
# at 4
#170207 4:42:36 server id 1 end_log_pos 123 CRC32 0x872c8855 Start: binlog v 4, server v 5.7.14-7-debug-log created 170207 4:42:36
BINLOG '
vN+YWA8BAAAAdwAAAHsAAAAAAAQANS43LjE0LTctZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AVWILIc=
'/*!*/;
fe 62 69 6e:binlog開頭魔法數 4位元組
event header
bc df 98 58:timestamp,小端顯示,及0X5898DFBC十進位制1486413756,用命令
[root@testmy mysqld.1]# date -d'@1486413756'
Tue Feb 7 04:42:36 CST 2017
可以看見時間和mysqbinlog解析的一致4:42:36
0f:event_type為15
01 00 00 00:service_id,小端顯示 0X00000001及1
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
和mysqlbinlog中的server id 1也是一致的
77 00 00 00:event長度及0X00000077及119,剛好是下一個event 123-4(魔法數)=119
7b 00 00 00:下一個event位置0X0000007b及123,和mysqlbinlog解析的end_log_pos 123一致
00 00:flags,如果為0X0001那麼會在MYSQLBINLOG輸出中報一個警告說本binlog沒有關閉
04 00:binlog 版本,小端顯示及0X0004,和mysqlbinlog中的解析Start: binlog v 4一致
35 2e 37 2e 31 34 2d 37 2d 64 65 62 75 67 2d 6c
6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 :
這部分就是50位元組的字串了其ASCII值是5.7.14-7-debug-log和mysqlbinlog中的解析
server v 5.7.14-7-debug-log一致
00 00 00 00:冗餘的timestamp,全是0X00
13 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f
00 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a
0a 2a 2a 00 12 34 00 01:
這部分是一個陣列,表現了已知的40個event的fixed data(posted header)的長度
打個比方說0a 0a 0a 這裡剛好array[30],array[31],array[32](C語言以[0]作為數
組的開始)就是我們最要的
WRITE_ROWS_EVENT
UPDATE_ROWS_EVENT
DELETE_ROWS_EVENT
的fixed data(posted header)的長度0X0A也就是10,以後會詳細解釋
55 88 2c 87: CRC32校驗位,小端顯示及0X872C8855和mysqlbinlog中的CRC32 0x872c8855一致
到這裡FORMAT_DESCRIPTION_EVENT解析完畢
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-2133189/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 解析MYSQL BINLOG二進位制格式(9)--infobin解析binlog幫助文件MySql
- 解析MYSQL BINLOG二進位制格式(10)--問題解答MySql
- 解析MYSQL BINLOG 二進位制格式(1)--準備工作MySql
- 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENTMySqldelete
- MySQL二進位制檔案(binlog)MySql
- 解析MYSQL BINLOG 二進位制格式(7)--Xid_log_event/XID_EVENTMySql
- Java二進位制Class檔案格式解析Java
- 解析MYSQL BINLOG二進位制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他MySql
- mysql二進位制日誌格式介紹MySql
- 如何在MySQL中檢視binlog二進位制日誌?MySql
- office檔案格式複合文件二進位制結構解析
- MySQL二進位制日誌MySql
- mysql 二進位制日誌MySql
- mixed模式下的binlog二進位制日誌解析,需要加-v引數模式
- 二進位制求5個1的格式。。。。
- Mysql二進位制包安裝MySql
- 管理mysql二進位制日誌MySql
- mysql的二進位制日誌MySql
- 二進位制與二進位制運算
- 進位制詳解:二進位制、八進位制和十六進位制
- JavaScript 二進位制、八進位制與十六進位制JavaScript
- [MySQL binlog]徹底解析Mixed日誌格式的binlogMySql
- MySQL二進位制日誌的三種格式優缺點比較MySql
- MySQL 壓縮二進位制日誌MySql
- mysql二進位制日誌詳解MySql
- MySQL linux二進位制安裝MySqlLinux
- 10進位制 VS 2進位制
- 利用vstruct解析二進位制資料Struct
- (二進位制)
- 十進位制——二 (八、十六 )進位制
- 有趣的二進位制2—高效位運算
- 二進位制,八進位制,十進位制,十六進位制的相互轉換
- 二進位制、十進位制與十六進位制相互轉化
- java中二進位制、八進位制、十進位制、十六進位制的轉換Java
- 二進位制,八進位制,十進位制,十六進位制之間的轉換