MySQL並行複製

1、介紹

在官方的 5.6 版本以前，MySQL 只支持單線程複製，由此在主庫併發高、TPS 高時就會出現嚴重的主備延遲問題。

若是備庫執行日誌的速度持續低於主庫生成日誌的速度，那麼主從延遲就有可能成了小時級別。並且對於一個壓力持續比較高的主庫來講，備庫極可能永遠都追不上主庫。

1>MySQL 5.6版本的並行複製策略

官方 MySQL5.6 版本，支持了並行複製，只是支持的粒度是按庫並行。這個策略的並行效果，取決於壓力模型。若是在主庫上有多個 DB，而且各個 DB 的壓力均衡，使用這個策略的效果會很好。

優勢：實現邏輯簡單，binlog格式同時支持statement和row。

缺點：若是熱點數據在同一個DB，則沒有並行效果了。另外在企業級架構設計時，DBA會用多實例單庫的模式來分解多個DB的並行壓力。

2>MySQL 5.7版本的並行複製策略

在官方的 MySQL5.7 版本中，由參數 slave-parallel-type 來控制並行複製策略：

1. 配置爲 DATABASE，表示使用 MySQL 5.6 版本的按庫並行策略；
2. 配置爲 LOGICAL_CLOCK，表明 MySQL 5.7 這個引入的新的並行策略。

原理：redo log組提交（group commit）策略，爲同一組一塊兒提交的事務維護一個commit_id,並寫入binlog日誌。日誌傳到備庫後，coordinator會以輪詢的方式將相同commit_id的事務分發到多個worker執行，待一組執行完成後，再取下一批。

MySQL 5.7.22 版本里，MySQL 增長了一個新的並行複製策略，基於 WRITESET 的並行複製。新增了一個參數 binlog-transaction-dependency-tracking，用來控制是否啓用這個新策略，默認爲commit_order，即上面介紹的這種。

2、開啓並行複製

slave_parallel_type = LOGICAL_CLOCK

slave_parallel_workers = 8

binlog_transaction_dependency_tracking=COMMIT_ORDER

注意

在MySQL 5.7.22中，默認binlog_transaction_dependency_tracking=commit_order,可是slave_parallel_type=database，此時咱們以slave_parallel_type=database爲準。

3、優化選項

1>設置併發線程數

slave_parallel_workers

建議把這個值設置爲 8~16 之間最好（32 核物理機的狀況），畢竟備庫還有可能要提供讀查詢，不能把 CPU 都吃光了。

2>binlog組提交控制

binlog_group_commit_sync_delay 參數，表示延遲多少微秒後才調用 fsync;

binlog_group_commit_sync_no_delay_count 參數，表示累積多少次之後才調用 fsync。

這兩個參數是用於故意拉長 binlog 從 write 到 fsync 的時間，以此減小 binlog 的寫盤次數。在 MySQL 5.7 的並行複製策略裏，它們能夠用來製造更多的「同時處於 prepare 階段的事務」。這樣就增長了備庫複製的並行度。

也就是說，這兩個參數，既能夠「故意」讓主庫提交得慢些，又可讓備庫執行得快些。在 MySQL 5.7 處理備庫延遲的時候，能夠考慮調整這兩個參數值，來達到提高備庫複製併發度的目的。