MySQL Binlog解析(2)

一、TABLE_MAP_EVENT

Used for row-based binary logging beginning with MySQL 5.1.5.The TABLE_MAP_EVENT defines the structure if the tables that are about to be changed.

用于从MySQL 5.1.5开始的基于行的二进制日志记录。每个ROW_EVENT之前都有一个TABLE_MAP_EVENT,用于描述表的内部ID和结构定义。

1)触发条件

    # ROW格式中每个ROW_EVENT之前

2)存储格式

1、事件头,占用19个字节。
2、事件体部分:
      固定数据部分:
        # table id:6 bytes    //6个字节存储table id
        # 2 bytes:Reserved for future use //2个字节保留未来使用

      可变数据部分:
        # 1 byte. The length of the database name.   //数据库名长度:1字节
        # Variable-sized. The database name (null-terminated).   //数据库名:可变长度
        # 1 byte. The length of the table name.      //表长度:1字节
        # Variable-sized. The table name (null-terminated). //表名:可变长度
        # Packed integer. The number of columns in the table. //表的行数:
        # Variable-sized. An array of column types, one byte per column. To find the meanings of these values, look at enum_field_types in the mysql_com.h header file.       //列类型数组,每一列1个字节
        # Packed integer. The length of the metadata block.  //元数据块的长度
        # Variable-sized. The metadata block; see log_event.h for contents and format.  //元数据块
        # Variable-sized. Bit-field indicating whether each column can be NULL, one bit per column. For this field, the amount of storage required for N columns is INT((N+7)/8) bytes.  //位字段,指示每个列是否可以为空,每个列一位。如果表有N列,需要:INT((N+7)/8) 字节

3)实战分析

结合hexdump出来的数据和mysqlbinlog解析出的日志进行分析:

-------公有事件头--------
1、timestamp(4): 21 2e 0e 5b
2、event_type(1):13,十进制19:TABLE_MAP_EVENT = 19
3、server id(4):5c 27 6b 94 十进制:2490050396
4、event size(4):2e 00 00 00,十进制:46
5、log_pos(4):aa 01 00 00 ,十进制:426 也就是end_log_pos=426
6、flags(2):00 00,等于0表示该日志文件关闭状态

--------固定数据部分(私有事件头)-----
1、table id(6):b1 01 00 00 00 00,十进制433,table_id=433
2、reserve(2):01 00,十进制:1,未被使用

---------可变数据部分(事件体)--------
3、db name len(1):06,数据库名占用6个字节,即darren
4、db name(6):64 61 72 72 65 6e,查询asci码,对应darren
5、00
6、table name len(1):01,表名占用1个字节
7、table name(1):74,asci码对应字母t,即表名是t
8、00
9、column count(1):01,即列的个数1
10、column type(1):03,表示MYSQL_TYPE_LONG
11、column metadata len(1):00,1个字节
12、column metadata:无
13、null bitmap(1):00,0表没有列可以为NULL,如果是01表示该列可以为NULL
14、crc32(4):8f cb  07 7d,代表CRC32=0x7d07cb8f,不在事件体里,可以认为每个事件都存在footer

原文地址:https://www.cnblogs.com/mysql-dba/p/9901659.html

时间: 2024-10-07 05:06:51

MySQL Binlog解析(2)的相关文章

MySQL Binlog 解析工具 Maxwell 详解

maxwell 简介 Maxwell是一个能实时读取MySQL二进制日志binlog,并生成 JSON 格式的消息,作为生产者发送给 Kafka,Kinesis.RabbitMQ.Redis.Google Cloud Pub/Sub.文件或其它平台的应用程序.它的常见应用场景有ETL.维护缓存.收集表级别的dml指标.增量到搜索引擎.数据分区迁移.切库binlog回滚方案等.官网(http://maxwells-daemon.io).GitHub(https://github.com/zende

mysql binlog解析概要

1,dump协议: 根据数据库的ip+port创建socket,如果创建成功,说明链接建立成功,接下来是使用dump协议订阅binlog 链接建立成功之后,服务端会主动向客户端发送如下问候信息greeting(可以理解为经java转换后,是一个java对象), 在下面的代码中可以看到greeting中的信息: this.context.setServerStatus(greeting.getServerStatus());//this.context.setServerVersion(greet

Mysql binlog 解析

首先,我们知道MySQL本身就带有replication的机制,我们需要伪造一个slave,向master注册,这样的话master才会发送binlog event.注册很简单,通过调用limysql.so中的cli_advanced_command(),指定binlog filename+position,向master发送COM_BINLOG_DUMP命令.在发送dump命令的时候,我们可以指定flag为BINLOG_DUMP_NON_BLOCK,这样master在没有可以发送的binlog

原创工具binlog2sql:从MySQL binlog得到你要的SQL

binlog2sql是我开发的mysql binlog解析工具,它能帮助你从binlog得到你要的SQL.根据不同设置,你可以得到原始SQL.回滚SQL.去除主键的INSERT SQL等. 用途 数据回滚 主从切换后数据不一致的修复 从binlog生成标准SQL,带来的衍生功能 安装 $ git clone https://github.com/danfengcao/binlog2sql.git $ pip install -r requirements.txt 使用 MySQL server必

腾讯工程师带你深入解析 MySQL binlog

欢迎大家前往云+社区,获取更多腾讯海量技术实践干货哦~ 本文由 腾讯云数据库内核团队 发布在云+社区 1.概述 binlog是Mysql sever层维护的一种二进制日志,与innodb引擎中的redo/undo log是完全不同的日志:其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句,并以"事务"的形式保存在磁盘中: 作用主要有: 复制:MySQL Replication在Master端开启binlog,Master把它的二进制日志传递给slaves并回放来达到mast

解析MySQL binlog --(2)FORMAT_DESCRIPTION_EVENT

该格式描述事件时binlog version 4中为了取代之前版本的START_EVENT_3事件而引入的.是binlog文件的第一个事件,并在一个binlog文件中仅出现一次.具体定义:binlog-version:binlog版本mysql-server version:服务器版本create timestamp:指明binlog文件的创建时间.如果该binlog是由于切换产生,那么该字段是0event header length:189event type header lengths:记

20180705关于mysql binlog的解析方式

来自:https://blog.csdn.net/u012985132/article/details/74964366/ 关系型数据库和Hadoop生态的沟通越来越密集,时效要求也越来越高.本篇就来调研下实时抓取MySQL更新数据到HDFS. 本篇仅作为调研报告. 初步调研了canal(Ali)+kafka connect+kafka.maxwell(Zendesk)+kafka和mysql_streamer(Yelp)+kafka.这几个工具抓取MySQL的方式都是通过扫描binlog,模拟

MySQL——binlog

一.binlog简介: 1.什么是binlog: binlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句.语句以"事件"的形式保存,它描述数据更改. 2.binlog的记录格式: Mysql binlog日志有三种格式,分别为:Statement ,MiXED ,和ROW: (在MySQL5.7.7版本之后,把binlog_format的默认值修改成了ROW.master将修改表的event写入binlog中,并且master将

PHP Client for Mysql Binlog

PHP解析Mysql Binlog,依赖于mysql-replication-listener库 详见:https://github.com/bullsoft/php-binlog Install MySQL Replication Listener https://github.com/bullsoft/mysql-replication-listener/archive/master.zip 该源代码,有一处bug,在 tcp_driver.cpp 第 650 行处: int Binlog_