Mysql binlog日志解析

1. 摘要：

Mysql日志抽取与解析正如名字所将的那样，分抽取和解析两个部分。这里Mysql日志主要是指binlog日志。二进制日志由配置文件的log-bin选项负责启用，Mysql服务器将在数据根目录创建两个新文件XXX-bin.001和XXX-bin.index，若配置选项没有给出文件名，Mysql将使用主机名称命名这两个文件，其中.index文件包含一份全体日志文件的清单。Mysql会把用户对所有数据库的内容和结构的修改情况记入XXX-bin.n文件，而不会记录SELECT和没有实际操作意义的语句。

2. 设计概要：

本项目主要包括两个独立的模块：1、日志抽取（mysql-tracker）；2、日志解析（mysql-parser）。日志抽取主要负责与mysql进行交互，通过socket连接以及基于mysql的开源协议数据报文，来进行从mysql主库上dump相应的日志数据下来。而日志解析主要负责与日志抽取模块交互，通过将dump下来的bytes类型的数据，根据mysql协议，对bytes数据进行解析，并封装成易读的event对象。

2.1  流程概要：

mysql-tracker 总体流程设计：

tracker与mysql交互：

1. 建立socket连接

2. 加载上次退出时的位点信息（从checkpoint表中加载）

3. 利用socket连接发送基于mysql协议的数据包+checkpoint表中的位点信息，创建mysql主库的binlog dump线程

4. 利用socket接受（监听）mysql主库传过来的数据包

5. 解析数据包（有多种形式，OK包，EOF包，ERROR包，EVENT包等等）

6. 如果有EVENT包，将基于byte的数据包解析成event对象

7. 将对象存入List或Queue里面

tracker与hbase交互：

1. 从queue中接收固定量数据（上限：防止内存溢出，下限：防止频繁I/O），或固定时间数据（防止内存溢出）。

2. 这里的数据就是event对象

3. 将event对象序列化，存入hbase（protobuf 和 entry）

4. 存入过程中，保证位点确认机制，如果有关于mysql binlog 的标志性位点，则将该event存入hbase后（注意这里有对特殊xid位点的确认机制，而parser是没有的，直接确认即可），然后再将该event的位点信息存入checkpoint表（维护各种位点信息：包括mysql binlog位点，event表（存如序列化后的event）位点，entry表（存入反序列化后的event）位点）

5. 也就是说只要是存入hbase实体数据，都要伴随位点确认机制。这里tracker确认两个方面的位点：mysql binlog 位点（xid:binlog file name + next position） + event表位点（tracker写位点:row key）

tracker 每分钟记录位点：

1. 每分中固定时间记录确认的checkpoint位点（可能有重复，长时间没有数据fetch重复最多）

mysql-parser 总体流程设计：(设计思路非常类似，只不过是mysql binlog变成了event表，parser fetch数据从这里fetch)

parser与event表交互：

1. 建立hbase连接

2. 加载上次退出的位点信息（从checkpoint表中加载）

3. 通过hbase连接+checkpoint表中的位点信息，不断监听event表一旦event表有更新，就从event表中把序列化的event fetch下来

4. 得到的序列化event（bytes） 存入List或Queue里面。

parser与hbase交互：

1. 从queue中接收固定量数据（上限：防止内存溢出，下限：防止频繁I/O），或固定时间数据（防止内存溢出）。

2. 将序列化的event（bytes）反序列化成entry（其实就是event对象）

3. 将entry存入hbase。

4. 存入过程中，伴随位点确认机制（直接确认位点，不需要特殊位点确认机制）（存入位点信息到checkpoint表中去：parser 读 event表的位点（row key） + parser 写entry表的位点（row key））

parser每分钟确认位点：

1. 每分钟固定时间记录确认的checkpoint位点（可能有重复，长时间没有数据fetch重复最多）

2.2 架构

tracker 与 parser都有同样的3个线程结构 取数据线程、消费数据线程、每分钟记录线程。并且每个消费数据线程必定伴随着位点确认的机制，就如前面2.1流程概要所说：

1、tracker的位点确认机制需要有xid的特殊event作为mysql主库的位点确认点。
2、而hbase里面的位点确认除了tracker写位点也需要是xid的event作为位点确认点，其他确认点没有特殊位点的要求。

3. mysql 相关

主要涉及到mysql的通讯协议和mysql 日志协议。mysql通讯协议，这里主要是利用到与mysql交互中的收发数据包的解析；mysql日志协议，这里主要是利用受到数据包后得到event事件的数据包，然后解析event数据包会用到相关的日志协议。即前者主要用在mysql交互、数据收发上面；后者主要用于日志解析、数据封装上面。

3.1 mysql 通讯协议

mysql通讯协议主要用于mysql客户端与mysql服务端的交互，通讯协议通过SSL加密通讯、数据包压缩通讯、连接阶段的强交互性。

3.1.1 mysql数据包

如果客户端要和服务端交互，他们会把数据打包成数据包的形式然后通过发送数据包的形式，实现信息的传递。数据包的具体格式如下：

例如一个COM_BINLOG_DUMP类型的数据包的payload（数据包体）是这样的：

3.2 mysql 日志协议

binlog日志是一个对于mysql记录各种变化的日志集合，开启日志功能可以通--log-bin 选项来开启。MySQL的二进制日志可以说或是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是失误安全型的.
MySQL的二进制日志的作用是显而易见的，可以方便的备份这些日志以便做数据恢复，也可以作为主从复制的同步文件。

3.2.1 event事件

mysql通过C++的类来描述事件的基本类型 log event，在这里我们可以通过mysql源码的log_event.cc来详细了解 各种各样的event事件类型。log event是一个描述事件的基本类型，更加细致的log event 组成了基本的log event，即log event是可派生的，并派生处了一些描述事件信息更详细的子事件类型。比如row event就是一个母事件类型。在mysql源码中是通过一系列枚举整数值来描述各个事件的，如下所示：

enum Log_event_type { 

  UNKNOWN_EVENT= 0, 

  START_EVENT_V3= 1, 

  QUERY_EVENT= 2, 

  STOP_EVENT= 3, 

  ROTATE_EVENT= 4, 

  INTVAR_EVENT= 5, 

  LOAD_EVENT= 6, 

  SLAVE_EVENT= 7, 

  CREATE_FILE_EVENT= 8, 

  APPEND_BLOCK_EVENT= 9, 

  EXEC_LOAD_EVENT= 10, 

  DELETE_FILE_EVENT= 11, 

  NEW_LOAD_EVENT= 12, 

  RAND_EVENT= 13, 

  USER_VAR_EVENT= 14, 

  FORMAT_DESCRIPTION_EVENT= 15, 

  XID_EVENT= 16, 

  BEGIN_LOAD_QUERY_EVENT= 17, 

  EXECUTE_LOAD_QUERY_EVENT= 18, 

  TABLE_MAP_EVENT = 19, 

  PRE_GA_WRITE_ROWS_EVENT = 20, 

  PRE_GA_UPDATE_ROWS_EVENT = 21, 

  PRE_GA_DELETE_ROWS_EVENT = 22, 

  WRITE_ROWS_EVENT = 23, 

  UPDATE_ROWS_EVENT = 24, 

  DELETE_ROWS_EVENT = 25, 

  INCIDENT_EVENT= 26, 

  HEARTBEAT_LOG_EVENT= 27, 

  ENUM_END_EVENT 

  /* end marker */ 

};

具体各种事件含义的详细说明可以参照mysql官方说明文档：http://dev.mysql.com/doc/internals/en/event-meanings.html

3.2.2 event 事件结构

接下来我们来看看一个通用事件的具体结构（参照mysql packet 数据包）
所有的event 都含有如下通用的事件结构：

+===================+

| event header      |

+===================+

| event data        |

+===================+

分别由时间头和时间体组成。
而事件的内部结构随mysql的版本不同而变化着，这里取出3个代表性的版本结构：

v1 ：用于mysql 3.23

v3 ：用于mysql 4.01

v4 ：用于mysql 5.0 及 以上

v1 的event 结构：

+=====================================+

| event     | timestamp         0 : 4    |

| header  +----------------------------+

|               | type_code         4 : 1    |

|              +----------------------------+

|               | server_id         5 : 4    |

|              +----------------------------+

|               | event_length      9 : 4    |

+=====================================+

| event      | fixed part       13 : y    |

| data       +----------------------------+

|                | variable part              |

+=====================================+

v3 的 event 结构 ：

+=====================================+

| event     | timestamp         0 : 4    |

| header  +----------------------------+

|              | type_code         4 : 1    |

|             +----------------------------+

|              | server_id         5 : 4    |

|             +----------------------------+

|              | event_length      9 : 4    |

|             +----------------------------+

|              | next_position    13 : 4    |

|             +----------------------------+

|              | flags            17 : 2    |

+=====================================+

| event    | fixed part       19 : y    |

| data     +----------------------------+

|             | variable part              |

+=====================================+

v4 的event结构：

+=====================================+

| event     | timestamp         0 : 4    |

| header  +----------------------------+

|              | type_code         4 : 1    |

|             +----------------------------+

|              | server_id         5 : 4    |

|             +----------------------------+

|              | event_length      9 : 4    |

|             +----------------------------+

|              | next_position    13 : 4    |

|             +----------------------------+

|              | flags            17 : 2    |

|             +----------------------------+

|              | extra_headers    19 : x-19 |

+=====================================+

| event     | fixed part        x : y    |

| data      +----------------------------+

|              | variable part              |

+=====================================+

更详细的事件包数据可见：http://dev.mysql.com/doc/internals/en/event-header-fields.html相关页面

4. 位点确认机制

在于mysql的交互过程中发现，xid event通常是作为一个事务的结尾（DML，DDL的话是Query作为结尾），现将DML和DDL的事件组成展示出来（过滤掉一些对解析日志无意义的事件）：
DML：

1. QUERY EVENT

2. TABLE MAP EVENT

3. ROWS EVENT

4. XID EVENT

DDL：

1. QUERY EVENT

这里我们可以通过一定的辨识机制将DDL的QUERY EVENT 和 DML的XID EVENT归为一类，所以我们把这种结束事务的时间统称为特殊xid 事件。从调试中可以得到这样一个推论：
在与mysql交互中，binlog dump线程的起始位点一定要是特殊xid事件的next position的。即特殊xid一定要作为mysql的结束标识，读时候一定要确认这里的位点机制。
所以在tracker重启，重新抓取数据时一定要从xid开始fetch数据，这样就是位点确认机制的由来。
目前的位点确认机制有：

1. mysql的位点确认，必须是以xid位点来确认的，所以checpoint表存储mysql位点信息的数据必须要是特殊xid事件

2. 写event表的checkpoint位点确认，受mysql位点特殊xid的影响，这里checkpoint表中tracker写event表的位点信息也必须是特殊xid的位点信息。（考虑这样一种场景，大事务里面有很多个event，如果tracker在写event表是crash掉了，这样我们可以把大事务的第一个时间a[0] 到发生crash的时间a[i]成为脏数据，为什么呢？？，因为如果重启tracker，他与mysql的交互特性是必须要以xid作为起始位点才开始fetch event数据，所以我们tracker会又从这个大事务的a[0]开始fetch，如果hbase event不以xid作为位点确认，那么这次event表就变成a[0]......a[i] a[0] …..a [j] ，这样a[0]......a[i]成了明确的脏数据，如果是以xid作为tracker写event的位点确认，实际上就是重写了一段a[0]......a[i]的数据，当然你可已在tracker fetch a[0]到a[i]这一段，先不写hbase，到crash的位点再开始写hbase也是可以的。注意这里有无限循环的bug漏洞）

3. 除以上两个的位点，其他位点的确认均采取直接确认，不需要考虑特殊xid事件。

4.1 确认位点分类：

大致有以下几类位点需要确认：

5. tracker设计

依照2.1的流程概要设计，其流程图如下所示：

 这部分可以结合源代码理解（Handler1.java）

1. prepare方法：

1. 建立mysql的两个连接，其中一个连接用于fetch event数据，另外一个连接用于fetch表结构元数据。这里如果创建连接不成功，将一直处于创建连接流程。保证程序的存活不依赖与mysql的存活

2. 建立hbase连接，这里如果hbase没有启动会处于阻塞和重连的状态。

3. 加载起始位点，既有mysql的起始位点也有event表的其实位点，注意这两个位点都是受xid影响的位点，如果hbase没有相关信息，这里我们用show master status的mysql命令，让mysql位点处于本库的最末端，而让event表位点置0，即相当于清除所有数据，从0开始。

4. 启动fetch 线程，开始从mysql主库上fetch event数据。

5. 启动per minute 线程，开始每分中记录相应位点

6. 启动persistence 线程，开始接受fetch到的event数据，并且序列化，然后存入hbase event表中，并且伴随位点确认机制。（注意：这个线程其实就是Handler.run()方法，实际上run（）方法也是一个线程的机制，只不过对Handler是不可见的而已）

2. fetch 线程：

1. preRun方法做一些初始化工作，包括设置binlog dump线程参数、send binlog dump让fetch指针置为到起始位点（start position）、初始化数据抓取器fetcher

2. fetch方法，抓取一条event数据。

3. 加入queue多线程队列中

4. kafka监控相关

5. 这里fetch是一个循环重连的机制，入股fetch方法失败跳出第一层循环，通过外层循环和checkMysqlConn()方法时间fetch线程重连mysql。即如果fetch中途mysql crash掉，fetch线程会等待mysql有效后重连mysql。

3. Per minute 线程：

1. 每分钟执行一次run方法

2. 具体是将得到的存储位点的全局变量存入checkpoint中去。注意row key的设计

4. Persistence 线程 Handler1.run()方法：

1. 接受多线成queue的数据到list中，以此位一批数据，

2. 以数量的上限，下限和时间的阀值来判断时候执行一批数据的持久化

3. 进行持久化。

4. 将一批event数据 序列化 然后 tracker写入到event表中去。

5. 伴随位点确认机制：当真正写入event表数据成功后，看这一批数据是否有特殊xid事件，如果有则作为位点确认，写入checkpoint表中去（tracker整体重启，启动的时候加载这个位点信息）

6. parser 设计

与tracker设计思路基本相同，不过是fetch的目的mysql换成hbase event表，以及位点信息的直接确认，不需要考虑特殊xid。这里不再详述。
注意：所有的位点确认一定要是在持久化成功之后才开始位点确认。

7. 重连机制

tracker中的mysql connector建立过程加入重连与等待机制。
fetch线程中加入了正在fetch数据，mysql突然断掉的重连机制。
hbase的断掉的自身重连机制

8. 性能评测

目前尚未进行系统性的，正式的性能测试。
仅以单机作测试有 每1-2秒 tracker能fetch 1万条数据，parser 每1万条数据 需要耗时4～5秒左右。
本单机测试尚不能作为评测标准，其性能以机器的硬件性能的不同而不同，不能以此作为性能标准。

9. bug与优化

1. 对于巨大事务的海量事件的场景，可能存在潜在的无限循环bug，即到事件a[i] crash掉，然后重启，重新fetch时 到 时间 a[i]再一次crash，然后再重启，这样一直不停地循环，永远扫描不完着一个巨量的大事务。
2. tracker与parser的数据交接目前仍是单线程的模式，可以考虑大规模分布式并行的模式，使tracker与parser在数据交接上能够提升效率（与mysql的交接，与hbase的交接）。

10. 结论

基于单机的，传统的，MySQL解析就到这里，主要是利用了mysql的协议进行数据传递与解析，后面组件考虑基于分布式的，基于大规模并行化的，基于高HA的模式。

11. 项目地址