解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT

原创：转载请说明出处谢谢！
上接
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 

class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31


class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32


自从5.1.18开始,row模式下的update/delete的event
这部分将UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因为了有了前面WRITE_ROW_EVENT 的
基础这两个基本和他一致，只是要注意UPDATE_ROW_EVENT存放了前后印象
--fixed data  10字节(5.6,5.7中描述为 ROWS_HEADER_LEN_V2)
  6 bytes 表ID
  2 bytes 保留
  2 bytes 文档中并没有描述
  源码中描述为：
  uchar    *m_extra_row_data;   /* Pointer to extra row data if any */
                                /* If non null, first byte is length */
  具体参考前面一篇(解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT)
--variable data part
  packed integer：表中字段个数，这个地方为packed integer自行参考源码
                  uchar *net_store_length或者参考第一章
                  (解析MYSQL BINLOG 二进制格式(1)--准备工作 )
  var-size:文档解释为每一位代表是否字段用到了 长度为INT((n+7)/8) n代表字段数量
           源码描述为 m_cols; /* Bitmap denoting columns available */
           测试表现这一字节和binlog_row_image设置有关，默认为FULL每一个字节始终为
           0XFF 
  var-size-update:UPDATE_ROW_EVENT专用和前面描述的一致，但是表示的是后印象，也就是update后的数据
  
  var-size:每一位代表的字段的值是否为NULL，长度为INT((n+7)/8) n代表字段数量，
  他采用一个位图的方式。
           1：NULL
           0：NOT NULL
  var-size:这部分就是真正的数据了。
    
  var-size-update:
  var-size-update:
  这两部分为UPDATE_ROW_EVENT专用和前面描述的两部分一致，但是表示的是后印象，也就是update后的数据
  
接下来进行实际的解析：
执行语句
mysql> select * from testnull2;
+------+-------+-------+
| id   | name1 | name2 |
+------+-------+-------+
| NULL | test  | NULL  |
+------+-------+-------+
1 row in set (0.01 sec)


mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0


mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)


使用./infobin (自己开发 我放到了云盘)
http://pan.baidu.com/s/1jHIWUN0


[root@testmy data]# ./infobin  test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com 
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes) 
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes) 
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000450 
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes) 
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes) 
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes) 
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000451 
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes) 
COMMIT 1000451 /*!add by tool*/


可以看到我们的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000450 
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000451 


现在使用mysqlbinlog --hexdump -vv 进行解析


先来看update event
二进制解析
# at 389
#170213  9:38:44 server id 93157  end_log_pos 441 CRC32 0x21c0591d 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
#      198 d2 00 00 00 00 00 01 00  02 00 03 ff ff fd 04 74 |...............t|
#      1a8 65 73 74 fa 02 00 00 00  04 74 65 73 74 1d 59 c0 |est......test.Y.|
#      1b8 21                                               |.|
#       Update_rows: table id 210 flags: STMT_END_F


-vv输出
### UPDATE `test`.`testnull2`
### WHERE
###   @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
###   @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2=NULL /* INT meta=60 nullable=1 is_null=1 */
###   @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */


分解：
--event header 部分就不解析了table id 210，
  --hexdump也明确的解析了，不理解参考前面的文章
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210  
                   小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */    
ff：update专用和上面一致


----update前印象数据：
fd: 11111101 代表字段@1=NULL和@3=NULL，但是字段@2不为空这和mysqlbinlog解析的一致
    @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
    @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
    @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 长度04 就是数据'test'的长度为4，这个也就是@2='test'事update的前印象
74 65 73 74：字符串'test'


----update后印象数据(update 专用)：
fa：11111010，@2=NULL，但是修改后@1和@3不为空和mysqlbinlog解析一致
    @1=2 /* INT meta=0 nullable=1 is_null=0 */
    @2=NULL /* INT meta=60 nullable=1 is_null=1 */
    @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */    
02 00 00 00 ：也就是数据2也是@1=2也就是update的后印象，小端显示
04： var 长度04 就是数据'test'的长度为4，也就是
74 65 73 74：字符串'test'也是@3='test'也就是update的后印象


1d 59 c0 21：CRC32校验




然后来看delete event
二进制解析
# at 667
#170213  9:38:50 server id 93157  end_log_pos 712 CRC32 0x055741c1 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      29b 2a 0e a1 58   20   e5 6b 01 00   2d 00 00 00   c8 02 00 00   00 00
#      2ae d2 00 00 00 00 00 01 00  02 00 03 ff fa 02 00 00 |................|
#      2be 00 04 74 65 73 74 c1 41  57 05                   |..test.AW.|
#       Delete_rows: table id 210 flags: STMT_END_F




-vv输出
### DELETE FROM `test`.`testnull2`
### WHERE
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2=NULL /* INT meta=60 nullable=1 is_null=1 */
###   @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */


分解：
--event header 部分就不解析了table id 210，
  --hexdump也明确的解析了，不理解参考前面的文章
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210 
                   小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */    


fa: 11111010 代表字段@2=NULL，但是字段@1 @3不为空这和mysqlbinlog解析的一致
    @1=2 /* INT meta=0 nullable=1 is_null=0 */
    @2=NULL /* INT meta=60 nullable=1 is_null=1 */
    @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4字节数据 2及@1=2 小端显示
04:var 长度04 就是数据'test'的长度为4，这个也就是@3='test'
74 65 73 74：字符串'test'
c1 41 57 05：crc32 校验


至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完毕


后记：
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一个字段值是否为空的位图，如前面所说
   然后紧跟了字段数据，这样根据位图就能确定出那些字段为NULL，而实际存储的值中并不包含NULL字段的数据
   因为它没有数据，同样也为了减少存储空间的使用，这种技术在数据库技术中大量使用，在INNODB PAGES中也
   是用到了。
2、很多闪回工具都依赖了binlog中能够记录了需要的所有信息，我们也看到了update还记录前后印象的值，那么
   也为闪回提供了条件，但是binlog_row_image会影响它的记录方式具体参考官方手册，但是它可以节约空间。