bug背景

    官方最近发布的版本(5.7.5)修复了这样一个bug，主备复制场景下，如果主库和备库对应的表结构中有数据类型不一致，并且主库的 binlog 是 row 格式的，这时候如果主库对不一致的表做了一个大事务更新，备库在应用 relay-log 的时候报OOM(Out of Memory)。bug地址在这里，主备数据类型不一致主要发生在这2种情况下：

    主备库版本不一致，不同版本之间的数据类型可能存在不一致。用户在报这个bug时，就是在5.5到5.6的复制场景下，用到了时间类型，时间类型在5.6.4版本时发生了变化 人为直接的连上从库 alter 表

    bug分析

    为啥数据类型不一致会导致 OOM 呢？OOM 表示程序在持续申请内存，把内存给用爆了。从库的slave thread在应用Rows_log_event时，如果发现主库的表和从库的表不兼容，就会创建一个临时中间表，做数据转化：

    1. Rows_log_event::do_apply_event()
    2. table_def::compatible_with()
    3. table_def::create_conversion_table()
    4. create_conversion_table()

    在此过程中用的临时表结构和field字段都是从thd的mem_root分配的，而每个Rows_log_event应用时分配内存空间再do_apply_event后就不会再用了，但是 Rows_log_event::do_apply_event() 结束后并没有free_root释放，而是在事务所有event做完后释放的。类似下面这种包含大量更新语句的事务，每一个更新对应一个Rows_log_event，备库在应用时，在事务执行中间所有申请的内存都会保持，如果语句非常多的话，就导致OOM了。

    1. begin;
    2. insert into t1 values (xxx); /* 1 */
    3. insert into t1 values (xxx); /* 2 */
    4. insert into t1 values (xxx); /* 3 */
    5. ....
    6. insert into t1 values (xxx); /* 1000000 */
    7. end;

    bug 修复

    像 Query_log_event::do_apply_event() 在结束会调用free_root，来释放thd->mem_root空间，而Rows_log_event::do_apply_event()却不能这样干，因为在下面的场景下，用户的线程会调用 Rows_log_event::do_apply_event()

    1. mysqlbinlog mysql-bin.00000x | mysql -hxxxx -Pxx -u

    如果在中间释放用户线程的thd->mem_root的话，会有问题。

    因此官方的修复方法是在Log_event类构造函数初始化一个属于log_event的 mem_root

    1. Log_event::Log_event()
    2. init_sql_alloc(PSI_INSTRUMENT_ME, &m_event_mem_root, 4096, 0);

    在析构函数里释放

    1. virtual ~Log_event()
    2. free_root(&m_event_mem_root, MYF(MY_KEEP_PREALLOC));

    然后把Rows_log_event::do_apply_event()本来从thd->mem_root申请的内存改为从自身的 m_event_mem_root 申请，这样每个event应用完，被delete时其转化过程中申请的内存也一并被释放，避免了OOM的产生。