今天就跟大家聊聊有關(guān)如何理解MySQL Authentication Failed的問題分析與解決方法，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

公司主營業(yè)務(wù)：成都網(wǎng)站建設(shè)、網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出潁泉免費(fèi)做網(wǎng)站回饋大家。

問題描述

在應(yīng)用端，偶爾看到有如下報(bào)錯(cuò)：Authentication to host 'xxxx' for user 'yyyy' using method 'mysql_native_password' failed with message: Reading from the stream has failed.

表現(xiàn)特征：

1. 只有用Connector/NET 出現(xiàn)這個(gè)問題， 用JDBC驅(qū)動(dòng)沒有類似問題。

2. 多臺(tái)應(yīng)用服務(wù)器，只有一臺(tái)報(bào)這個(gè)錯(cuò)。因此可以排除服務(wù)器端的問題。

3. 問題非常隨機(jī)。重啟一下服務(wù)器/IIS，就能臨時(shí)解決問題。

4. 有一些場景應(yīng)用服務(wù)器CPU并不是很高，也會(huì)偶爾拋出這個(gè)錯(cuò)來。

客戶端是Windows機(jī)器， 驅(qū)動(dòng)是MySQL Connector  ADO.NET Driver for MySQL (Connector/NET) ，使用的版本是6.9.9是比較新的版本。

問題分析

我們在應(yīng)用服務(wù)器端和數(shù)據(jù)庫端抓包。兩邊抓到的包是一致的?？梢耘懦W(wǎng)絡(luò)包丟失問題。下面是抓到的包，以及時(shí)間點(diǎn)：

從上述網(wǎng)絡(luò)包的交互來看， 前面三個(gè)包是TCP的三次握手協(xié)議。問題出在第六個(gè)包，數(shù)據(jù)庫服務(wù)器向應(yīng)用服務(wù)器發(fā)送了一個(gè)Finish包，來終止數(shù)據(jù)庫的連接。數(shù)據(jù)庫發(fā)送Finish包，是由于數(shù)據(jù)庫端發(fā)現(xiàn)連接超時(shí)而發(fā)送的。 這是由服務(wù)器端的Connect_timeout這個(gè)變量來控制。原因在于應(yīng)用端超過10秒未向數(shù)據(jù)庫服務(wù)器端發(fā)送網(wǎng)絡(luò)包。從網(wǎng)絡(luò)包交互的情況來看，第五個(gè)包和第六個(gè)包的時(shí)間間隔剛好是10秒。

對(duì)比正常的數(shù)據(jù)庫連接和上面異常的數(shù)據(jù)庫連接。 應(yīng)用服務(wù)器發(fā)送第5個(gè)包到數(shù)據(jù)庫端后， 應(yīng)該緊接著發(fā)送下面的網(wǎng)絡(luò)包到數(shù)據(jù)庫端的。這個(gè)包主要是發(fā)送賬號(hào)，驅(qū)動(dòng)版本，操作系統(tǒng)信息等到數(shù)據(jù)庫服務(wù)器端。【下面是部分的正常的網(wǎng)絡(luò)包截圖】。在出現(xiàn)異常報(bào)錯(cuò)的場景，客戶端是延遲發(fā)送這個(gè)包的。在Frame 8才發(fā)送的。而此時(shí)連接已經(jīng)被Finish了，在Frame 9，數(shù)據(jù)庫端發(fā)送了一個(gè)Reset包到應(yīng)用服務(wù)器，徹底中斷連接。

我們現(xiàn)在具體分析，為何客戶端發(fā)送賬號(hào)，驅(qū)動(dòng)版本，操作系統(tǒng)信息到數(shù)據(jù)庫端這么慢。這部分的代碼在Connector/NET的MySQLAuthenticationPlugin.cs文件中。 我們修改這部分代碼，進(jìn)行時(shí)間埋點(diǎn)，來進(jìn)一步定位問題。下面是根據(jù)時(shí)間埋點(diǎn)，打印出來的跟蹤信息。

從跟蹤的Trace來看，有30秒左右的操作延時(shí)，全部時(shí)間集中在獲取Mysqldefs:: OSDetails的屬性。這部分代碼如下：

這段代碼是通過WMI查詢，來獲得Caption信息。也就是操作系統(tǒng)的版本信息。由于是WMI調(diào)用，所以依賴的關(guān)系比較多且與操作系統(tǒng)的狀態(tài)相關(guān)。

問題驗(yàn)證

為了驗(yàn)證是否為WMI偶發(fā)且頻繁的延時(shí)導(dǎo)致生產(chǎn)環(huán)境的某些機(jī)器出現(xiàn)通訊異常，我們把這段代碼抽出來。下面是一段簡短的重現(xiàn)代碼：

在有問題的應(yīng)用服務(wù)器上，我們運(yùn)行上述代碼，確實(shí)可以發(fā)現(xiàn)WMI查詢有超時(shí)。下面這些日志信息是我們抓到的查詢超過30秒的WMI信息查詢操作。由此完全確認(rèn)是該操作導(dǎo)致MySQL authentication failed錯(cuò)誤。

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高，或者查詢本身有死鎖。這個(gè)問題有待于進(jìn)一步分析。但看代碼，我們知道做這個(gè)WMI查詢，只是為了獲得操作系統(tǒng)的信息。這個(gè)信息完全可以緩存起來。而不必要每次連接的時(shí)候，去進(jìn)行WMI查詢。

此處確定該錯(cuò)誤的根本原因在于MySQL的C# connector中對(duì)操作系統(tǒng)信息的獲取時(shí)間過久，導(dǎo)致觸發(fā)服務(wù)器的連接超時(shí)。注釋掉該部分可能導(dǎo)致長時(shí)間的操作，在問題機(jī)器上進(jìn)行進(jìn)一步的驗(yàn)證，再無任何的超時(shí)錯(cuò)誤出現(xiàn)。

由于應(yīng)用端的系統(tǒng)信息相對(duì)來說是靜態(tài)信息，因此Connector/Net可以通過環(huán)境變量獲取這些信息，繞過WMI調(diào)用查詢。這樣每次進(jìn)行連接時(shí)，可避免出現(xiàn)查詢超時(shí)的問題，并且能夠提高Connector/Net的效率。

看完上述內(nèi)容，你們對(duì)如何理解MySQL Authentication Failed的問題分析與解決方法有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。