mysql主從同步的時候，為什么主是順序寫binlog但是從庫卻是隨機讀取的？
有大佬來告知一下嘛，是mysql特定好就是這樣的，還是可以設定的？
萬分感謝
uj5u.com熱心網友回復：
備庫并行復制能力協調器coordinator就是之前的sql_thread，現在只負責讀取中繼中日志和分發事務，真正更新日志的變成了worker執行緒，而worker執行緒的個數由引數slave_parallel_workers決定的，在分發事務時滿足以下兩個基本原則：
1、不能造成更新覆寫，這就要求更新同一行的兩個事務必須分發到同一個worker中
2、同一個事不能被拆開，必須放到同一個worker中
相比于按表并行分發策略，按行并行策略在決定執行緒分發的時候，需要消耗更多的計算資源。約束條件:
1、要能夠從binlog里面決議出表名，主鍵值和唯一索引的值，也就是主庫的binlog格式是row
2、表必須有主鍵
3、不能有外鍵，表上如果有外鍵，級聯更新的行不會記錄在binlog中，這樣沖突檢測不準確
這三條約束就是DBA要求業務開發人員必須遵守的線上使用規范。
mysql 5.6支持按庫并行復制。有兩個優勢
1、構造hash值的時候很快，只需要庫名；而且一個實體上db數也不會很多，不會有100萬個
2、不要求binlog的格式,因為statement格式binlog也可能很容易拿到庫名
mariaDB并行復制策略
1、能夠在同一組提交的事務，一定不會修改同一行；
2、主庫上可以并行執行的事務，備庫上可一定是可以并行執行的。
邏輯如下：
1、在一組里面一起提交的事務，有一個相同的commit_id，下一組就是commit_id+1
2、commit_id直接寫到binlog里面
3、傳到備庫應用的時候，相同的commit_id的事分發到多個worker執行
4、這一組全部執行完成后，coordinator再去取下一批
mysql5.7并行復制策略，由引數slave-parallel-type來控制并行復制策略
1、配置為database，表示使用mysql5.6版本的按庫并行策略
2、配置為logical_clock，表示的就是類似mariaDB的策略，不過mysql 5.7這個策略針對并行度做了優化：同時處于執行狀態的所有事務是不可能并行執行的。
在兩階段提交程序中，只能夠達到redolog prepare階段，就表示事務已經通過鎖沖突的檢驗了。
mysql 5.7并行復制策略思想是:
1、同時處于prepare狀態的事務在備是可以并行
2、處于prepare狀態的事務，與處于commit狀態的事務之間，在備庫執行時也是可以并行的。
binlog組提交有兩個引數：
binlog_group_commit_sync_delay表示延遲多少微秒后才呼叫fsync
binlog_group_commit_sync_no_delay_count表示累積多少次以后才呼叫fsync
這兩個引數是故意拉長binlog從write到fsync的時間，以減少寫盤的次數，在這里可以用來制造更多的處于prepare階段的事務，這樣就增加了備庫復制的并行度。這兩個引數既可以主庫提交慢些，也可以讓備庫執行的快些。
mysq 5.7.22增加并行復制策略，基于wirteset的并行復制，相應的增加一個引數binlog_transaction_dependency_tracking用來控制是否啟用這個新策略
1、commit_order，表示就是前面介紹的根據同時進行prepare和commit來判斷是否可并行的策略
2、writeset表示的是對于事務涉及更新的每一行計算出這一行的hash值，組成集合writeset。如果兩個事務沒有操作相同的行，也就是說它們的writeset沒有交集，就可以并行。
3、writeset_session，是在wrieset的基礎上多了一個約束，即在主庫上同一個執行緒先后執行的兩個事務在備庫執行的時候，要保證相同的先順序。
hash值是通過庫名+表名+索引名+值 計算出來的。
相比mysql 5.5的按行分發策略有如下優勢
1、writeset是在主庫生成后直接寫入到binlog里面的,這樣在備庫執行的時候不需要決議binlog內容，（event的行資料），節省了很多計算量
2、不需要把整 個事務的binlog都掃一遍才能決定分發哪個worker，更節省記憶體
3、由于備庫的分發策略不依賴于binlog內容，所以binlog是statement格式也是可以的。
uj5u.com熱心網友回復：
是不是復制型別的原因轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/14988.html
標籤：MySQL