溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

MySQL并發(fā)復制系列三：MySQL和MariaDB實現(xiàn)對比

發(fā)布時間：2020-08-13 00:02:42 來源：ITPUB博客 閱讀：255 作者：沃趣科技 欄目：MySQL數(shù)據(jù)庫

并發(fā)復制（Parallel Replication） 系列三：MySQL 5.7 和MariaDB 10的parallel replication對比

作者：沃趣科技MySQL數(shù)據(jù)庫工程師  麻鵬飛

        經(jīng)過上兩篇關于MySQL／MariaDB 的Binary Log Group Commit的發(fā)展歷程和enhanced multi-threaded slave的介紹，相信大家對MySQL 基于Binay Log 的replication的原理以及為了解決主備數(shù)據(jù)復制延遲問題而引入的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ù)據(jù)寫入磁盤。當并發(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í)行這一組被標記的事務。MySQL并發(fā)復制系列三：MySQL和MariaDB實現(xiàn)對比

原理：

       從上面的例子可以看出，并發(fā)線程執(zhí)行不同的事務只要在同一時刻能夠commit（說明線程之間沒有鎖沖突），那么master節(jié)點就可以將這一組的事務標記并在slave機器上安全的進行并發(fā)重放主庫提交的事務。所以盡可能的使所有線程能在同一時刻提交可以極大的提高slave機器并發(fā)執(zhí)行事務的數(shù)量使主備數(shù)據(jù)同步。

      在上一篇文章提到過：MySQL／MariaDB開啟Binary Log日志后使二進制日志寫入順序和存儲引擎提交順序保持一致，Binary Log Group Commit分為三個過程：MySQL并發(fā)復制系列三：MySQL和MariaDB實現(xiàn)對比
圖1: Binary Log Group Commit 三個階段

在 Flush stage：所有已經(jīng)注冊線程都將寫入binary log緩存

在Sync stage ：binary log緩存的數(shù)據(jù)將會sync到磁盤，當sync_binlog=1時所有該隊列事務的二進制日志緩存永久寫入磁盤

在 Commit stage:    leader根據(jù)順序調用存儲引擎提交事務。

那么為了使更多的并發(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ù)據(jù)庫實例上運行三個線程分別提交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提交的過程。

MySQL并發(fā)復制系列三：MySQL和MariaDB實現(xiàn)對比
圖2: 組提交過程


 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組成：

MySQL并發(fā)復制系列三：MySQL和MariaDB實現(xiàn)對比
   圖3 MariaDB GTID組成

>    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

 




 
向AI問一下細節(jié)

免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內容。

AI
助
手