完全解決 MySQL 5.7 主從復制的延遲問題
阿新 • • 發佈：2018-08-02
cond master sla sql 進行 b- proc mas 恢復 1、問題發現
sysbench使用以下配置對MySQL進行測試
sysbench使用以下配置對MySQL進行測試
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.1.221 --mysql-port=3306 --mysql-user=root --mysql-password=MySQL5.7 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=10000 --threads=50 --time=60 --db-driver=mysql --report-interval=10 run >sysbench.log
一段時間後查看slave的狀態發現延時嚴重
mysql> show slave status\G
...
Seconds_Behind_Master: 467
...2、原因分析
一個服務器開放Ｎ個鏈接給客戶端來連接的， 這樣有會有大並發的更新操作, 但是從服務器的裏面讀取binlog 的線程僅有一個， 當某個SQL在從服務器上執行的時間稍長 或者由於某個SQL要進行鎖表就會導致，主服務器的SQL大量積壓，未被同步到從服務器裏。這就導致了主從不一致， 也就是主從延遲。
3、解決方法，開啟MySQL 5.7 的新功能復制多線程
mysql> show variables like ‘slave_parallel%‘; +------------------------+----------+ | Variable_name | Value | +------------------------+----------+ | slave_parallel_type | DATABASE | | slave_parallel_workers | 0 | +------------------------+----------+ mysql> set global slave_parallel_type=‘logical_clock‘; mysql> set global slave_parallel_workers=100; #大小根據需要設置 mysql> start slave; mysql> show processlist;
4、一段時間後查看狀態，已經恢復正常
mysql> show slave status\G
...
Seconds_Behind_Master: 0
...參考文檔：MySQL 5.7下主從復制延遲解決方案
完全解決 MySQL 5.7 主從復制的延遲問題