解析MYSQL BINLOG 二進(jìn)制格式(1)--準(zhǔn)備工作

原創(chuàng)：轉(zhuǎn)載請(qǐng)說(shuō)明出處謝謝！

參考源：
1、源碼log_event.h log_event.cc pack.c
2、internals-en.epub


一、目的
   本系列文件主要為了說(shuō)明
1、為什么說(shuō)row格式較statement更占空間
2、為什么說(shuō)row格式的binlog更加安全
3、INSERT/UPDATE/DELETE是生成的row binlog如何直接看懂二進(jìn)制格式
4、DDL生成的binlog是怎么樣的
5、INSERT SELECT/CREATE TABLE 如何生成的row binlog

二、使用版本和數(shù)字顯示
本系列文章重要解釋MYSQL 5.6后row格式的binlog格式以及和事物有關(guān)的event，按照官方的說(shuō)法
binlog的格式經(jīng)歷了幾個(gè)階段
v1：mysql 3.23
v3：mysql 4.0.2 到 4.1
v4：mysql 5.0以上
v2版本只是短暫的存在過(guò)，當(dāng)然我們要解析當(dāng)然是v4版本的binlog
因?yàn)橐词?.6以上的binlog
關(guān)于多字節(jié)的數(shù)字顯示，一般使用 Little-endian模式，做到和OS系統(tǒng)無(wú)關(guān)，除非刻意說(shuō)明
關(guān)于Little-endian參考：
http://blog.itpub.net/7728585/viewspace-2124159/
三、binlog的魔法數(shù)
關(guān)于MYSQL BINLOG的作用就不做過(guò)多的解析了,在binlog中存儲(chǔ)的是一種稱(chēng)之為event的條目，
它們以二進(jìn)制的格式存儲(chǔ)，平時(shí)我們使用的mysqlbinlog工具也就是對(duì)這種二進(jìn)制格式的文件
進(jìn)行解析，得到直觀(guān)的輸出。這里不用mysqlbinlog而改為直接看二進(jìn)制文件，當(dāng)然我會(huì)對(duì)比
MYSQLBINLOG的輸出和二進(jìn)制解析的過(guò)程
每一個(gè)binlog文件都有4字節(jié)的魔法數(shù)，其值固定為
[root@testmy mysqld.1]# hexdump -Cv test.000005 
可以看到
fe 62 69 6e .bin

四、binlog event的總體構(gòu)架
一個(gè)event包括了
event header
event data
其中event data又分為
fixed data(posted header)
variable data

event header：全部的event統(tǒng)一固定的格式
fixed data(posted header)：每一類(lèi)event固定
variable data：就是可以變化實(shí)際值了

關(guān)于event的類(lèi)型比較多詳細(xì)參考末尾源碼的截取

五、本系列文章要討論的event
而這里我們只要討論5.6,5.7中和row binlog格式和innodb
聯(lián)系比較緊密的幾種event如下：
query_log_event/QUERY_EVENT typecode=02
Format_description_log_event/FORMAT_DESCRIPTION_EVENT  typecode=15
Xid_log_event/XID_EVENT  typecode=16
Table_map_log_event/TABLE_MAP_EVENT typecode=19
Write_rows_log_event/WRITE_ROW_EVENT typecode=30
Update_rows_log_event/UPDATE_ROW_EVENT typecode=31 
Delele_rows_log_event/DELETE_ROW_EVENT typecode=32 

因?yàn)檫@些語(yǔ)句是一個(gè)事物必須經(jīng)歷的，而Format_description_log_event是一個(gè)最重要的
說(shuō)明性的event

六、通用頭文件(event header)解析
下面先解釋一下通用的19個(gè)字節(jié)。
每一個(gè)event有一個(gè)固定的頭信息叫做event header：
event header
timestamp        0:4             
type_code        4:1  
server_id           5:4
event_length     9:4
next_position    13:4
flags                 17:2             


timestamp：固定4字節(jié)展示是新紀(jì)元(epoch time)以來(lái)的秒數(shù)
type_code：固定1字節(jié)event事件的編碼，在源碼中是一個(gè)enum類(lèi)型負(fù)載最后源碼處
server_id：固定4字節(jié)就是 show variables like '%server_id';出來(lái)的值
event_length：固定4字節(jié)整個(gè)event的長(zhǎng)度，包含固定和非固定長(zhǎng)度
next_position：固定4字節(jié)下一個(gè)event的開(kāi)始位置(2^32為4G)
flags:固定2字節(jié) event flags
      LOG_EVENT_BINLOG_IN_USE_F   0x1 這個(gè)flags表示是否binlog正確的關(guān)閉了，這個(gè)標(biāo)示只出現(xiàn)在Format_description_log_event中
      LOG_EVENT_THREAD_SPECIFIC_F 0x4 是否查詢(xún)基于了臨時(shí)表，如果基于了臨時(shí)表MYSQLBINLOG必須設(shè)置 @@PSEUDO_THREAD_ID=xx
      LOG_EVENT_SUPPRESS_USE_F    0x8 和--binlog-do-db 、 --replicated-do-db有關(guān)
      其他還有很多
      LOG_EVENT_ARTIFICIAL_F 0x20 LOG_EVENT_RELAY_LOG_F 0x40 LOG_EVENT_IGNORABLE_F 0x80 LOG_EVENT_NO_FILTER_F 0x100 。。。
      可以自行參考log_event.h源碼頭文件中的詳細(xì)解釋
      
七、packed interger
在binlog中部分?jǐn)?shù)字使用這種方式顯示，在后面的解析中會(huì)提到
按照文檔和源碼中的說(shuō)明
如果第一個(gè)字節(jié)為0-250及0X0-0XFA那么這個(gè)字節(jié)就是實(shí)際顯示的數(shù)字值
源碼的：
  if (length < (ulonglong) LL(251))
  {
    *packet=(uchar) length;
    return packet+1;
  }
如果第一個(gè)字節(jié)為252及0XFC那么后面的2個(gè)字節(jié)的值為0XFB-0XFFFF
源碼的：
if (length < (ulonglong) LL(65536))
  {
    *packet++=252;
    int2store(packet,(uint) length);
    return packet+2;
  }
如果第一個(gè)字節(jié)為253及0XFD那么后面的3個(gè)字節(jié)的值為0XFFFF-0XFFFFFF
源碼的：
if (length < (ulonglong) LL(16777216))
  {
    *packet++=253;
    int3store(packet,(ulong) length);
    return packet+3;
  }
如果第一個(gè)字節(jié)為254及0XFE那么后面的8個(gè)字節(jié)的值為0XFFFFFF-0XFFFFFFFFFFFFFFFF
  *packet++=254;
  int8store(packet,length);

可以自行參考源碼接口，函數(shù)返回值為一個(gè)下一個(gè)位置的指針
uchar *net_store_length(uchar *packet, ulonglong length)