MySQL5.7 簡述新的複制模式LOGICAL_CLOCK

我們知道，在mysql5.6中引入了并行複制模式，當執行個體上有多個庫的時候，可以在備庫上對這幾個庫進行并發操作；這在基于分庫的應用場景下，可以顯著提升備庫的複制效率，但對于我們以分表為主的場景，則效果甚微。

mysql5.7.2是最新的開發版本release，在該版本中可以看到對複制部分做了非常大的改動，例如半同步複制的after sync， 使用performance schema表來監控複制線程，實驗室版本的多主複制，以及本文要提到的新的多線程複制模式，mysql裡用一個新的參數來控制：slave_parallel_type，預設值為database，表示預設行為；另外一個值為logical_clock，即為新增的模式

1.基本思路

由于mysql存儲引擎層已經保證了同時能夠進入事務prepare/commit階段的事務是沒有沖突的（例如innodb的行鎖機制來保證事務的排程），那麼可以認為在同時進入prepare階段的事務是可以在備庫并發執行的，因為他們互相沒有沖突；

logical_clock是一個全局遞增的64位長整型數字，主要通過它來判斷哪些事務能夠并發；

a.配置設定

在二階段送出的binlog prepare階段進行配置設定

   binlog_cache_mngr *const cache_mngr= thd_get_cache_mngr(thd); cache= cache_mngr->get_binlog_cache_log(all); if (cache->commit_seq_no == seq_uninit) cache->commit_seq_no= mysql_bin_log.commit_clock.get_timestamp(); }

在之前版本中binlog_prepare函數都是空函數

b.寫入

logical_clock隻有記錄到binlog中，才能為備庫所用，在将每個線程cache的binlog寫入時，調用函數write_commit_seq_no，每組事務的第一個事件才記錄logical_clock

具體的存儲位置，可以閱讀函數gtid_log_event::gtid_log_event()

c.遞增

mysql的group commit有三個階段，flush_stage, sync_stage, 以及commit_stage，遞增logical_clock發生在第二階段結束之後，第三階段開始之前，這時候sync階段的leader還沒有釋放lock_sync。

7300   mysql_bin_log.commit_clock.step(); 7301   if (opt_binlog_order_commits) 7302   { 7303     if (change_stage(thd, stage_manager::commit_stage, 7304

這裡并不是嚴格要求所有同時進入prepare階段的事務都在備庫并發執行，是以一組送出的事務中可能存在不同的seq no

更具體的可以閱讀如下連結：

開發人員部落格也詳細的如何配置step by step：

<a href="http://geek.rohitkalhans.com/2013/09/enhancedmts-configuration.html">http://geek.rohitkalhans.com/2013/09/enhancedmts-configuration.html</a>

以及實作的原理

<a href="http://geek.rohitkalhans.com/2013/09/enhancedmts-deepdive.html">http://geek.rohitkalhans.com/2013/09/enhancedmts-deepdive.html</a>