并發(fā)復制(Parallel Replication) 系列三:MySQL 5.7和MariaDB 10的parallel
replication對比
作者:沃趣科技MySQL數(shù)據庫工程師 麻鵬飛
創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供巴東網站建設、巴東做網站、巴東網站設計、巴東網站制作等企業(yè)網站建設、網頁設計與制作、巴東企業(yè)網站模板建站服務,十載巴東做網站經驗,不只是建網站,更提供有價值的思路和整體網絡服務。
經過上兩篇關于MySQL/MariaDB 的Binary Log Group Commit的發(fā)展歷程和enhanced multi-threaded slave的介紹,相信大家對MySQL 基于Binay Log 的replication的原理以及為了解決主備數(shù)據復制延遲問題而引入的enhanced multi-threaded slave 功能,支持從庫多線程并發(fā)回放主庫提交的事務有了更深入的了解。同時為了更好的發(fā)揮MySQL 5.7/MariaDB 10 并發(fā)復制的性能,兩個版本都在主庫Binary Log Group Commit的階段做了更加深入的優(yōu)化。
無論是MySQL還是MariaDB在Binary Log Group Commit優(yōu)化的目的都是:使高并發(fā)下的事務盡可能的在同一個時間點提交,然后用一次fsync()的操作將這一組的Binary log緩存的數(shù)據寫入磁盤。當并發(fā)事務可以在同一個時間提交,說明每個線程所執(zhí)行的事務之間沒有鎖沖突(如果有鎖沖突,并發(fā)的事務將無法在同一個時刻提交),那么意味著這一組并發(fā)提交的事務在slave機器上能并發(fā)重放主庫提交的事務,所以我們只需要在master機器對二進制日志進行Group Commit的時候標記上組提交相關信息,slave機器就可以安全的并發(fā)執(zhí)行主庫提交的事務。
我們來看一個例子:
事務T1、T2(start transaction)開始事務,落后于事務T3、T4的(start transaction)開始時間,但是這一組事務都在C(commit)時間點提交事務,所以這一組事務(T1、T2、T3、T4)將在master機器上進行Binary Log group Commit,然后該二進制日志推送到slave機器上時可以并發(fā)執(zhí)行這一組被標記的事務。原理:
從上面的例子可以看出,并發(fā)線程執(zhí)行不同的事務只要在同一時刻能夠commit(說明線程之間沒有鎖沖突),那么master節(jié)點就可以將這一組的事務標記并在slave機器上安全的進行并發(fā)重放主庫提交的事務。所以盡可能的使所有線程能在同一時刻提交可以極大的提高slave機器并發(fā)執(zhí)行事務的數(shù)量使主備數(shù)據同步。
在 Flush stage:所有已經注冊線程都將寫入binary log緩存
在Sync stage :binary log緩存的數(shù)據將會sync到磁盤,當sync_binlog=1時所有該隊列事務的二進制日志緩存永久寫入磁盤
在 Commit stage: leader根據順序調用存儲引擎提交事務。
那么為了使更多的并發(fā)線程事務能夠視為在同一個時刻commit即在Sync階段(調fsync()把binary log文件系統(tǒng)緩存日志永久刷入磁盤文件)master機器標記并發(fā)提交的事務為同一組事務的信息寫入binary log日志中。我們可以在Flush Stage將注冊為leader的線程帶領更多的follower線程到Sync stage進行一次fsync()的操作,來增加Binary Log Group Commit的數(shù)量。
如下圖:
當前MySQL/MariaDB數(shù)據庫實例上運行三個線程分別提交T1、T2、T3事務,T1事務的線程率先提交進入第一階段Flush stage隊列,發(fā)現(xiàn)該隊列是空隊列故注冊成leader,與此同時T2事務進入Flush stage成為該隊列的follower等待leader調配,事務T1的leader帶領T2事務進入Sync stage進行一次fsync()操作那么T1、T2在binary log進行一次group commit。
在二進制日志內標記了這一組事務。之后T3線程的事務隨后進入了binary log提交的過程。
MariaDB 10通過@@binlog_commit_wait_count and @@binlog_commit_wait_usec 兩個參數(shù)設置,既事務commit階段的時候至少等binlog_commit_wait_usec毫秒直到有binlog_commit_wait_count個數(shù)時進行一次組提交,來提高每組事務中的事務數(shù)量,并可以通過查詢狀態(tài)變量@@binlog_commit和@@binlog_group_commit來查參數(shù)來查看當前binary log group commit比例。
MySQL5.7通過引入 binlog_group_commit_sync_delay和 binlog_group_commit_sync_no_delay_count參數(shù)即提高binary log組提交并發(fā)數(shù)量,既MySQL等待binlog_group_commit_sync_delay毫秒的時間直到binlog_group_commit_sync_no_delay_count個數(shù)時進行一次組提交。
實現(xiàn):
Binary Log Group Commit在MySQL 5.7和MariaDB 10 中是默認開啟不需要配置任何信息,且在binary log中標記的組提交信息依賴于GTID,而MySQL和MariaDB的GTID組成和實現(xiàn)方式不一樣,這里我們簡單梳理下。
在MySQL 5.7版本由于Binary Log Group Commit是默認開啟的,所以即使你不開啟gtid_mode在配置文件中,binary log的內容中同樣也有GTID 信息只不過標記的信息是"ANONYMOUS"
> show binlog events in 'mysql-bin.000004';截取一段信息
1. ...............
| mysql-bin.000004 | 3571 | Anonymous_Gtid | 15112 |
3636 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
2. | mysql-bin.000004 | 3636 | Query | 15112 | 3712 | BEGIN |
3. | mysql-bin.000004 | 3712 | Rows_query | 15112 | 3763 | # INSERT INTO t1 () VALUES () |
4. | mysql-bin.000004 | 3763 | Table_map | 15112 | 3807 | table_id: 108 (db2.t1) |
5. | mysql-bin.000004 | 3807 | Write_rows | 15112 | 3847 | table_id: 108 flags: STMT_END_F |
6. | mysql-bin.000004 | 3847 | Xid
|
15112 |
3878 | COMMIT /* xid=33 */
|
.................
> mysqlbinlog -vvv mysql-bin.00004 | less
1. #151231 14:34:03 server id 15112 end_log_pos 2408 CRC32 0x5586fe71 Anonymous_GTID last_committed=6 sequence_number=8
2. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
3. # at 2408
4. #151231 14:34:03 server id 15112 end_log_pos 2484 CRC32 0x748efb17 Query thread_id=11 exec_time=0 error_code=0
5. SET TIMESTAMP=1451543643/*!*/;
6. BEGIN
7. ..
MariaDB的GTID同樣也是默認開啟且GTID是由Domain ID、Server ID和transaction Sequence Number組成:
> show binlog events in 'mysql-bin.000003';截取一段信息
1. .......
| mysql-bin.000003 | 335 | Gtid
| 15102 | 377 | BEGIN GTID 0-15102-64139
|
2. | mysql-bin.000003 | 377 | Table_map | 15102 | 434 | table_id: 18 (test.sbtest1) |
3. | mysql-bin.000003 | 434 | Write_rows_v1 | 15102 | 657 | table_id: 18 flags: STMT_END_F |
4. | mysql-bin.000003 | 657 | Xid | 15102 | 688 | COMMIT /* xid=16 */ |
5. | mysql-bin.000003 | 688 | Gtid | 15102 | 732 | BEGIN GTID 0-15102-64140 cid=20 |
6. | mysql-bin.000003 | 732 | Table_map | 15102 | 789 | table_id: 19 (test.sbtest6) |
7. | mysql-bin.000003 | 789 | Write_rows_v1 | 15102 | 1012 | table_id: 19 flags: STMT_END_F |
8. | mysql-bin.000003 | 1012 | Xid | 15102 | 1043 | COMMIT /* xid=20 */ |
9. | mysql-bin.000003 | 1043 | Gtid | 15102 | 1087 | BEGIN GTID 0-15102-64141 cid=20 |
10. | mysql-bin.000003 | 1087 | Table_map | 15102 | 1145 | table_id: 20 (test.sbtest12) |
11. | mysql-bin.000003 | 1145 | Write_rows_v1 | 15102 | 1368 | table_id: 20 flags: STMT_END_F |
12. | mysql-bin.000003 | 1368 | Xid
| 15102 | 1399 | COMMIT /* xid=21 */
|
......
> mysqlbinlog -vvv mysql-bin.00003 | less
1. .......
2. # at 1754
3. #160104 15:16:46 server id 15102 end_log_pos 1798 CRC32 0x26104c0b GTID 0-15102-64143 cid=20 trans
4. /*!100001 SET @@session.gtid_seq_no=64143*//*!*/;
5. BEGIN
6. /*!*/;
7. # at 1798
8. #160104 15:16:46 server id 15102 end_log_pos 1856 CRC32 0x2c994f5a Table_map: `test`.`sbtest12` mapped to number 20
9. # at 1856
10. #160104 15:16:46 server id 15102 end_log_pos 2079 CRC32 0x02b5a694 Write_rows: table id 20 flags: STMT_END_F
11.
12. BINLOG '
13. .........
結論:
MySQL 5.7 / MariaDB 10的parallel replication都是基于主庫上Binary Log Group Commit。
MySQL: 主庫并發(fā)提交的事務group commit寫入binary log日志中,當事務被標記的 last_committed=N的值相同時(通過binlog_group_commit_sync_delay、 binlog_group_commit_sync_no_delay_count參數(shù)設置提高并發(fā)事務數(shù)量),可以在slave節(jié)點并發(fā)回放主庫提交的事務。
MariaDB: 主庫并發(fā)提交的事務group commit寫入binary log日志中,當事務被標記的 cid=N 的值相同時(通過 binlog_commit_wait_count、binlog_commit_wait_usec參數(shù)設置提高并發(fā)事務數(shù)量),可以在slave節(jié)點并發(fā)回放主庫提交的事務。
Reference:http://geek.rohitkalhans.com/2013/09/enhancedMTS-deepdive.html
網站名稱:MySQL并發(fā)復制系列三:MySQL和MariaDB實現(xiàn)對比
文章位置:http://bm7419.com/article40/pscgho.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供App開發(fā)、面包屑導航、軟件開發(fā)、App設計、服務器托管、手機網站建設
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)