您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關Mysql5.7如何并行復制,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
MySQL 5.7的并行復制建立在組提交的基礎上,所有在主庫上能夠完成 Prepared
的語句表示沒有數據沖突,就可以在 Slave 節點并行復制。
關于 MySQL 5.7 的組提交,我們要看下以下的參數:
(test) > show global variables like '%group_commit%' -> ; +-----------------------------------------+-------+ | Variable_name | Value | +-----------------------------------------+-------+ | binlog_group_commit_sync_delay | 0 | | binlog_group_commit_sync_no_delay_count | 0 | +-----------------------------------------+-------+
要開啟 MySQL 5.7 并行復制需要以下二步,首先在主庫設置 binlog_group_commit_sync_delay
的值大于0 。
> set global binlog_group_commit_sync_no_delay_count=20; > set global binlog_group_commit_sync_delay =10;
這里簡要說明下 binlog_group_commit_sync_delay
和 binlog_group_commit_sync_no_delay_count
參數的作用。
binlog_group_commit_sync_delay
全局動態變量,單位微妙,默認0,范圍:0~1000000(1秒)。
表示
binlog
提交后等待延遲多少時間再同步到磁盤,默認0 ,不延遲。當設置為 0 以上的時候,就允許多個事務的日志同時一起提交,也就是我們說的組提交。組提交是并行復制的基礎,我們設置這個值的大于 0 就代表打開了組提交的功能。
binlog_group_commit_sync_no_delay_count
全局動態變量,單位個數,默認0,范圍:0~1000000。
表示等待延遲提交的最大事務數,如果上面參數的時間沒到,但事務數到了,則直接同步到磁盤。若
binlog_group_commit_sync_delay
沒有開啟,則該參數也不會開啟。
其次要在 Slave 主機上設置如下幾個參數:
# 過多的線程會增加線程間同步的開銷,建議4-8個Slave線程。 slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=4
或者直接在線啟用也是可以的:
mysql> stop slave; Query OK, 0 rows affected (0.07 sec) mysql> set global slave_parallel_type='LOGICAL_CLOCK'; Query OK, 0 rows affected (0.00 sec) mysql> set global slave_parallel_workers=4; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.06 sec) mysql> show variables like 'slave_parallel_%'; +------------------------+---------------+ | Variable_name | Value | +------------------------+---------------+ | slave_parallel_type | LOGICAL_CLOCK | | slave_parallel_workers | 4 | +------------------------+---------------+ 2 rows in set (0.00 sec)
當前的 Slave 的 SQL 線程為 Coordinator
(協調器),執行 Relay log
日志的線程為 Worker
(當前的 SQL 線程不僅起到協調器的作用,同時也可以重放 Relay log
中主庫提交的事務)。
我們上面設置的線程數是 4 ,從庫就能看到 4 個 Coordinator
(協調器)進程。
開啟 MTS 功能后,務必將參數 master-info-repository
設置為 TABLE ,這樣性能可以有 50%~80% 的提升。這是因為并行復制開啟后對于 master.info
這個文件的更新將會大幅提升,資源的競爭也會變大。
在 MySQL 5.7 中,推薦將 master-info-repository
和 relay-log-info-repository
設置為 TABLE ,來減小這部分的開銷。
master-info-repository = table relay-log-info-repository = table relay-log-recovery = ON
復制的監控依舊可以通過 SHOW SLAVE STATUS\G
,但是 MySQL 5.7 在 performance_schema
架構下多了以下這些元數據表,用戶可以更細力度的進行監控:
mysql> use performance_schema; mysql> show tables like 'replication%'; +---------------------------------------------+ | Tables_in_performance_schema (replication%) | +---------------------------------------------+ | replication_applier_configuration | | replication_applier_status | | replication_applier_status_by_coordinator | | replication_applier_status_by_worker | | replication_connection_configuration | | replication_connection_status | | replication_group_member_stats | | replication_group_members | +---------------------------------------------+ 8 rows in set (0.00 sec) 想辦法統計出來每個同步線程使用的比率。統計方法如下: 1、將線上從機相關統計打開(出于性能考慮默認是關閉的),打開方法可以如下如下SQL: UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_transactions%'; UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'WHERE NAME = 'transaction'; 2、創建一個查看各個同步線程使用量的視圖,代碼如下: USE test; CREATE VIEW rep_thread_count AS SELECT a.THREAD_ID AS THREAD_ID,a.COUNT_STAR AS COUNT_STAR FROM performance_schema.events_transactions_summary_by_thread_by_event_name a WHERE a.THREAD_ID in (SELECT b.THREAD_ID FROM performance_schema.replication_applier_status_by_worker b); 3、一段時間后,統計各個同步線程的使用比率,SQL如下: SELECT SUM(COUNT_STAR) FROM rep_thread_count INTO @total; SELECT 100*(COUNT_STAR/@total) AS thread_usage FROM rep_thread_count;
關于“Mysql5.7如何并行復制”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。