高可用數據庫主從複製延時的解決

 

MySQL主從複製的延時一直是業界困擾已久的問題。延時的出現會下降主從讀寫分離的價值，不利於數據實時性較高的業務使用MySQL。

1、延時問題的重要性

若是主從複製之間出現延時，就會影響主從數據的一致性。

此時發生容災切換，且在新的主庫寫入了數據，那麼從業務角度上，會產生意想不到的嚴重後果。

複製延時問題，在只讀從庫的場景下，若從庫產生複製延時，也可能會對業務形成必定影響，好比在業務上表現爲讀寫不一致——新增/修改數據查不到等現象。

因而可知，主從複製的延時問題在數據庫運營中須要特別關注。通常來講，DBA在庫上執行'SHOW SLAVE STATUS'，而且觀察

'Seconds_Behind_Master'的值，就可以瞭解當前某個數據庫和它的主庫之間的數據複製延時。

 

2、生產環境中延時問題的分析及解決

案例一：主庫DML請求頻繁

某些業務高峯期間，特別是對於數據庫主庫有大量的寫請求操做，即大量insert、delete、update等併發操做的狀況下，會出現主從複製延時問題。

現象描述

經過觀察主庫的寫操做的QPS的值，會看到主庫的寫操做的QPS值忽然升高，伴隨主從複製延時的上升，能夠判斷是因爲主庫DML請求頻繁緣由形成的。

 

 

如上圖，能夠看出，在17:58分左右QPS突增，查看控制檯上的寫相關QPS，也有相應提高。而QPS突增的時間，對應的延時也在逐步上升，以下圖所示。

 

 

緣由分析

通過分析，咱們認爲這是因爲主庫大量的寫請求操做，在短期產生了大量的binlog。這些操做須要所有同步到從庫，而且執行，所以產生了主從的數據複製延時。

從深層次分析緣由，是由於在業務高峯期間的主庫寫入數據是併發寫入的，而從庫SQL Thread爲單線程回放binlog日誌，很容易形成relaylog堆積，產生延時。

解決思路

若是是MySQL 5.7如下的版本，能夠作分片(sharding)，經過水平擴展(scale out)的方法打散寫請求，提高寫請求寫入binlog的並行度。

若是是MySQL 5.7以上的版本，在MySQL 5.7，使用了基於邏輯時鐘(Group Commit)的並行複製。而在MySQL 8.0，使用了基於Write Set的並行複製。這兩種方案都可以提高回放binlog的性能，減小延時。

 

 

 

案例二：主庫執行大事務

大事務指一個事務的執行，耗時很是長。常見產生大事務的語句有：

使用了大量速度很慢的導入數據語句，好比：INSERT INTO $tb、SELECT * FROM $tb、LOAD DATA INFILE等；

使用了UPDATE、DELETE語句，對於一個很大的表進行全表的UPDATE和DELETE等。

當這個事務在從庫執行回放執行操做時，就有可能會產生主從複製延時。

現象描述

從SHOW SLAVE STATUS的結果進行分析，會發現 Exec_Master_Log_Pos 字段一直未變，且second_behinds_master持續增長，而 Slave_SQL_Running_State 字段的值爲"Reading event from the relay log"；同時，分析主庫binlog，看主庫當前執行的事務，會發現有一些大事務，這樣基本能夠斷定是執行大事務的緣由致使的主從複製延時。

 

 

緣由分析

當大事務記錄入binlog並同步到從庫以後，從庫執行這個事務的操做耗時也很是長，這段時間，就會產生主從複製延時。

舉個例子，假如主庫花費200s更新了一張大表，在主從庫配置相近的狀況下，從庫也須要花幾乎一樣的時間更新這張大表，此時從庫延時開始堆積，後續的events沒法更新。

解決思路

對於這種狀況引發的主從複製延時，咱們的改進方法是：拆分大事務語句到若干小事務中，這樣可以進行及時提交，減少主從複製延時。

 

案例三：主庫對大表執行DDL語句

DDL全稱爲 Data Definition Language ，指一些對錶結構進行修改操做的語句，好比，對錶加一個字段或者加一個索引等等。當DDL對主庫大表執行DDL語句的狀況下，可能會產生主從複製延時。

現象描述

從現象上，若是從庫執行SHOW SLAVE STATUS的輸出中，檢查Exec_Master_Log_Pos一直未動，在排除主庫執行大事務的狀況下，那麼就有多是在執行大表的 DDL。這一點結合分析主庫binlog，看主庫當前執行的事務就能夠進行確認。

DDL語句的執行狀況，能夠進一步細分現象來更好地判斷：

1.DDL未開始，被阻塞，這時SHOW SLAVE STATUS的結果能檢查到Slave_SQL_Running_State爲waiting for table metadata lock，且Exec_Master_Log_Pos不變；

 

 

 2.DDL正在執行，SQL Thread單線程應用致使延時增長。這種狀況下觀察SHOW SLAVE STATU的結果能發現Slave_SQL_Running_State爲altering table，而Exec_Master_Log_Pos不變。

 

 

 

若是有上述的現象，那麼頗有可能主庫對大表執行DDL語句，同步到從庫並在從庫回放時，就產生了主從複製延時。

緣由分析

DDL致使的主從複製延時的緣由和大事務相似，也是由於從庫執行DDL的binlog較慢而產生了主從複製延時。

解決思路

遇到這種狀況，咱們主要經過SHOW PROCESSLIST或對information_schema.innodb_trx作查詢，來找到阻塞DDL語句，並KILL掉相關查詢，讓DDL正常在從庫執行。

DDL自己形成的延時難以免，建議考慮：

避免業務高峯，儘可能安排在業務低峯期執行 ；

set sql_log_bin=0後，分別在主從庫上手動執行DDL（此操做對於某些DDL操做會形成數據不一致，請務必嚴格測試），這一條若是用戶使用雲數據庫UDB，能夠聯繫UCloud UDB運維團隊進行協助操做。

 

案例四：主庫與從庫配置不一致

若是主庫和從庫使用了不一樣的計算資源和存儲資源，或者使用了不一樣的內核調教參數，可能會形成主從不一致。

現象描述

咱們會詳細比對主庫和從庫的性能監控數據，若是發現監控數據差別巨大，結合查看主從的各個配置狀況，便可做出明確判斷。

緣由分析

各類硬件或者資源的配置差別都有可能致使主從的性能差別，從而致使主從複製延時發生：

硬件上：好比，主庫實例服務器使用SSD磁盤，而從庫實例服務器使用普通SAS盤，那麼主庫產生的寫入操做在從庫上不能立刻消化掉，就產生了主從複製延時；

配置上：好比，RAID卡寫策略不一致、OS內核參數設置不一致、MySQL落盤策略不一致等，都是可能的緣由。

解決思路

考慮儘可能統一DB機器的配置（包括硬件及選項參數）。甚至對於某些OLAP業務，從庫實例硬件配置須要略高於主庫。

 

案例五：表缺少主鍵或合適索引

若是數據庫的表缺乏主鍵或者合適索引，在主從複製的binlog_format設置爲'row'的狀況下，可能會產生主從複製延時。

現象描述

咱們進行數據庫檢查時，會發現：

觀察SHOW SLAVE STATUS的輸出，發現Slave_SQL_Running_State爲Reading event from the relay log；

SHOW OPEN TABLES WHERE in_use=1的表一直存在；

觀察SHOW SLAVE STATUS的Exec_Master_Log_Pos字段不變；

mysqld進程的CPU接近100%（無讀業務時），IO壓力不大。

這些現象出現的狀況下，能夠認爲極可能有表缺少主鍵或惟一索引。

緣由分析

在主從複製的binlog_format設置爲'row'的狀況下，好比有這樣的一個場景，主庫更新一張500萬表中的20萬行數據。binlog在row格式下，記錄到binlog的爲20萬次update操做，也就是每次操做更新1條記錄。若是這條語句剛好有很差的執行計劃，如發生全表掃描，那麼每一條update語句須要全表掃描。此時SQL Thread重放將特別慢，形成嚴重的主從複製延時。

解決思路

這種狀況下，咱們會去檢查表結構，保證每一個表都有顯式自增主鍵，並協助用戶創建合適索引。

 

案例六：從庫自身壓力過大

有時候，從庫性能壓力很大的狀況下，跟不上主庫的更新速度，就產生了主從複製延時。

現象描述

觀察數據庫實例時，會發現CPU負載太高，IO利用率太高等現象，這些致使SQL Thread應用過慢。這樣就能夠判斷是由於從庫自身壓力過大引發主從複製延時。

緣由分析

部分UCloud用戶對於數據庫的主從會使用讀寫分離模式，讀請求大部分在從庫上執行。在業務有大量讀請求的場景下，從庫會產生比主庫大得多的性能壓力。有的用戶甚至會在從庫運行十分耗費計算資源的OLAP業務，這也對從庫形成了更高的性能挑戰，這些都會形成主從複製的延時。

解決思路

這種狀況下，咱們會建議用戶創建更多從庫，打散讀請求，下降現有從庫實例的壓力。對於OLAP業務來講，能夠專門創建一個從庫來作OLAP業務，並對這個從庫，容許適當的主從複製延時。

 

總結

在使用MySQL的主從複製模式進行數據複製時，主從複製延時是一個須要考量的關鍵因素。它會影響數據的一致性，進而影響數據庫高可用的容災切換。

在遇到數據庫之間出現主從複製延時的狀況下，咱們團隊基於過往經驗，概括出如下方法與流程來協助排查問題：

經過SHOW SLAVE STATUS與SHOW PROCESSLIST查看如今從庫的狀況。（順便也可排除在從庫備份時的相似緣由）；

若Exec_Master_Log_Pos不變，考慮大事務、DDL、無主鍵，檢查主庫對應的binlog及position便可；

若Exec_Master_Log_Pos變化，延時逐步增長，考慮從庫機器負載，如IO、CPU等，並考慮主庫寫操做與從庫自身壓力是否過大。

 

文章參考來源：https://mp.weixin.qq.com/s/IDPr6wPwTCIGr5yB3xeGKA