mysql主从复制源码分析(3)

handle_slave_sql比较复杂，设计到主从复制的核心问题，要读懂这块代码，需要一些储备知识：

mysql 主从之间是通过dump协议来交互数据的，dump协议的数据传输包括很多种类型的event

下面列出重要的几个事件，其他事件可以查看官方协议文档：

ROTATE_EVENT ：binlog 切换事件，通知slave要切换新的BINLOG了

XID_EVENT： 记录了一个事务提交的相关信息。

BINLOG的格式可以设置为STATEMENT和ROW的方式，这个可以从mysql 配置文件中设置。

对应不同的设置会产生不同的事件：

QUERY_EVENT：当设置为STATEMENT情况下产生，DML会记录为原始的SQL。

TABLE_MAP_EVENT：记录本次更新的表table_id和表结构信息

WRITE_ROWS_EVENT：row模式，当insert的时候，mysql master会将原始sql插入的数据一行一行写入binlog

UPDATE_ROWS_EVENT：row模式，当update的时候，mysql master会将原始sql更新的数据一行一行写入binlog

DELETE_ROWS_EVENT：

UPDATE_ROWS_EVENT：row模式，当delete的时候，mysql master会将原始sql删除的数据一行一行写入binlog

先简单说下mysql slave做的事情：

handle_slave_sql启动后先启动了一堆worker，然后就开始读relay_log了，

碰到相应的事件就转发到相应的worker处理，注意转发规则是根据内部一张hash表，key就是db，所以其实mysql是根据本次事件db名字找相应的worker处理。

当然有些事件是handle_slave_sql线程自己来处理的，比如 rotate_event，如果是没有开启并行复制模式的话，所有的事件也都是他自己做的。

再来说下worker的事件处理方法，如果worker碰巧收到的事件是query_event也就是一个sql语句，那处理流程基本就跟master收到这个sql处理流程是一样的，但是如果是row模式，mysql就直接调用引擎层的接口来处理了，直接插入到存储引擎。