建站
咨詢
售后
建站咨詢
新聞中心
問題描述
成都創(chuàng)新互聯(lián)公司是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，專業(yè)領(lǐng)域包括網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、電商網(wǎng)站制作開發(fā)、微信小程序開發(fā)、微信營銷、系統(tǒng)平臺開發(fā)，與其他網(wǎng)站設(shè)計及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！
在應(yīng)用端，偶爾看到有如下報錯：Authentication to host 'xxxx' for user 'yyyy' using method 'mysql_native_password' failed with message: Reading from the stream has failed.
表現(xiàn)特征：
- 只有用Connector/NET 出現(xiàn)這個問題， 用JDBC驅(qū)動沒有類似問題。
- 多臺應(yīng)用服務(wù)器，只有一臺報這個錯。因此可以排除服務(wù)器端的問題。
- 問題非常隨機。重啟一下服務(wù)器/IIS，就能臨時解決問題。
- 有一些場景應(yīng)用服務(wù)器CPU并不是很高，也會偶爾拋出這個錯來。
客戶端是Windows機器， 驅(qū)動是MySQL Connector ADO.NET Driver for MySQL (Connector/NET) ，使用的版本是6.9.9是比較新的版本。
問題分析
我們在應(yīng)用服務(wù)器端和數(shù)據(jù)庫端抓包。兩邊抓到的包是一致的?？梢耘懦W(wǎng)絡(luò)包丟失問題。下面是抓到的包，以及時間點：
從上述網(wǎng)絡(luò)包的交互來看， 前面三個包是TCP的三次握手協(xié)議。問題出在第六個包，數(shù)據(jù)庫服務(wù)器向應(yīng)用服務(wù)器發(fā)送了一個Finish包，來終止數(shù)據(jù)庫的連接。數(shù)據(jù)庫發(fā)送Finish包，是由于數(shù)據(jù)庫端發(fā)現(xiàn)連接超時而發(fā)送的。 這是由服務(wù)器端的Connect_timeout這個變量來控制。原因在于應(yīng)用端超過10秒未向數(shù)據(jù)庫服務(wù)器端發(fā)送網(wǎng)絡(luò)包。從網(wǎng)絡(luò)包交互的情況來看，第五個包和第六個包的時間間隔剛好是10秒。
對比正常的數(shù)據(jù)庫連接和上面異常的數(shù)據(jù)庫連接。 應(yīng)用服務(wù)器發(fā)送第5個包到數(shù)據(jù)庫端后， 應(yīng)該緊接著發(fā)送下面的網(wǎng)絡(luò)包到數(shù)據(jù)庫端的。這個包主要是發(fā)送賬號，驅(qū)動版本，操作系統(tǒng)信息等到數(shù)據(jù)庫服務(wù)器端。【下面是部分的正常的網(wǎng)絡(luò)包截圖】。在出現(xiàn)異常報錯的場景，客戶端是延遲發(fā)送這個包的。在Frame 8才發(fā)送的。而此時連接已經(jīng)被Finish了，在Frame 9，數(shù)據(jù)庫端發(fā)送了一個Reset包到應(yīng)用服務(wù)器，徹底中斷連接。
我們現(xiàn)在具體分析，為何客戶端發(fā)送賬號，驅(qū)動版本，操作系統(tǒng)信息到數(shù)據(jù)庫端這么慢。這部分的代碼在Connector/NET的MySQLAuthenticationPlugin.cs文件中。 我們修改這部分代碼，進(jìn)行時間埋點，來進(jìn)一步定位問題。下面是根據(jù)時間埋點，打印出來的跟蹤信息。
從跟蹤的Trace來看，有30秒左右的操作延時，全部時間集中在獲取Mysqldefs:: OSDetails的屬性。這部分代碼如下：
這段代碼是通過WMI查詢，來獲得Caption信息。也就是操作系統(tǒng)的版本信息。由于是WMI調(diào)用，所以依賴的關(guān)系比較多且與操作系統(tǒng)的狀態(tài)相關(guān)。
問題驗證
為了驗證是否為WMI偶發(fā)且頻繁的延時導(dǎo)致生產(chǎn)環(huán)境的某些機器出現(xiàn)通訊異常，我們把這段代碼抽出來。下面是一段簡短的重現(xiàn)代碼：
在有問題的應(yīng)用服務(wù)器上，我們運行上述代碼，確實可以發(fā)現(xiàn)WMI查詢有超時。下面這些日志信息是我們抓到的查詢超過30秒的WMI信息查詢操作。由此完全確認(rèn)是該操作導(dǎo)致MySQL authentication failed錯誤。
- 2017-11-21 17:19:30.208， 33638
- 2017-11-21 17:20:09.193， 33199
- 2017-11-21 17:20:53.086， 33201
- 2017-11-21 17:27:05.114， 32976
- 2017-11-21 17:28:19.178， 33635
- 2017-11-21 17:30:07.130， 65977
- 2017-11-21 17:30:49.051， 40478
- 2017-11-21 17:31:15.126， 26072
- 2017-11-21 17:38:16.048， 66671
- 2017-11-21 17:38:49.204， 33152
- 2017-11-21 17:39:53.161， 33828
- 2017-11-21 17:40:38.121， 33549
- 2017-11-21 17:47:09.179， 33775
- 2017-11-21 17:47:57.174， 33164
解決思路
WMI查詢慢，可能是由于多種原因所致。如操作系統(tǒng)CPU高，或者查詢本身有死鎖。這個問題有待于進(jìn)一步分析。但看代碼，我們知道做這個WMI查詢，只是為了獲得操作系統(tǒng)的信息。這個信息完全可以緩存起來。而不必要每次連接的時候，去進(jìn)行WMI查詢。
此處確定該錯誤的根本原因在于MySQL的C# connector中對操作系統(tǒng)信息的獲取時間過久，導(dǎo)致觸發(fā)服務(wù)器的連接超時。注釋掉該部分可能導(dǎo)致長時間的操作，在問題機器上進(jìn)行進(jìn)一步的驗證，再無任何的超時錯誤出現(xiàn)。
由于應(yīng)用端的系統(tǒng)信息相對來說是靜態(tài)信息，因此Connector/Net可以通過環(huán)境變量獲取這些信息，繞過WMI調(diào)用查詢。這樣每次進(jìn)行連接時，可避免出現(xiàn)查詢超時的問題，并且能夠提高Connector/Net的效率。
本文標(biāo)題：MySQLAuthenticationFailed的問題分析與解決對策
網(wǎng)頁路徑：http://www.5511xx.com/article/dpeeedc.html
