MySQL 生成binlog的代码分析

https://www.cnblogs.com/jackhub/p/3830683.html

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和刷脏页）