這套方法論,徹底終結MySQL同步延遲問題!
一、背景
最近有一組DB出現比較大的延遲,這組DB是專門用來存儲監控數據的,每分鐘會使用Load Data的方式導入大量的數據。為了節省空間,將原來使用壓縮表的InnoDB引擎轉換成了TokuDB引擎,使用的版本和引擎如下:
MySQL Version: 5.7
Storage Engine: TokuDB
轉換後,發現主從延遲逐漸增大,基本每天落後主機大概50個binlog左右,大概延遲7.5個小時左右的數據,主機每天大概產生160個binlog,binlog列表如下圖所示:
由於對該業務非常熟悉,因此很快就定位到造成主從同步延遲的原因,並很快就解決了延遲的問題。這裏不直接說解決辦法,而是想描述一套完整的解決主從延遲問題的思考方式,和大家一起來系統的做一些思考。
帶著問題去思考延遲的根本原因和解決辦法,這也許會更有意義。授人以魚,不如授人以漁。接下來我們就一起開腦洞吧。
分享之前我還是要推薦下我自己創建的大數據學習交流Qun531629188
無論是大牛還是想轉行想學習的大學生
小編我都挺歡迎,今天的已經資訊上傳到群文件,不定期分享幹貨,還有免費學習大數據的直播平臺
包括我自己整理的一份最新的適合2018年學習的大數據教程,歡迎初學和進階中的小夥伴。
二、思考
首先,既然產生了主從延遲,就說明在從機上的消費速度趕不上主機binlog產生的速度。我們先來思考一下可能的原因,並根據現場的蛛絲馬跡去驗證猜想的正確性。其實所謂的問題排查,就是提出可能問題猜想,然後不斷去證明的過程。不同的是,每個人的經驗不同,排查的質量也不盡頭相同,僅此而已。
1
網絡
網絡可能導致主從延遲的問題,比如主機或者從機的帶寬打滿、主從之間網絡延遲很大,有可能會導致主上的binlog沒有全量傳輸到從機,造成延遲。
筆者的那組DB的IO線程已經將對應的binlog近乎實時地拉取到了從機DB上,基本排除網絡導致的延遲,還可以結合網絡質量相關監控來進一步確認是網絡的問題。
2
機器性能
從機使用了爛機器?
之前有遇到過有的業務從機使用了很爛的機器,導致的主從延遲。比如主機使用SSD,而從機還是使用的SATA。從機用爛機器的觀念需要改改,隨著DB自動切換的需求越來越高,尤其是筆者所在的金融行業,從機至少不要比主機配置差。
從機高負載?
有很多業務會在從機上做統計,把從機服務器搞成高負載,從而造成從機延遲很大的情況,這種使用top命令即可快速發現。
從機磁盤有問題?
磁盤、Raid卡、調度策略有問題的情況下,有時會出現單個IO延遲很高的情況,比如Raid卡電池充放電時,在沒有設置強行write back的情況下得會將write back模式修改為write through。
使用iostat命令查看DB數據盤的IO情況,是否是單個IO的執行時間很長、塊大小和磁盤隊列情況等,可以比較一下DB盤的IO調度規則以及塊大小的設置等。
使用iostat查看IO運行情況:
從IO情況看也沒什麽問題,單個IO延遲很小,IOPS很低,寫帶寬也不大。調度規則(cat /sys/block/fioa/queue/scheduler)和塊大小等和主機設置是一樣的,排除掉磁盤的問題。
從運行指標看,機器負載很低,機器性能也可以排除。
3
大事務
是否經常會有大事務?
這個可能DBA們會遇到比較多,比如在RBR模式下,執行帶有大量的Delete操作,或者在MBR模式下刪除時添加了不確定語句(類似limit)或一個表的Alter操作等,都會導致延遲情況的發生。
這種可通過查看Processlist相關信息,以及使用mysqlbinlog查看binlog中的SQL就能快速進行確認。這個設想也被排除。
4
鎖
鎖沖突問題也可能導致從機的SQL線程執行慢,比如從機上有一些select .... for update的SQL,或者使用了MyISAM引擎等。此類問題,可以通過抓去Processlist以及查看information_schema下面和鎖以及事務相關的表來查看。
經過排查也並未發現鎖的問題。
5
參數
參數部分使用如果是InnoDB引擎,可以根據自己的使用環境調整innodb_flush_log_at_trx_commit、sync_binlog參數來提升復制速度,那組DB使用的TokuDB,則可以優化tokudb_commit_sync、tokudb_fsync_log_period、sync_binlog等參數來做調整。這些參數調整後,復制的延遲情況會有一些作用。
備註:這種調整可能會影響數據的安全性,需要結合業務來考慮。
6
多線程
多線程問題可能是DBA們遇到最多的問題,之前在5.1和5.5版本,MySQL的單線程復制瓶頸就廣受詬病。從5.6開始MySQL正式支持多線程復制。
很容易想到,如果是單線程同步的話,單個線程存在寫入瓶頸,導致主從延遲。那就先調整為多線程試試效果。
可以通過Show Processlist查看是否有多個同步線程,也可以查看參數的方式查看是否使用多線程(show variables like '%slave_parallel%')
當你看到是上圖這種結果時,恭喜你,你使用的是單線程。可使用下面那行命令改造成多線程復制:
STOP SLAVE SQL_THREAD;
SET GLOBAL
slave_parallel_type='LOGICAL_CLOCK';
SET GLOBAL
slave_parallel_workers=8;
START SLAVE SQL_THREAD;
改造後如下圖所示:
我的環境如上圖所示,本來就已經是多線程復制了,因此問題的根源也不在是否開啟多線程復制上。但當我使用Show Processlist查看復制狀態時,大多數情況下發現只有1個SQL線程在執行,如下圖所示:
通過上面的圖可發現,基本都是一個線程在執行,那麽可初步判定是多線程的威力沒有得到很好的發揮,為了更有力地說明問題,想辦法統計出來每個同步線程使用的比率。統計方法如下:
1、將線上從機相關統計打開(出於性能考慮默認是關閉的),打開方法如下:
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 FROMperformance_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) FROMrep_thread_count INTO @total;
SELECT 100*(COUNT_STAR/@total) AS thread_usage FROMrep_thread_count;
結果如下:
從上面的結果可以看出,絕大多數情況下,都是一個線程在跑,在監控這種存在大量數據導入的場景下肯定容易出現瓶頸。如果能提高各個線程並發執行的能力,也許能很好地改善同步延遲的情況,那如何解決呢?
7
組提交
我們不妨從多線程同步的原理來思考,在5.7中,多線程復制的功能有很很大的改善,支持LOGICAL_CLOCK的方式,在這種方式下,並發執行的多個事務只要能在同一時刻commit,就說明線程之間沒有鎖沖突,那麽Master就可以將這一組的事務標記並在slave機器上安全的進行並發執行。
因此,可以盡可能地使所有線程能在同一時刻提交,這樣就能很大程度上提升從機的執行的並行度,從而減少從機的延遲。
有了這個猜想後,很自然想到了人為控制盡可能多地使所有線程在同一時刻提交,其實官方已經給我們提供了類似的參數,參數如下:
binlog_group_commit_sync_delay
備註:這個參數會對延遲SQL的響應,對延遲非常敏感的環境需要特別註意,單位是微秒。
參數說明見:
https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_group_commit_sync_delay
binlog_group_commit_sync_no_delay_count
備註:這個參數取到了一定的保護作用,在達到binlog_group_commit_sync_no_delay_count設定的值的時候,不管是否達到了binlog_group_commit_sync_delay設置定的閥值,都立即進行提交。
參數說明見:
https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_group_commit_sync_no_delay_count
由於是監控的DB,主要是load數據,然後進行展示,1秒左右的導入延遲對業務沒什麽影響,因此將兩個參數調整為:
SET GLOBAL binlog_group_commit_sync_delay = 1000000;
SET GLOBAL binlog_group_commit_sync_no_delay_count = 20;
備註:這兩個參數請根據業務特性進行調整,以免造成線上故障。
為了防止導入SQL堆積,設置SET GLOBAL binlog_group_commit_sync_no_delay_count為20,在達到20個事務時不管是否達到了1秒都進行提交,來減少對業務的影響。
設置完這兩個參數後,發現並發復制瞬間提升了好多,很多時候8個線程都能跑滿。於是將線程調整到16個。運行一段事件後,再次統計各個同步線程的使用比率,發現並發度提升了非常多,新的比率如下圖所示:
通過show slave status查看,發現從機延遲越來越小,目前已經完全追上,並穩定運行了一周。
三、總結
最後簡單總結一下,在遇到主從延遲的問題時,可從以下幾個地方開腦洞,尋找蛛絲馬跡,找到問題的根源,對癥下藥才能藥到病除,排查範圍包括但不限於如下幾方面:
網絡方面
性能方面
配置方面(參數優化)
大事務
鎖
多線程復制
組提交
通過上面對整個問題排查的梳理,希望能夠幫助廣大DBA在遇到類似復制延遲的問題時徹底終結問題。
這套方法論,徹底終結MySQL同步延遲問題!