[mysql] [note] mysql 報錯Aborted connection

Aborted connection報錯一般分兩種，

1）Got an error reading communication packets，基本是網絡等原因導致。

2）Got? timeout? reading communication packets，原因基本是會話的idle時間達到了數據庫指定的timeout時間。

這里主要Got an error reading communication packets報錯

2021-01-25T05:54:00.746567Z 1172765 [Note] Aborted connection 1172765 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets)

2021-01-25T06:13:58.256934Z 1174164 [Note] Aborted connection 1174164 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets)

2021-01-25T06:14:27.452621Z 1174094 [Note] Aborted connection 1174094 to db: 'xx' user: 'root' host: 'xx.xx.5.12' (Got an error reading communication packets)

2021-01-25T06:18:13.795623Z 1174092 [Note] Aborted connection 1174092 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets)

2021-01-25T06:18:43.059256Z 1171452 [Note] Aborted connection 1171452 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets)

2021-01-25T06:25:11.992919Z 1174520 [Note] Aborted connection 1174520 to db: 'xx' user: 'root' host: 'xx.xx.5.11' (Got an error reading communication packets)

參考文檔：

https://www.percona.com/blog/2016/05/16/Mysql-got-an-error-reading-communication-packet-errors/

首先，當發生“Got an error reading communication packet”?錯誤時，它都會為Aborted_clients或Aborted_connects遞增狀態計數器，該計數器描述了由于客戶端在沒有正確關閉連接而中斷的情況下中止的連接數，以及嘗試連接到Mysql服務器的失敗嘗試數。這兩個錯誤的可能原因很多（請參見MySQL手冊中的?Aborted_clients increments or Aborted_connects increments 部分）。

在這種情況下，MySQL為Aborted_clients增加狀態counter?，這可能意味著：

客戶端成功連接但異常（可能與未正確關閉連接有關）

客戶端的sleep時間超過了定義的wait_timeout或Interactive_timeout秒數（最終導致連接休眠了wait_timeout秒數，然后該連接被MySQL服務器強行關閉）

客戶端異常終止或超出了?查詢的?max_allowed_pa cket

以上不是全部問題列表，要根據具體確定導致此問題的原因以及如何解決。

修復MySQL Communication Errors

連接中斷錯誤不容易診斷。就經驗來看，大多數情況下它與網絡/防火墻問題有關。我們通常在Percona工具包腳本（即pt-summary?/?pt-mysql-summary?/?pt-stalk）的幫助下調查這些問題。這些腳本的輸出可能非常有幫助。

導致連接錯誤中止的一些原因可能是：

大量連接處于MySQL內部數百秒的休眠狀態是應用程序在完成工作后沒有關閉連接，而是依靠wait_timeout?來關閉連接的癥狀之一?。建議更改應用程序邏輯以在操作結束時正確關閉連接。

檢查以確保max_allowed_pa cket的值足夠高，并且客戶端沒有收到“ packet too large”消息。這種情況會中止連接而沒有正確關閉它。

另一種可能性是?TIME_WAIT，通過netstat排查 TIME_WAIT，因此我建議確認在應用程序端可以很好地關閉連接。

確保正確提交（開始和提交）事務，以便一旦應用程序“完成”連接后，它將保持干凈狀態。

確保客戶端應用程序不會中斷連接。例如，如果PHP將選項?max_execution_time?設置為5秒，則增加connect_timeout將無濟于事，因為PHP將終止腳本。其他編程語言和環境可以具有類似的安全選項。

有可能是DNS問題，檢查是否已啟用“skip-name-resolve”，以及是否根據主機的IP地址（而不是主機名）對主機進行了身份驗證。

找出應用程序行為異常的一種方法是在代碼中添加一些日志記錄，以保存應用程序操作以及MySQL連接ID。這樣，可以將其與錯誤行中的連接號相關聯。啟用審核日志插件，該日志記錄連接和查詢活動，并在遇到連接異常中止錯誤后立即檢查?Percona審核日志插件。可以檢查審核日志以識別哪個查詢是罪魁禍首。如果由于某種原因不能使用Audit插件，則可以考慮使用MySQL常規日志-但是，這在加載的服務器上可能會有風險。您應該啟用?常規日志持續至少幾分鐘。盡管這給服務器增加了沉重的負擔，但錯誤經常發生，因此您應該能夠在日志變得太大之前收集數據。我建議啟用帶有-f尾部的常規日志，然后在看到日志中的下一個警告時禁用常規日志。從中止的連接中找到查詢后，請確定要查詢的應用程序部分，并將查詢與應用程序的各個部分相關聯。

嘗試增加MySQL的net_read_timeout和net_write_timeout值，看看是否可以減少錯誤數量。? 除非網絡比較差，否則net_read_timeout很少會成為問題。可以試調整這些值，因為在大多數情況下，查詢是作為單個數據包生成并發送到服務器的，并且應用程序無法切換為做其他事情，而會使服務器保留部分接收到的查詢。 可以參考文章https://www.percona.com/blog/2007/07/08/mysql-net_write_timeout-vs-wait_timeout-and-protocol-notes/。

由于異常，所以發生中斷連接。除非服務器和客戶端之間存在網絡問題（例如服務器為半雙工，而客戶端為全雙工），否則服務器不會導致連接異常終止--這是網絡引起的問題。此類問題應該在網絡接口上排查。通過ifconfig?-a? 檢查 MySQL服務器上輸出，以檢查是否有錯誤。

另一種方法是通過 tcpdump。您可以參考此博客文章（https://www.percona.com/blog/2008/08/23/how-to-track-down-the-source-of-aborted_connects/），以了解如何追蹤中止連接的來源。使用MySQL查找潛在的網絡問題，超時和資源問題。

可以參考該文章(https://www.percona.com/blog/2011/04/18/how-to-use-tcpdump-on-very-busy-hosts/)在負載的主機上使用tcpdump非常有用 。它為跟蹤導致連接中斷的TCP交換序列提供了幫助，排查原因。

對于網絡問題，請使用ping來計算mysqld所在的計算機與應用程序發出請求的計算機之間的往返時間（RTT）。在客戶端和服務器計算機之間發送一個大文件（1GB或更大），使用tcpdump監視該過程 ，然后檢查傳輸過程中是否發生錯誤。重復此測試幾次。參考博文http://www.tusacentral.net/joomla/index.php/mysql-blogs/164-effective-way-to-check-the-network-connection-when-in-need-of-a-geographic-distribution-replication-.html。

另外是? netstat?-s?每N秒后時間戳一起輸出來進行排查（例如，10秒鐘，這樣你可以涉及?netstat?-s?之前和之后從MySQL錯誤日志中止連接錯誤輸出） 。與被中斷的連接錯誤時戳，則可以與共同涉及它? 的netstat?捕獲作為每一個樣本的時間戳?netstat的，和其中手表錯誤計數器下的TcpExt部分增加?的netstat?-s 。

除此之外，還應該檢查位于客戶端和服務器之間的網絡基礎結構，以查找可能引起問題的代理，負載平衡器和防火墻。

結論：

除了診斷通信故障錯誤之外，您還需要考慮可能導致此問題的以太網，集線器，交換機，電纜等故障。

MySQL 數據庫 網絡

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。