我們知道MySQL 5.7并行復制引入了兩個值last_committed和sequence_number。last_committed表示事務提交的時候，上次事務提交的編號，在主庫上同時提交的事務設置成相同的last_committed。如果事務具有相同的last_committed，表示這些事務都在一組內，可以進行并行的回放。
1）該參數控制mysql 組提交之前等待的微秒數，設置該參數可以讓組提交的每個組里面的事務數更多（因為他等待了n微妙），因為每個組里面的事務可以在從庫并行的去重放，所以設置該參數大于0，有助于提高從庫應用日志的速度，減少從庫延遲
3）當設置sync_binlog=0或sync_binlog=1時，binlog_group_commit_sync_delay指定的延遲將作用于每個事務組提交。當sync_binlog設置為大于1的值n時，該參數的延遲作用于每n個二進制日志提交組提交之間；
基于主鍵的沖突檢測(binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, 修改的row的主鍵或非空唯一鍵沒有沖突，即可并行)
WRITESET: 基于寫集合決定事務依賴（有問題?。?/div>
WRITESET_SESSION:
基于寫集合，但是同一個session中的事務不會有相同的last_committed
事務檢測算法：
transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32
MySQL會有一個變量來存儲已經提交的事務HASH值，所有已經提交的事務所修改的主鍵（或唯一鍵）的值經過hash后都會與那個變量的集合進行對比，來判斷改行是否與其沖突，并以此來確定依賴關系
這里說的變量，可以通過這個設置大?。?binlog_transaction_dependency_history_size
這樣的粒度，就到了 row級別了，此時并行的粒度更加精細，并行的速度會更快，某些情況下，說slave的并行度超越master也不為過(master是單線程的寫，slave也可以并行回放)
二：binlog_group_commit_sync_no_delay_count
|
Property |
Value |
|
Command-Line Format |
--binlog-group-commit-sync-no-delay-count=# |
|
System Variable |
binlog_group_commit_sync_no_delay_count |
|
Scope |
Global |
|
Dynamic |
Yes |
|
Type |
Integer |
|
Default Value |
0 |
|
Minimum Value |
0 |
|
Maximum Value |
1000000 |
該參數必須和binlog_group_commit_sync_delay一起使用才有意義，當已經處于延遲的事務個數達到該參數設置的數的時候，就終止了binlog_group_commit_sync_delay參數設置的微妙延遲（不需要一定要延遲參數binlog_group_commit_sync_delay設置的微妙數），也就是該參數保證同一個組提交的組里面的事務數不能太多！
三：slave_preserve_commit_order
|
Property |
Value |
|
Command-Line Format |
--slave-preserve-commit-order[={OFF|ON}] |
|
System Variable |
slave_preserve_commit_order |
|
Scope |
Global |
|
Dynamic |
Yes |
|
Type |
Boolean |
|
Default Value |
OFF |
1）對于多線程從機，此變量的設置1確保事務在主庫提交的順序與它們在從庫中繼日志中顯示的順序相同，并防止從庫中繼日志執行的事務序列中出現間隙。此變量對未啟用多線程的從機沒有影響。請注意，slave_preserve_commit_order=1不保留非事務性DML更新的順序，因此這些更新可能在中繼日志中它們之前的事務之前提交，這可能會導致間隙；
2）slave_preserve_commit_order=1要求在從機上啟用--log bin和
--log-slave-updates ，并且slave_parallel_type設置為
LOGICAL_CLOCK。在更改此變量之前，必須停止所有復制線程（如果使用多個復制通道，則為所有復制通道）
3）在啟用slave_preserve_commit_order的情況下，sql線程在提交之前等待所有以前的事務提交，
當從線程等待其他工作線程提交其事務時，它會將其狀態報告為:Waiting for preceding transaction to commit,所以如果啟用該參數，那么可能會加劇主從延遲！
4)如果設置slave_preserve_commit_order=0，則slave并行應用的事務可能會無序提交。因此，檢查最近執行的事務并不能保證來自主服務器的所有以前的事務都在從服務器上已經執行（也就是說某你在從庫看到的不是當前的狀態，這不是延遲導致的，而是提交順序不一樣導致的不一致狀態）。在從機的中繼日志中執行的事務序列中可能存在間隙。這對使用多線程應用的從庫的日志記錄和恢復有影響。
四：binlog_order_commits
|
Property |
Value |
|
Command-Line Format |
--binlog-order-commits[={OFF|ON}] |
|
System Variable |
binlog_order_commits |
|
Scope |
Global |
|
Dynamic |
Yes |
|
Type |
Boolean |
|
Default Value |
ON |
該參數控制：
當在復制主機上啟用此變量（這是默認設置）時，向存儲引擎發出的事務提交指令將使用單個線程串行的提交，以便事務始終按寫入二進制日志的相同順序提交。禁用此變量允許使用多個線程發出事務提交指令。
與二進制日志組提交結合使用，可以防止單個事務的提交速率成為吞吐量的瓶頸，因此可能會提高性能（主從都設置）
當所有涉及的存儲引擎都已確認事務已準備好提交時，事務將寫入二進制日志。然后，二進制日志組提交邏輯在二進制日志寫入之后提交一組事務。當binlog_order_commits被禁用時，由于此進程使用多個線程，提交組中的事務可能會以不同于二進制日志中事務順序的順序提交。（來自單個客戶機的事務總是按時間順序提交）在許多情況下，這無關緊要，因為既然組提交中的事務可以并行復制，說明這些事務分開執行是會產生一致性的結果的，否則不能并行復制只能單獨的事務執行了；
建議：在一些不重要的從庫上，可以關閉該參數來提高從庫的復制性能！
五：關于packet 數據包的大?。?/span>
1.slave_pending_jobs_size_max的用途：
在多線程復制時，在隊列中Pending（等待）的事件所占用的最大內存，默認為16M，如果內存富余，或者延遲較大時，可以適當調大;
注意這個值要比主庫的max_allowed_packet大，并且這個參數需要重啟restart slave才能生效，也就是stop slave,start slave才能生效
查看主庫的max_allowed_packet參數！
mysql
> show variables
like
'max_allowed_packet';
-- 134217728 即128M
+
--------------------+-----------+
| Variable_name
| Value
|
+
--------------------+-----------+
| max_allowed_packet
|
134217728
|
+
--------------------+-----------+
2.max_allowed_packet
|
Property |
Value |
|
Command-Line Format |
--max-allowed-packet=# |
|
System Variable |
max_allowed_packet |
|
Scope |
Global, Session |
|
Dynamic |
Yes |
|
Type |
Integer |
|
Default Value |
4194304 |
|
Minimum Value |
1024 |
|
Maximum Value |
1073741824 |
該參數控制mysql限制server接受的數據包大小，需要注意應該設置成正1024的整數倍的k, 因為有些服務器下的mysql由于某些原因可能無法將M轉為k。默認是4m;最大是1g,
該參數設置過大，可能會導致由于某個事務過大，導致主從延遲加??！
set global max_allowed_packet = 2*1024*1024*10 (20m)
3.slave_max_allowed_packet參數
此變量設置slave 的SQL和I/O線程的最大數據包大小，不會因為復制更新超過了允許的最大數據包數，而導致基于行的復制的大型更新失敗。設置此變量將立即對所有復制通道生效，包括正在運行的通道。
此全局變量的值始終是1024的正整數倍；如果將其設置為非正整數倍，則該值將向下舍入到1024的下一個最大倍數，以便存儲或使用；將slave_max_allowed_packet設置為0將使用1024。（在所有這些情況下都會發出截斷警告。）默認值和最大值為1073741824（1 GB）；最小值為1024
|
Property |
Value |
|
Command-Line Format |
--slave-max-allowed-packet=# |
|
System Variable |
slave_max_allowed_packet |
|
Scope |
Global |
|
Dynamic |
Yes |
|
Type |
Integer |
|
Default Value |
1073741824 |
|
Minimum Value |
1024 |
|
Maximum Value |
1073741824 |
