## 前言 只讀實例是目前 RDS 用戶實現數據讀寫分離的一種常見架構，用戶只需要將業務中的讀請求分擔到只讀節點上，就可以緩解主庫查詢壓力，同時也可以把一些 OLAP 的分析查詢放到另外的只讀節點上，減小復雜統計查詢對主庫的沖擊，RDS只讀節點架構圖如下：  由于RDS只讀節點采用原生的MySQL Binlog復制技術，那么延遲必然會成為其成立之初就會存在的問題。延遲會導致只讀節點與主庫的數據出現不一致，進而可能造成業務上邏輯的混亂或者數據不正確。 最近也收到了很多用戶關于只讀實例延遲的問題反饋，下面將會分析RDS只讀實例出現延遲的幾種常見場景，希望能夠幫助用戶理解和處理只讀節點的延遲，更好地使用只讀節點： 1. 只讀節點規格過小(10%) 2. 主庫的TPS過高(20%) 3. 主庫的DDL(alter、drop、repair)(40%) 4. 主庫大事務(insert..select)(20%) 5. 其他（無主鍵）(10%)  ## 場景一：只讀實例規格配置過小導致延遲 這類延遲場景的出現往往是主節點購買的一個較大規格的配置，而只讀節點卻購買了一個最小規格的配置（例如240M內存/150 IOPS）。 分析：只讀節點的數據為了和主節點保持同步，采用了MySQL原生的binlog復制技術，由一個IO線程和一個SQL線程來完成，IO線程負責將主庫的binlog拉取到只讀節點，SQL線程負責消費這些binlog日志，這兩個線程會消耗掉只讀節點的IO資源，所以當只讀節點IOPS配置不夠的時候，則會導致只讀節點的數據出現延遲：  可以通過只讀節點性能監控來判斷是否已經達到只讀實例的資源配額:   所以當這樣的延遲情況的發生的時候，需要用戶升級只讀實例的規格（可以參考主庫此時的IOPS的消耗情況），防止由于只讀實例的規格較小導致了數據延遲。 最佳實踐：只讀實例節點的配置大于或者等于主節點的配置； ## 場景二：主庫的TPS過高導致只讀節點延遲 這一類的延遲也是非常常見的延遲，由于只讀節點與主庫的同步采用的是單線程同步，而主庫的壓力是并發多線程寫入，這樣勢必會導致只讀節點的數據延遲，可以通過觀察只讀節點的TPS與主節點的TPS性能數據來完成判斷： 主庫的TPS性能數據：  只讀節點的TPS性能數據：  針對這樣場景的延遲，開啟只讀節點的并行復制是解決這一問題的根本方法，目前RDS生產環境默認開啟了并行復制。但是并行復制也不能夠徹底解決單表更新的問題，所以用戶需要排查業務寫入壓力是否正常，適當對業務進行優化或者拆分，保證主庫的TPS不會導致slave出現延遲。 ## 場景三：主庫的DDL(alter、drop、repair、create)導致只讀節點延遲 這種延遲是非常常見的延遲， 可以分為兩類： 第一類：只讀節點與主庫的DDL同步是串行進行的，如果DDL操作在主庫執行時間很長，那么同樣在備庫也會消耗同樣的時間，比如在主庫對一張500W的表添加一個字段耗費了10分鐘，那么在只讀節點上也同樣會耗費10分鐘，所以只讀節點會延遲600S，其他常見操作比如： ~~~ create index，repair table， alter table add column； ~~~ 范例：只讀節點出現延遲  主實例備庫同樣出現延遲：  查看主庫這這一段時間是否存在DDL，發現主庫在添加索引：  第二類：由于只讀節點上會有用戶的查詢在上面運行，所以如果只讀節點上有一個執行時間非常長的的查詢正在執行，那么這個查詢會堵塞來自主庫的DDL，直到查詢結束為止，進而導致了只讀節點的數據延遲。在只讀節點上可以通過執行show processlist命令查看連接的狀態處于:?`Waiting for table metadata lock`  這個時候只需要kill掉只讀節點上的大查詢就可以恢復只讀節點與主節點的數據同步。 ## 場景四：主庫執行大事務導致延遲 這一種延遲場景也是比較常見的，比如在主庫執行一個大的update、delete、insert … select的事務操作，產生大量的binlog傳送到只讀節點，只讀節點需要花費與主庫相同的時間來完成該事務操作，進而導致了只讀節點的延遲。只讀實例發生延遲，在只讀節點執行show slave status\G命令，可以通過兩個關鍵的位點參數來判斷只讀實例上是否在執行大事務：Seconds_Behind_Master不斷增加，但是Exec_Master_Log_Pos 卻沒有發生變化，這樣則可以判斷只讀節點的SQL線程在執行一個大的事務或者DDL操作。 例如下面的例子，用戶在主庫執行了一條insert … select非常大的插入操作，該操作產生了近幾十G的binlog文件傳輸到只讀節點，進而導致了只讀節點出現應用binlog延遲：   針對此類大事務延遲的場景，需要將大事務拆分成為小事務進行排量提交，這樣只讀節點就可以迅速的完成事務的執行，不會造成數據的延遲。 ## 場景五：其他只讀實例出現延遲的情況 如對無主鍵的表進行刪除（可以參考[MySQL主鍵的缺少導致備庫hang](https://yq.aliyun.com/articles/9066)），RDS目前已經支持對表添加隱式主鍵，但是對于以前歷史創建的表需要進行重建才能支持隱式主鍵。 ## 總結 綜上所述，當只讀實例出現延遲后的排查思路： 1. 看只讀節點IOPS定位是否存在資源瓶頸； 2. 看只讀節點的binlog增長量定位是否存在大事務； 3. 看只讀節點的comdml性能指標，對比主節點的commdml定位是否是主庫寫入壓力過高導致； 4. 看只讀節點show full processlist，判斷是否有Waiting for table metadata lock和alter，repair，create等ddl操作。 最佳實踐 1. 使用innodb存儲引擎； 2. 只讀實例的規格不低于主實例； 3. 大事務拆分為小事務； 4. 購買多個只讀節點冗余； 5. DDL變更期間觀察是否有大查詢。