[Mysql]Mysql5.7並行複製
啟用MySQL並行複製
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)
檢查Worker執行緒的狀態
當前的 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;
參考文件
https://www.jianshu.com/p/ed19bb0e748a
https://www.hi-linux.com/posts/9892.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29096438/viewspace-2665869/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL 5.7 並行複製MySql並行
- mysql 並行複製原理MySql並行
- MySQL 5.7並行複製MySql並行
- Mysql5.7半同步複製MySql
- mysql5.7主從複製,主主複製MySql
- MySQL5.7主從複製-半同步複製搭建MySql
- MySQL5.7主從複製教程MySql
- #MySQL# mysql5.7新特性之半同步複製MySql
- MySQL並行複製(MTS)原理(完整版)MySql並行
- MySQL並行複製-原始碼理解記錄MySql並行原始碼
- MySQL Case-MySQL8.0真正的並行複製writesetMySql並行
- MySQL Case-MySQL5.7無效的並行複製MySql並行
- MySQL案例07:MySQL5.7併發複製隱式bugMySql
- MySQL5.7半同步複製報錯案例分析MySql
- MySQL並行複製延時時間不準確MySql並行
- MySQL 並行複製方案演進歷史及原理分析MySql並行
- MySQL 主從複製之多執行緒複製MySql執行緒
- MySQL5.7在滴滴雲主機上的主從複製MySql
- MySQL案例-並行複製亂序提交引起的同步異常MySql並行
- MySQL複製MySql
- mysql複製--主從複製配置MySql
- MySQL 主從複製的執行流程MySql
- mysql5.7 GTID 主從複製模式-增加新的slave1(好文章!!)MySql模式
- 例項解讀:MySQL並行複製如何解決特定的主從問題?MySql並行
- MySQL 8 複製(三)——延遲複製與部分複製MySql
- MySQL主從複製之GTID複製MySql
- MySQL 8 複製(一)——非同步複製MySql非同步
- MySQL 8 複製(二)——半同步複製MySql
- MySQL 8 複製(四)——GTID與複製MySql
- MySQL 8 複製(五)——配置GTID複製MySql
- MySQL 複製全解析 Part 11 使用xtrabackup建立MySQL複製MySql
- MySQL主從複製之半同步複製MySql
- MySQL主從複製之非同步複製MySql非同步
- 第16節:基於WRITESET的並行複製方式並行
- Welcome to MySQL Workbench:MySQL 複製表MySql
- MySQL 多源複製MySql
- MySQL主從複製MySql
- mysql 併發複製MySql