又是一個(gè)季度一次的現(xiàn)場巡檢，期待數(shù)據(jù)庫能跑的又快又穩(wěn)，畢竟這是對DBA最大的饋贈了。

?

結(jié)果不遂人意發(fā)現(xiàn)在錯(cuò)誤日志內(nèi)存在大量的如下報(bào)錯(cuò)：

查看當(dāng)前數(shù)據(jù)庫的狀態(tài)值：

查看數(shù)據(jù)庫關(guān)于數(shù)據(jù)庫會話的關(guān)鍵參數(shù)：

數(shù)據(jù)庫環(huán)境及相關(guān)參數(shù)connect_timeout10

interactive_timeout28800

wait_timeout28800

max_connections151

net_write_timeout60

net_read_timeout30

可見，自數(shù)據(jù)庫啟動，440萬嘗試連接中，近140萬會話異常退出，近200萬會話未能正常連接到數(shù)據(jù)庫環(huán)境。而排查錯(cuò)誤日志中該報(bào)錯(cuò)無時(shí)間規(guī)律，同時(shí)客戶反饋在業(yè)務(wù)層面，經(jīng)常有長連接斷開的現(xiàn)象。

TIP：

首先我們通過官方文檔來了解Aborted_clients和Aborted_connects兩個(gè)狀態(tài)變量的代表意義，以及哪些情況或因素會導(dǎo)致這些狀態(tài)變量變化呢？

造成Aborted_connects狀態(tài)變量增加的可能原因：

1.客戶機(jī)試圖訪問數(shù)據(jù)庫，但沒有數(shù)據(jù)庫的特權(quán)。

2.客戶端使用了錯(cuò)誤的密碼。

3.連接包不包含正確的信息。

4.獲取一個(gè)連接包需要的時(shí)間超過connect_timeout秒。

造成Aborted_clients 狀態(tài)變量增加的可能原因：

1.程序退出前，客戶機(jī)程序沒有調(diào)用mysql_close()。

2.客戶端睡眠時(shí)間超過了wait_timeout或interactive_timeout秒。

3.客戶端程序在數(shù)據(jù)傳輸過程中突然終止。

簡單來說即：數(shù)據(jù)庫會話未能正常連接到數(shù)據(jù)庫，會造成Aborted_connects變量增加。數(shù)據(jù)庫會話已正常連接到數(shù)據(jù)庫但未能正常退出，會造成Aborted_clients變量增加。

根據(jù)錯(cuò)誤日志中報(bào)錯(cuò)：

Got timeout reading communication packets

出現(xiàn)如上錯(cuò)誤，基本上可判斷為數(shù)據(jù)庫認(rèn)證超時(shí)導(dǎo)致，或者業(yè)務(wù)線程異常退出。

客戶反饋并無相關(guān)業(yè)務(wù)客戶端異常退出等操作或現(xiàn)象。

可簡單判斷會話超過interactive_timeout/ wait_timeout限制時(shí)間(28800)導(dǎo)致會話被數(shù)據(jù)庫殺掉，跟應(yīng)用溝通之后，應(yīng)用確認(rèn)其業(yè)務(wù)邏輯會話均為長連接，不會主動進(jìn)行斷開操作。如上可初步解釋為何Aborted_clients狀態(tài)變量會如此之高。

那又該如何解釋Aborted_connects這個(gè)狀態(tài)變量如何之高？

能使該狀態(tài)變量增加的幾種可能性，我們依次來確認(rèn)排查。

1.客戶機(jī)試圖訪問數(shù)據(jù)庫，但沒有數(shù)據(jù)庫的特權(quán)。

2.客戶端使用了錯(cuò)誤的密碼。

3.連接包不包含正確的信息。

4.獲取一個(gè)連接包需要的時(shí)間超過connect_timeout秒。

關(guān)于1、2、3這三點(diǎn)，可統(tǒng)一解釋為 用戶/密碼/權(quán)限錯(cuò)誤導(dǎo)致無法正常連接到數(shù)據(jù)庫。這幾個(gè)錯(cuò)誤不會在錯(cuò)誤日志中報(bào)該錯(cuò)誤(Got timeout reading communication packets),錯(cuò)誤日志中也不存在(Access denied for user)該類錯(cuò)誤，且業(yè)務(wù)能正常運(yùn)行。這樣就能排除這三點(diǎn)的可能性。

那唯一可能就是由于連接認(rèn)證超時(shí)時(shí)間超過connect_timeout秒，數(shù)據(jù)庫層面connect_timeout參數(shù)設(shè)置為默認(rèn)的10s。根據(jù)官方文檔解釋：

10s基本上能夠支持業(yè)務(wù)使用。

那還有什么可能呢？

跟客戶確認(rèn)之后，了解到應(yīng)用是通過MySQL Router連接到數(shù)據(jù)庫服務(wù)器。檢查Router 參數(shù)文件配置，發(fā)現(xiàn)如下參數(shù)設(shè)置

發(fā)現(xiàn)在Router的配置中connect_timeout 配置為3s，那是否可能由于客戶端連接數(shù)據(jù)庫的認(rèn)證超過該限制導(dǎo)致。

因此建議修改Router配置文件中該參數(shù)，然后運(yùn)行一段時(shí)間后是否情況得到一定的改善。

后續(xù)排查往網(wǎng)絡(luò)方向排查，簡單可通過客戶端長ping數(shù)據(jù)庫服務(wù)端，查看網(wǎng)絡(luò)是否存在波動現(xiàn)象。

TIP:

根據(jù)官方文檔中介紹，還可能是由于網(wǎng)絡(luò)或者硬件層面的問題造成這個(gè)問題。

1. max_allowed_packet變量值太小，或者查詢需要的內(nèi)存比分配給mysqld的內(nèi)存多。

2. 在Linux中使用以太網(wǎng)協(xié)議，包括半雙工和全雙工。一些Linux以太網(wǎng)驅(qū)動程序有這個(gè)bug。您應(yīng)該通過在客戶機(jī)和服務(wù)器機(jī)器之間使用FTP傳輸一個(gè)大文件來測試這個(gè)bug。如果傳輸以突發(fā)-暫停-突發(fā)-暫停模式進(jìn)行，那么您正在經(jīng)歷一種Linux雙工綜合征。將網(wǎng)卡和集線器的雙工模式切換到全雙工或半雙工模式，并測試結(jié)果以確定最佳設(shè)置。

3. 線程庫中導(dǎo)致讀取中斷的問題。

4. 錯(cuò)誤的TCP / IP配置。

5. 有故障的以太網(wǎng)、集線器、交換機(jī)、電纜等等。只有通過更換硬件才能正確診斷。

下面對各類Aborted connection的可能性進(jìn)行一定的測試與分析：

測試環(huán)境說明：MySQL5.7

測試環(huán)境及相關(guān)參數(shù)connect_timeout10

interactive_timeout28800

wait_timeout28800

max_connections151

net_write_timeout60

net_read_timeout30

注：每次測試前均重啟數(shù)據(jù)庫重置狀態(tài)值，方便后續(xù)比較

測試一：錯(cuò)誤密碼、錯(cuò)誤用戶

錯(cuò)誤用戶：數(shù)據(jù)庫不存在該用戶。

查看數(shù)據(jù)庫內(nèi)狀態(tài)值：

查看錯(cuò)誤日志：

測試二：超時(shí)參數(shù)

當(dāng)前數(shù)據(jù)庫wait_timeout 及interactive_timeout均為默認(rèn)的28800，下面調(diào)整這兩個(gè)參數(shù)，測試對數(shù)據(jù)庫連接的行為影響。

該實(shí)驗(yàn)同時(shí)修改兩個(gè)參數(shù)為10：

查看數(shù)據(jù)庫內(nèi)狀態(tài)值：

查看錯(cuò)誤日志：

測試三：最大連接數(shù)

當(dāng)前數(shù)據(jù)庫max_connections參數(shù)默認(rèn)為151，下面調(diào)整改參數(shù)，測試對數(shù)據(jù)庫連接的行為影響。

當(dāng)開啟第四個(gè)連接會話，報(bào)如下錯(cuò)誤：

查看數(shù)據(jù)庫內(nèi)狀態(tài)值

此時(shí)錯(cuò)誤日志無變化。

測試四

第三方工具SQLyog select結(jié)果沒有出來的時(shí)候選擇停止則出現(xiàn)：

查看數(shù)據(jù)庫內(nèi)狀態(tài)值：

此時(shí)錯(cuò)誤日志無變化。

結(jié)論：

1.建議業(yè)務(wù)操作結(jié)束后使應(yīng)用程序邏輯以正確關(guān)閉連接，以短連接替代長連接。

2.確保max_allowed_packet的值足夠高，并且客戶端沒有收到“數(shù)據(jù)包太大”消息。

3.確保客戶端應(yīng)用程序不中止連接。

4.檢查是否啟用了skip-name-resolve，檢查主機(jī)根據(jù)其IP地址而不是其主機(jī)名進(jìn)行身份驗(yàn)證。

5.嘗試增加MySQL的net_read_timeout和net_write_timeout值，看看是否減少了錯(cuò)誤的數(shù)量。

參考文獻(xiàn)

總結(jié)

以上是生活随笔為你收集整理的mysql的告警日志_运维日记|MySQL关于aborted告警日志的分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。