天天看點

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

作者:豫仁

RDS常見問題總結主要分為兩個方面的原因:使用者側配置問題、外部原因。

問題概述

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

1、 使用者側問題

1.1 使用者自身配置問題可能有多方面配置原因導緻,在此列舉下常見的一些配置問題

1.1.1 白名單設定問題

RDS是有白名單通路保護的,不論使用者内網通路還是外網通路都需要先添加要通路的IP到目标執行個體的白名單中,目前一個RDS執行個體最多可設定50個白名單分組和1000個IP,具體資訊請參考[RDS設定白名單]

https://help.aliyun.com/document_detail/43186.html?spm=5176.11065259.1996646101.searchclickresult.fa963e27pEtxtT)

在高安全通路模式下的報錯提示為:

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

在标準通路模式下的報錯提示為:

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

1.1.2 使用者自建DNS異常

RDS的通路不是直接以IP的形式進行通路,都是提供一個通路連接配接位址加端口号的形式進行通路,是以中間涉及到通路連接配接位址到IP的域名解析過程,通常情況下使用者都會使用RDS自身提供的DNS解析服務,但是也存在個别使用者出于各自運維管理的需要而自建DNS服務進行域名解析的情況。RDS提供域名給使用者通路就是為了友善使用者使用,在遇到如HA切換、執行個體遷移等情況,使用者的通路方式可以保持不變,其機制就是背景在執行個體切換的過程中雖然IP發生變化,但是通過域名解析映射,保證了使用者的通路方式不發生變化。是以通常情況下建議使用者通路RDS執行個體使用RDS提供的連接配接位址進行通路,自建DNS服務是無法确定切換後執行個體的IP。

1.1.3 使用者自身Mysql指令環境變量配置有誤或/etc/my.cnf下指定連接配接資訊不正确

使用者在mysql用戶端通路RDS執行個體的時候,一般常見需要如下幾個參數:-u 使用者名 –p 密碼(可非顯示輸入) -h 執行個體位址 –P 端口(預設3306)等,mysql用戶端在進行登入的時候對于沒有明确設定的參數通過讀取配置檔案(通常情況下為) /etc/my.cnf進行設定,舉一個常見的例子,使用者在my.cnf配置檔案裡設定了預設端口為3307,可使用者要連接配接的執行個體的端口為3306,使用者在mysql登入的時候沒有設定-P參數,是以出現連接配接錯誤:

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因
RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

指定正确端口即可通路:

RDS For MySQL常見連接配接問題總結1、 使用者側問題2、 外部原因

1.1.4 Iptables防火牆配置

RDS白名單是屬于RDS側的通路控制,防火牆是屬于使用者側的通路控制,如果使用者是使用ECS進行通路,還需要首先在ECS上設定相應的安全組,本文暫以使用者用Linux通路RDS進行說明,如使用者開啟了Iptables,可通過iptables –L進行通路政策檢視,Iptables可通過IP、協定、端口三個次元進行通路限制,是以使用者需要在Iptables中設定相應的政策,使用者也可選擇關閉Iptables,可通過service iptables stop進行關閉。

1.1.5 使用者本地DNS緩存或者綁定Host

使用者DNS緩存問題或者hosts檔案中配置中問題,和上述第二個原因很類似,都屬于域名解析類問題,Linux下清除域名緩存可通過service nscd restart的方式,/etc/hosts檔案主要是使用者在檔案中将連接配接位址和IP進行綁定,是以在執行個體進行切換時導緻通路失敗,通常不建議使用者這麼做,建議還是以RDS提供的連接配接位址的形式進行通路。

1.2 使用者應用代碼配置問題

1.2.1 代碼中連接配接資訊配置不對

遇到比較多的情況是使用者的代碼中連接配接位址配置錯誤、賬戶資訊配置錯誤,或者上述提到比較多的,在代碼中是以IP進行通路等,這種情況下,一般建議使用者先通過mysql用戶端的形式進行RDS登入,如能正常登入,建議使用者檢查下自己代碼中關于連接配接部分的設定。

1.2.2 代碼中連接配接參數設定不合理

使用者代碼中不合理的連接配接設定,導緻大部分連接配接沒有及時關閉,進而消耗RDS資源,最終引發連接配接數打滿的情況。建議使用者調整應用代碼中關于連接配接部分的設定。

1.3 使用者ECS側問題

通常阿裡雲的使用者都會通過ECS進行RDS通路,可能會因為争搶、OOM等原因導緻RDS通路失敗,也會存在源端因CPU打滿、網卡打滿(這裡不局限于ECS)等情況産生的網絡丢包現象而引起的連接配接閃斷現象。

1.4 使用者業務引起的RDS連接配接報錯

1.4.1 慢查詢引起CPU使用率增高導緻連接配接堆積

使用者代碼中存在性能較差的SQL導緻RDS出現慢大量SQL,CPU打滿,引發連接配接堆積RDS無法響應的現象,通常建議使用者通過

CloudDBA

中的

診斷慢SQL

功能對慢SQL進行診斷并調整優化。

1.4.2 目前執行個體規格不滿足業務增長

使用者的業務正常增長,但是目前執行個體規格無法滿足業務的合理增長,RDS是可以線上更新配置的, 是以建議使用者更新配置,升配過程中可能會有一次30s左右的閃斷,建議使用者做好連接配接重連機制,保證使用者業務的正常運作,具體資訊請參考:

RDS使用須知

1.5 使用者RDS使用問題

1.5.1 RDS相關連接配接參數設定不合理

使用者存在相關參數設定不合理的情況,例如使用者有session在執行長時間的read或者write操作時,

net_read_timeou

t和

net_write_timeout

設定過低導緻連接配接中斷。建議使用者結合業務和SQL實際運作情況調整RDS參數值。

1.5.2 執行個體被鎖定

使用者RDS執行個體因為磁盤空間超出購買規格限制而被鎖定,在執行個體鎖定期間,應用無法對RDS資料庫進行讀寫操作。建議使用者提前設定好RDS磁盤空間監控,在達到空間監控閥值進行預警,具體處理辦法請參考:

MySQL執行個體空間使用率過高的原因和解決方法

2、 外部原因

2.1 阿裡雲與其他雲廠商伺服器之間的互訪

使用者的RDS執行個體在阿裡雲上,但是應用端在其他雲廠商如AWS或IDC機房裡,目前出現過阿裡雲RDS在與AWS網絡互訪出現問題導緻RDS通路報錯的情況,或者使用者應用端在IDC機房,走公網通路RDS,由于公網網絡品質原因導緻的RDS通路丢包現象。

2.2 使用者在阿裡雲内的跨區通路中發生的網絡不穩定

使用者ECS執行個體與RDS執行個體均在阿裡雲上,但是RDS執行個體與ECS不在同一個Region中,非同一個Region互相間通路需要走公網,是以也存在因公網網絡品質原因導緻的RDS通路丢包現象。建議使用者在架構上合理搭配,盡量ECS和RDS在同一可用區,避免跨可用區甚至跨地域的情況發生。

以上是常見的RDS連接配接出錯可能産生的原因,并不是産生報錯的全部原因。但是大部分的連接配接問題都可以在上面的可能原因中找到對應情況。在診斷RDS連接配接報錯時,通常可通過如下幾個步驟進行排查:

1、ping URL 驗證DNS服務是否正常
2、telnet URL port  再次驗證DNS服務,同時看端口能否通,(在高安全通路模式下,telnet能通不代表RDS一定能正常服務)
3、telnet vip port  驗證4層服務是否OK
4、mysql –u –h –p –P 查下7層是否能聯通,(需要使用者使用官方的mysql用戶端)
5、如果上面都沒有問題,建議使用者在源端進行抓包,分析下網絡包看下是否建連成功