**背景** MySQL 5.6.6 版本新加了這樣一個參數——log_bin_use_v1_row_events，這個參數用來控制binlog中Rows_log_event的格式，如果這個值為1的話，就用v1版的Rows_log_event格式（即5.6.6之前的），默認是0，用新的v2版本的格式，更詳細看[官方文檔](http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_log_bin_use_v1_row_events)。這個參數一般保持默認即可，但是當我們需要搭 5.6->5.5 這要的主備的時候，就需要把主庫的這個值改為1，不然5.5的備庫不能正確解析Rows_log_event。最近在使用這個參數的時候發現了一個bug，導致主庫binlog寫壞，備庫復制中斷，報錯如下： Last_SQL_Errno: 1594 Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. **bug 分析** binlog event 結構 ~~~ event header event body -fixed part(postheader) -variable part (payload) ~~~ 如上所示，每種binlog event 都可以分為header 和 body 2部分，body 又可以分為 fixed part 和 variable part，其中event header的長度相同并且固定，5.0開始用的v4格式的binlog，其event header固定長度為19字節，包含多個字段，具體每個字段的含義可以看[這里](http://dev.mysql.com/doc/internals/en/event-structure.html)。 event body 中post header 長度也是固定的，所以叫 fixed part，但是不同類型event這一部分的長度不一樣，最后的 variable part 就是event的主體了，這個就長度不一了。 log_bin_use_v1_row_events 這個值的不同，影響的部分就是 postheader 這里的長度，如果值為1的話，用v1格式，postheader 長度是8個字節，如果是0，用v2格式，其長度為10。每個Rows_log_event的event header的type字節會標明當前event是v1還是v2，試想一下，如果event header部分標明是v2，postheader卻實際上只有8個字節，或者反過來，event header部分標明是v1，postheader有10個字節，備庫拿到這樣的binlog，去嘗試解析的時候，就完全凌亂了。 為啥會出現這種一個event前后不一致的情況呢，代碼編寫不嚴謹！ 在寫 Rows_log_event(Write/Update/Delete) 過程中，有2次用到 log_bin_use_v1_row_events 這個全局變量，一次是在構造函數處，一次是在寫postheader時 Rows_log_event::write_data_header()，2次都是直接使用，如果正好在這2次中間，我們執行 set global log_bin_use_v1_row_events = 0|1，改變原來的值，就會導致前后邏輯判斷結果不一致。如果主庫有頻繁的更新操作，每次更新又比較大，只要修改這個值，就很容易觸發這個bug。 另外官方還有點不嚴謹的是，[文檔上](http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_log_bin_use_v1_row_events)說這個值是 readonly的，實際代碼是dynamic 的，如果是 readonly 的話，也就不會觸發上面的bug了。 **bug修復** 修復很簡單，把2次引用全局變量改成一次就好了，在Rows_log_event::write_data_header函數里直接使用已經保存的m_type，改法如下 ~~~ - if (likely(!log_bin_use_v1_row_events)) + + + if (likely(!(m_type == WRITE_ROWS_EVENT_V1 || + m_type == UPDATE_ROWS_EVENT_V1 || + m_type == DELETE_ROWS_EVENT_V1 ))) ~~~ 這樣改之后，就只會在構造函數中才用到全局變量。