二：Mysql 5.7并行復制相關的參數 一般主從延遲太大，要不是沒有主鍵，要不是配置的不合理 依次介紹些這些參數的作用，以及設置途徑 binlog_group_commit_sync_delay binlog_group_commit_sync_no_delay_count max_allowed_packet slave_max_allowed_packet slave_preserve_commit_order slave_pending_jobs_size_max 一：binlog_group_commit_sync_delay ： Property Value Command-Line Format --binlog-group-commit-sync-delay=# System Variable binlog_group_commit_sync_delay Scope Global Dynamic Yes Type Integer Default Value 0 Minimum Value 0 Maximum Value 1000000 1）該參數控制mysql 組提交之前等待的微秒數，設置該參數可以讓組提交的每個組里面的事務數更多（因為他等待了n微妙），因為每個組里面的事務可以在從庫并行的去重放，所以設置該參數大于0，有助于提高從庫應用日志的速度，減少從庫延遲 設置binlog_group_commit_sync_delay可以增加從庫的并行提交事務數，因此可以增加復制從屬服務器上的并行執行能力。要受益于此效果，從屬服務器必須設置slave_parallel_type=LOGICAL_CLOCK，并且在還設置binlog_transaction_dependency_tracking=COMMIT_ORDER時效果更顯著。在調整binlog_group_commit_sync_delay的設置時，必須同時考慮主設備的吞吐量和從設備的吞吐量。 2）但是設置binlog_group_commit_sync_delay會增加主服務器上事務的延遲，這可能會影響客戶端應用程序。此外，在 高度并發的工作負載上，可能會增加爭用，從而降低吞吐量，導致數據庫性能降低，還能在錯誤日志中看到很多RECORD LOCK信息， 3）當設置sync_binlog=0或sync_binlog=1時，binlog_group_commit_sync_delay指定的延遲將作用于每個事務組提交。當sync_binlog設置為大于1的值n時，該參數的延遲作用于每n個二進制日志提交組提交之間； 建議：該參數設置一定要結合實際情況，評估出mysql的并發量，計算出單位時間內的并發量，然后合理設置binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count（單位時間每組的事務數） ，一定要限制每個組的事務個數，因為如果不設置的話，如果你的實際并發量挺大，這就會導致你的每個組的事務數可能非常多，然后我們知道組提交的commit階段是分三個步驟的，每個階段都是有隊列的，如果每個組太多事務，就會導致內存隊列不夠用，而使用臨時文件，這樣就降低了commit的性能，造成更多的延遲， 所以要使用 binlog_group_commit_sync_no_delay_count 來限制你的每個組的事務數，這樣就能盡可能多的把同一個組的事務數增多，但是也不至于太多，限制在一個合理的范圍，這些事務可以在從庫并發執行，而如果不設置的話，那么這些事務可能有很多是串行的， 也有可能事務太多導致性能降低而產生更多的延遲！ 拓展參數 binlog_transaction_depandency_tracking： 控制檢測是不是可以并行復制的方式， 基于主鍵的沖突檢測(binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, 修改的row的主鍵或非空唯一鍵沒有沖突，即可并行) 5.7.22 也支持了 write-set 機制 事務依賴關系： binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION COMMIT_ORDERE: 繼續基于組提交方式 WRITESET: 基于寫集合決定事務依賴（有問題！） 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 數據包的大小： 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
