ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization pa

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0

我的問題是mysql安裝在docker中，經過一番探索，需要在docker的MySQL服務引數檔案中修改bind-address=0.0.0.0或去掉該引數，加上skip_name_resolve，最後重啟MySQL資料庫即可。

最近遇到一個MySQL連線的問題，遠端連線MySQL時遇到 “ ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0 ” 錯誤，如下所示：

 

[root@DB-Server ~]# mysql -h 10.13.65.93 -u onecard -p

Enter password:

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0

 

這個測試的MySQL位於阿里雲Kubernetes(K8s)中Docker容器裡面，而且在遠端連線MySQL出現上面錯誤的時候，Docker也會出現下面錯誤。

 

 

一般出現 “ ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet' ” 錯誤的原因較多：

 

1：網路異常或時延非常高的時候，   超過連線時間限制（系統變數connect_timeout）會導致這個錯誤。MySQL客戶端與資料庫建立連線需要發起三次握手協議，正常情況下，這個時間非常短，但是一旦網路異常，網路超時等因素出現，就會導致這個握手協議無法完成，MySQL有個引數connect_timeout，它是MySQL服務端程式mysqld等待連線建立完成的時間，單位為秒。如果超過connect_timeout時間範圍內，仍然無法完成協議握手話，MySQL客戶端會收到異常。  更多詳細資訊可以參考我這篇部落格 “ MySQL引數max_connect_errors分析釋疑 ” ，但是當前這個案例中，不存在網路延時情況，如下所示：

 

[root@DB-Server ~]# ping 10.13.65.93

PING 10.13.65.93 (10.13.65.93) 56(84) bytes of data.

64 bytes from 10.13.65.93: icmp_seq=1 ttl=97 time=36.1 ms

64 bytes from 10.13.65.93: icmp_seq=2 ttl=97 time=36.3 ms

64 bytes from 10.13.65.93: icmp_seq=3 ttl=97 time=36.1 ms

64 bytes from 10.13.65.93: icmp_seq=4 ttl=97 time=36.0 ms

64 bytes from 10.13.65.93: icmp_seq=5 ttl=97 time=36.1 ms

64 bytes from 10.13.65.93: icmp_seq=6 ttl=97 time=36.2 ms

64 bytes from 10.13.65.93: icmp_seq=7 ttl=97 time=36.1 ms

64 bytes from 10.13.65.93: icmp_seq=8 ttl=97 time=36.2 ms

--- 10.13.65.93 ping statistics ---

8 packets transmitted, 8 received, 0% packet loss, time 7003ms

rtt min/avg/max/mdev = 36.092/36.205/36.354/0.205 ms

 

 

 

 

2：域名解析會導致這個問題。當客戶端連線上來，伺服器端都會對客戶端進來的IP地址進行DNS解析，來獲得客戶端的域名或主機名，如果DNS解析出了問題或DNS解析相當慢，就會導致連線驗證使用者出現問題。而skip-name-resolve這個引數的意義就是禁止域名解析。官方文件解釋如下：

 

 

For each new client connection, the server uses the client IP address to check whether the client host name is in the host cache. If so, the server refuses or continues to process the connection request depending on whether or not the host is blocked. If the host is not in the cache, the server attempts to resolve the host name. First, it resolves the IP address to a host name and resolves that host name back to an IP address. Then it compares the result to the original IP address to ensure that they are the same. The server stores information about the result of this operation in the host cache. If the cache is full, the least recently used entry is discarded.

The server handles entries in the host cache like this:

 

• When the first TCP client connection reaches the server from a given IP address, a new cache entry is created to record the client IP, host name, and client lookup validation flag. Initially, the host name is set to NULL and the flag is false. This entry is also used for subsequent client TCP connections from the same originating IP.

 

  當有一個新的客戶端連線通過TCP進來時，MySQL Server會為這個IP在host cache中建立一個新的記錄，包括IP，主機名和client lookup validation flag，分別對應host_cache表中的IP，HOST和HOST_VALIDATED這三列。第一次建立連線因為只有IP，沒有主機名，所以HOST將設定為NULL，HOST_VALIDATED將設定為FALSE。

 

• If the validation flag for the client IP entry is false, the server attempts an IP-to-host name-to-IP DNS resolution. If that is successful, the host name is updated with the resolved host name and the validation flag is set to true. If resolution is unsuccessful, the action taken depends on whether the error is permanent or transient. For permanent failures, the host name remains NULL and the validation flag is set to true. For transient failures, the host name and validation flag remain unchanged. (In this case, another DNS resolution attempt occurs the next time a client connects from this IP.)

 

      MySQL Server檢測HOST_VALIDATED的值，如果為FALSE，它會試圖進行DNS解析，如果解析成功，它將更新HOST的值為主機名，並將HOST_VALIDATED值設為TRUE。如果沒有解析成功，判斷失敗的原因是永久的還是臨時的，如果是永久的，則HOST的值依舊為NULL，且將HOST_VALIDATED的值設定為TRUE，後續連線不再進行解析，如果該原因是臨時的，則HOST_VALIDATED依舊為FALSE，後續連線會再次進行DNS解析。

 

• If an error occurs while processing an incoming client connection from a given IP address, the server updates the corresponding error counters in the entry for that IP. For a description of the errors recorded, see  Section 26.12.17.1, “The host_cache Table” .  

          如果在處理來自給定IP地址的傳入客戶端連線時發生錯誤，則伺服器會更新該IP條目中的相應錯誤計數器。 有關記錄的錯誤的說明，請參見第26.12.17.1節 “ host_cache表 ” 。

 

 

 

這個案例裡面，因為MySQL位於阿里雲Kubernetes(K8s)中Docker容器裡面，對公司內部的IP地址進行DNS解析確實會出現問題。我們在配置檔案設定 skip_name_resolve 後，確實解決了這個問題。然後本來以為找到了原因的我，在本地兩臺機器上測試時發現（一臺 MySQL版本為5.6.41， 一臺 MySQL版本為5.6.23），即使兩臺伺服器相互不能做 DNS解析，如下截圖所示，但是從 192.168.27.180連線 DB-Server時，並不會報這個錯誤。 Why？ 即使我將 connect_timeout調整為 2，依然不會出現這個錯誤。看來 MySQL的連線不像我們表面看的那樣簡單。還是相當複雜。只是目前的技術水平，還做不到進一步分析！

 

 

 

另外，在這個案例的測試過程中，發現 skip_name_resolve為 OFF的情況下，將 connect_timeout設大，也不會出現這個錯誤

 

mysql>  show variables like '%connect_timeout%';

+-----------------+-------+

| Variable_name   | Value |

+-----------------+-------+

| connect_timeout | 10    |

+-----------------+-------+

1 row in set (0.01 sec)

mysql> set global connect_timeout=30;

Query OK, 0 rows affected (0.00 sec)

mysql>

 

 

然後從客戶端連線 MySQL資料庫就成功了，如下所示，只是 IP地址並不是客戶端的 IP地址，而是 Port IP。

 

 

  當然這種情況下Kubernetes(K8s)中Docker下MySQL並沒有掛掉，反而當系統變數 connect_timeout=10 的情況下，如果沒有開啟系統變數 skip_name_resolve，每次遠端連線 MySQL就會出現 Kubernetes(K8s)中Docker下MySQL掛掉，重啟的過程，所以極度懷疑是疑因為在連線過程，Docker下MySQL掛掉重啟才出現這個錯誤。但是對K8s瞭解不多，涉及太廣，沒法進一步分析具體原因了。

---

---

About Me

........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ DB寶）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文CSDN地址： https://blog.csdn.net/lihuarongaini ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ........................................................................................................................ ● QQ群號： 230161599 、618766405 ● 微 信群：可加我微 信（lhrbestxh），我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ），註明新增緣由 ● 於 2020-06-01 06:00 ~ 2020-06-30 24:00 在西安完成 ● 最新修改時間：2020-06-01 06:00 ~ 2020-06-30 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁： https://lhr.ke.qq.com/ ........................................................................................................................ 請掃描下面的二維碼來關注小麥苗的微 信公眾號（ DB寶）及QQ群（230161599、618766405）、新增小麥苗微 信（lhrbestxh）， 學習最實用的資料庫技術。 ........................................................................................................................

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2695698/，如需轉載，請註明出處，否則將追究法律責任。