--MySQL如何记录binlog
-------------------------------2014/07/08
binlog文件的内容 log event
MySQL的binlog文件中记录的是对数据库的各种修改操作，用来表示修改操作的数据结构是Log event。不同的修改操作对应的不同的log event。比较常用的几种log event有：Query event、Row event、Xid event等。其中Query event对应的是一条SQL语句，在DDL操作和STMT格式的binlog中用的比较多。Row event是个基础类，它的派生类有Row insert event、Row update event、Row delete event三种，分别对应ROW格式binlog的增、改、删操作。Xid event 对应的是支持事务的commit操作，对于不支持事务的commit操作，记录的形式是Query event。其他还有一些event，比如Format log event、Rotate event等等，可以查看MySQL的官方文档了解更多相关信息。log event的种类一直在增加，比如InnoSQL中新增的checkpoint event等。要MySQL本身就留有接口以便新增一个Log event，但是新增一个Log event时需要实现几个必要的方法函数，比如print、write、get_code_type等。binlog文件的内容就是各种Log event的集合。
产生Log event
事务在执行DDL，或则update等操作时会记录操作的event到线程的cache_mngr中。
1，执行DDL操作会在db的操作函数中记录event，这些函数有：mysql_upgrade_db,mysql_alter_db，mysql_rm_db等。其他的DDL操作会调用函数write_bin_log来记录binlog。
2，执行修改操作的DML语句会根据binlog格式的不同做不同的操作。若binlog格式是STMT，则记录event的函数是binlog_query,该函数所做的事情是：
1，根据DML操作语句构造一个Query event:
Query_log_event qinfo(this,query_arg,query_len, ...)
2，将event写入缓存中
mysql_bin_log.write(&qinfo)
调用binlog_query的函数有：mysql_insert，mysql_delete，mysql_update等.
3，若binlog格式是ROW，修改操作的DML语句记录event的过程会调用binlog_log_row，每一条行的修改记录一个Row event，所以调用binlog_log_row
的都是对单个行进行修改的引擎层接口函数：ha_write_row、ha_update_row、ha_delete_row。
函数binlog_log_row会根据行操作的具体类型分别调用三个不同的函数：binlog_write_row、binlog_update_row、binlog_delete_row。
这三个函数的功能是：构造相应的Row event，并将行的数据写入到Row event中。
具体过程是：
binlog_write_row
1，binlog_prepare_pending_rows_event(table, server_id, cols，...);
2，ev->add_row_data(row_data, len);
binlog_update_row
1，ev= binlog_prepare_pending_rows_event(table, server_id, cols，...);
2，ev->add_row_data(before_row, before_size)
ev->add_row_data(after_row, after_size)
binlog_delete_row
1，ev= binlog_prepare_pending_rows_event(table, server_id, cols，...);
2，ev->add_row_data(row_data, len);
新构造的Row event会在下一次记录event的时候写入到线程的缓存区中。
IO_CACHE
写binlog的过程都是缓存写，使用的缓存结构是IO_CACHE。
cache_mngr，cache_data
事务在执行过程中产生log event，这些Log event记录在线程相关的一块缓冲区中，每一个事务线程都有这样一个缓存块（前提是事务开启了记录binlog的功能），这块缓存区的名称是binlog_cache_mngr，结构如下：
class binlog_cache_mngr {
binlog_cache_data stmt_cache; //不支持事务的存储引擎使用的binlog缓存区
binlog_cache_data trx_cache; //支持事务的存储引擎使用的binlog缓存区
。。。
}
Log event保存在cache_mngr的缓存结构cache_data中，cache_data内有一个IO_CACHE缓存空间，Log event实际写入到这个IO_CACHE中binlog_cache_data的结构如下：
class binlog_cache_data{
IO_CACHE cache_log;
。。。
}
事务执行完一个修改操作后，写相应的Log event到线程缓存区的过程是：
1)，获得线程的cache_mngr指针：
cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(thd, binlog_hton);
2)，获得cache_data缓存区的指针：
cache_data= cache_mngr->get_binlog_cache_data(use_trans_cache(thd, is_transactional));
3)，将event写入到IO_CACHE中：
IO_CACHE *file= &cache_data->cache_log;
event->write(file);
写binlog
一个事务在提交阶段会将产生的log event写入到外部binlog文件中。不同事务以串行的方式将log event写入到外部binlog文件中，所以一个事务的所有log event在binlog文件中是连续的，中间不会插入任何其他事务的log event。MySQL整体是一个插件式的结构，binlog也是作为一个引擎插件被上层调用，事务提交的时候MySQL上层会依次调用事务所有引擎的提交接口，binlog的提交接口第一个被调用，然后再调用其它引擎的提交接口。所以事务提交的时候是先写binlog然后再进行底层引擎的提交过程（如InnoDB提交过程的写redo log和刷脏页）