建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
mysql基于組提交的并發(fā)復制小結
一：MySQL 5.7并行復制初理解
我們知道MySQL 5.7并行復制引入了兩個值last_committed和sequence_number。last_committed表示事務提交的時候，上次事務提交的編號，在主庫上同時提交的事務設置成相同的last_committed。如果事務具有相同的last_committed，表示這些事務都在一組內(nèi)，可以進行并行的回放。
查看組提交的事務個數(shù),其中9892是last_commited的值，相同的last_commited值，后面的sequnen ce_number是可以并行復制的事務的一個序列號，新的binlog文件是從1開始的，給gtid的xid沒有關系！
cat binlog.log | grep GTID | grep last_committed | grep 19408
二：造成延遲的原因：
表沒有主鍵，事務太大，并行力度不夠,參數(shù)設置不合適，從庫硬件差
二：Mysql 5.7并行復制相關的參數(shù)
一般主從延遲太大，要不是沒有主鍵，要不是配置的不合理
依次介紹些這些參數(shù)的作用，以及設置途徑
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）該參數(shù)控制mysql 組提交之前等待的微秒數(shù)，設置該參數(shù)可以讓組提交的每個組里面的事務數(shù)更多（因為他等待了n微妙），因為每個組里面的事務可以在從庫并行的去重放，所以設置該參數(shù)大于0，有助于提高從庫應用日志的速度，減少從庫延遲
設置binlog_group_commit_sync_delay可以增加從庫的并行提交事務數(shù)，因此可以增加復制從屬服務器上的并行執(zhí)行能力。要受益于此效果，從屬服務器必須設置slave_parallel_type=LOGICAL_CLOCK，并且在還設置binlog_transaction_dependency_tracking=COMMIT_ORDER時效果更顯著。在調(diào)整binlog_group_commit_sync_delay的設置時，必須同時考慮主設備的吞吐量和從設備的吞吐量。
2）但是設置binlog_group_commit_sync_delay會增加主服務器上事務的延遲，這可能會影響客戶端應用程序。此外，在
高度并發(fā)的工作負載上，可能會增加爭用，從而降低吞吐量，導致數(shù)據(jù)庫性能降低，還能在錯誤日志中看到很多RECORD LOCK信息，
3）當設置sync_binlog=0或sync_binlog=1時，binlog_group_commit_sync_delay指定的延遲將作用于每個事務組提交。當sync_binlog設置為大于1的值n時，該參數(shù)的延遲作用于每n個二進制日志提交組提交之間；
建議：該參數(shù)設置一定要結合實際情況，評估出mysql的并發(fā)量，計算出單位時間內(nèi)的并發(fā)量，然后合理設置binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count（單位時間每組的事務數(shù)） ，一定要限制每個組的事務個數(shù)，因為如果不設置的話，如果你的實際并發(fā)量挺大，這就會導致你的每個組的事務數(shù)可能非常多，然后我們知道組提交的commit階段是分三個步驟的，每個階段都是有隊列的，如果每個組太多事務，就會導致內(nèi)存隊列不夠用，而使用臨時文件，這樣就降低了commit的性能，造成更多的延遲， 所以要使用 binlog_group_commit_sync_no_delay_count 來限制你的每個組的事務數(shù)，這樣就能盡可能多的把同一個組的事務數(shù)增多，但是也不至于太多，限制在一個合理的范圍，這些事務可以在從庫并發(fā)執(zhí)行，而如果不設置的話，那么這些事務可能有很多是串行的， 也有可能事務太多導致性能降低而產(chǎn)生更多的延遲！
拓展參數(shù) 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: 繼續(xù)基于組提交方式
WRITESET: 基于寫集合決定事務依賴（有問題?。?/div>
WRITESET_SESSION:
基于寫集合，但是同一個session中的事務不會有相同的last_committed
事務檢測算法：
transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32
MySQL會有一個變量來存儲已經(jīng)提交的事務HASH值，所有已經(jīng)提交的事務所修改的主鍵（或唯一鍵）的值經(jīng)過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 |
該參數(shù)必須和binlog_group_commit_sync_delay一起使用才有意義，當已經(jīng)處于延遲的事務個數(shù)達到該參數(shù)設置的數(shù)的時候，就終止了binlog_group_commit_sync_delay參數(shù)設置的微妙延遲（不需要一定要延遲參數(shù)binlog_group_commit_sync_delay設置的微妙數(shù)），也就是該參數(shù)保證同一個組提交的組里面的事務數(shù)不能太多！
三：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確保事務在主庫提交的順序與它們在從庫中繼日志中顯示的順序相同，并防止從庫中繼日志執(zhí)行的事務序列中出現(xiàn)間隙。此變量對未啟用多線程的從機沒有影響。請注意，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線程在提交之前等待所有以前的事務提交，
當從線程等待其他工作線程提交其事務時，它會將其狀態(tài)報告為:Waiting for preceding transaction to commit,所以如果啟用該參數(shù)，那么可能會加劇主從延遲！
4)如果設置slave_preserve_commit_order=0，則slave并行應用的事務可能會無序提交。因此，檢查最近執(zhí)行的事務并不能保證來自主服務器的所有以前的事務都在從服務器上已經(jīng)執(zhí)行（也就是說某你在從庫看到的不是當前的狀態(tài)，這不是延遲導致的，而是提交順序不一樣導致的不一致狀態(tài)）。在從機的中繼日志中執(zhí)行的事務序列中可能存在間隙。這對使用多線程應用的從庫的日志記錄和恢復有影響。
四：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 |
該參數(shù)控制：
當在復制主機上啟用此變量（這是默認設置）時，向存儲引擎發(fā)出的事務提交指令將使用單個線程串行的提交，以便事務始終按寫入二進制日志的相同順序提交。禁用此變量允許使用多個線程發(fā)出事務提交指令。
與二進制日志組提交結合使用，可以防止單個事務的提交速率成為吞吐量的瓶頸，因此可能會提高性能（主從都設置）
當所有涉及的存儲引擎都已確認事務已準備好提交時，事務將寫入二進制日志。然后，二進制日志組提交邏輯在二進制日志寫入之后提交一組事務。當binlog_order_commits被禁用時，由于此進程使用多個線程，提交組中的事務可能會以不同于二進制日志中事務順序的順序提交。（來自單個客戶機的事務總是按時間順序提交）在許多情況下，這無關緊要，因為既然組提交中的事務可以并行復制，說明這些事務分開執(zhí)行是會產(chǎn)生一致性的結果的，否則不能并行復制只能單獨的事務執(zhí)行了；
建議：在一些不重要的從庫上，可以關閉該參數(shù)來提高從庫的復制性能！
五：關于packet 數(shù)據(jù)包的大?。?/div>
當前題目：mysql基于組提交的并發(fā)復制小結
網(wǎng)站地址：http://www.dlmjj.cn/article/pecpcd.html
1.slave_pending_jobs_size_max的用途：
在多線程復制時，在隊列中Pending（等待）的事件所占用的最大內(nèi)存，默認為16M，如果內(nèi)存富余，或者延遲較大時，可以適當調(diào)大;
注意這個值要比主庫的max_allowed_packet大，并且這個參數(shù)需要重啟restart slave才能生效，也就是stop slave,start slave才能生效
查看主庫的max_allowed_packet參數(shù)！
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 |
該參數(shù)控制mysql限制server接受的數(shù)據(jù)包大小，需要注意應該設置成正1024的整數(shù)倍的k, 因為有些服務器下的mysql由于某些原因可能無法將M轉為k。默認是4m;最大是1g,
該參數(shù)設置過大，可能會導致由于某個事務過大，導致主從延遲加劇！
set global max_allowed_packet = 2*1024*1024*10 (20m)
3.slave_max_allowed_packet參數(shù)
此變量設置slave 的SQL和I/O線程的最大數(shù)據(jù)包大小，不會因為復制更新超過了允許的最大數(shù)據(jù)包數(shù)，而導致基于行的復制的大型更新失敗。設置此變量將立即對所有復制通道生效，包括正在運行的通道。
此全局變量的值始終是1024的正整數(shù)倍；如果將其設置為非正整數(shù)倍，則該值將向下舍入到1024的下一個最大倍數(shù)，以便存儲或使用；將slave_max_allowed_packet設置為0將使用1024。（在所有這些情況下都會發(fā)出截斷警告。）默認值和最大值為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 |
當前題目：mysql基于組提交的并發(fā)復制小結
網(wǎng)站地址：http://www.dlmjj.cn/article/pecpcd.html
