成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

MySQL Authentication Failed的問題分析與解決對策

數據庫 MySQL
在應用端,偶爾看到有如下報錯:Authentication to host 'xxxx' for user 'yyyy' using method 'mysql_native_password' failed with message: Reading from the stream has failed. 本文將對它進行分析并給以解決對策。

問題描述

在應用端,偶爾看到有如下報錯:Authentication to host 'xxxx' for user 'yyyy' using method 'mysql_native_password' failed with message: Reading from the stream has failed. 

表現特征:

  1. 只有用Connector/NET 出現這個問題, 用JDBC驅動沒有類似問題。
  2. 多臺應用服務器,只有一臺報這個錯。因此可以排除服務器端的問題。
  3. 問題非常隨機。重啟一下服務器/IIS,就能臨時解決問題。
  4. 有一些場景應用服務器CPU并不是很高,也會偶爾拋出這個錯來。

客戶端是Windows機器, 驅動是MySQL Connector  ADO.NET Driver for MySQL (Connector/NET) ,使用的版本是6.9.9是比較新的版本。

問題分析

我們在應用服務器端和數據庫端抓包。兩邊抓到的包是一致的。可以排除網絡包丟失問題。下面是抓到的包,以及時間點:

從上述網絡包的交互來看, 前面三個包是TCP的三次握手協議。問題出在第六個包,數據庫服務器向應用服務器發送了一個Finish包,來終止數據庫的連接。數據庫發送Finish包,是由于數據庫端發現連接超時而發送的。 這是由服務器端的Connect_timeout這個變量來控制。原因在于應用端超過10秒未向數據庫服務器端發送網絡包。從網絡包交互的情況來看,第五個包和第六個包的時間間隔剛好是10秒。

對比正常的數據庫連接和上面異常的數據庫連接。 應用服務器發送第5個包到數據庫端后, 應該緊接著發送下面的網絡包到數據庫端的。這個包主要是發送賬號,驅動版本,操作系統信息等到數據庫服務器端。【下面是部分的正常的網絡包截圖】。在出現異常報錯的場景,客戶端是延遲發送這個包的。在Frame 8才發送的。而此時連接已經被Finish了,在Frame 9,數據庫端發送了一個Reset包到應用服務器,徹底中斷連接。

我們現在具體分析,為何客戶端發送賬號,驅動版本,操作系統信息到數據庫端這么慢。這部分的代碼在Connector/NET的MySQLAuthenticationPlugin.cs文件中。 我們修改這部分代碼,進行時間埋點,來進一步定位問題。下面是根據時間埋點,打印出來的跟蹤信息。

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

這段代碼是通過WMI查詢,來獲得Caption信息。也就是操作系統的版本信息。由于是WMI調用,所以依賴的關系比較多且與操作系統的狀態相關。

問題驗證

為了驗證是否為WMI偶發且頻繁的延時導致生產環境的某些機器出現通訊異常,我們把這段代碼抽出來。下面是一段簡短的重現代碼:

 

在有問題的應用服務器上,我們運行上述代碼,確實可以發現WMI查詢有超時。下面這些日志信息是我們抓到的查詢超過30秒的WMI信息查詢操作。由此完全確認是該操作導致MySQL authentication failed錯誤。

  1. 2017-11-21 17:19:30.208,       33638 
  2.  
  3. 2017-11-21 17:20:09.193,       33199 
  4.  
  5. 2017-11-21 17:20:53.086,       33201 
  6.  
  7. 2017-11-21 17:27:05.114,       32976 
  8.  
  9. 2017-11-21 17:28:19.178,       33635 
  10.  
  11. 2017-11-21 17:30:07.130,       65977 
  12.  
  13. 2017-11-21 17:30:49.051,       40478 
  14.  
  15. 2017-11-21 17:31:15.126,       26072 
  16.  
  17. 2017-11-21 17:38:16.048,       66671 
  18.  
  19. 2017-11-21 17:38:49.204,       33152 
  20.  
  21. 2017-11-21 17:39:53.161,       33828 
  22.  
  23. 2017-11-21 17:40:38.121,       33549 
  24.  
  25. 2017-11-21 17:47:09.179,       33775 
  26.  
  27. 2017-11-21 17:47:57.174,       33164 

解決思路

WMI查詢慢,可能是由于多種原因所致。如操作系統CPU高,或者查詢本身有死鎖。這個問題有待于進一步分析。但看代碼,我們知道做這個WMI查詢,只是為了獲得操作系統的信息。這個信息完全可以緩存起來。而不必要每次連接的時候,去進行WMI查詢。

此處確定該錯誤的根本原因在于MySQL的C# connector中對操作系統信息的獲取時間過久,導致觸發服務器的連接超時。注釋掉該部分可能導致長時間的操作,在問題機器上進行進一步的驗證,再無任何的超時錯誤出現。

 

由于應用端的系統信息相對來說是靜態信息,因此Connector/Net可以通過環境變量獲取這些信息,繞過WMI調用查詢。這樣每次進行連接時,可避免出現查詢超時的問題,并且能夠提高Connector/Net的效率。 

責任編輯:龐桂玉 來源: DBAplus社群
相關推薦

2015-03-17 21:01:12

2013-06-19 10:03:42

2023-10-18 14:14:59

數字化轉型

2010-06-30 14:15:08

SQL Server死

2024-07-29 00:01:00

RabbitMQ消息堆積

2009-06-16 14:08:10

JBoss JDBC驅

2011-06-16 11:04:09

光纖損耗

2012-11-28 13:37:27

.NET.NET社區

2021-03-26 10:40:16

MySQL鎖等待死鎖

2010-05-28 18:05:22

jsp MySQL

2010-09-08 12:58:20

2010-09-01 17:30:38

2017-05-15 12:05:33

2011-08-24 17:41:16

MySQL死鎖

2021-09-07 18:23:37

數據清理對策

2024-06-17 08:24:09

2021-09-10 11:19:41

醫療行業CISO網絡攻擊

2017-06-14 22:11:57

數據庫MySQL死鎖

2021-06-08 08:38:36

MySQL數據庫死鎖問題

2011-03-22 16:09:33

MySQL 5.0.1亂碼
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 操人视频在线观看 | 欧美黄色小视频 | 精品毛片| 亚洲日韩中文字幕一区 | 特黄av| 日韩视频免费看 | 欧美国产日韩在线观看 | 色婷婷激情综合 | 美日韩免费视频 | 日韩五月天 | 中文字幕在线观看国产 | 国产精品美女久久久 | 免费国产一区二区 | 精品毛片| 手机在线观看 | 色视频网站免费 | 91av在线免费播放 | 色综合视频 | 国产特黄一级 | 日韩精品在线播放 | 国产精品久久久久一区二区三区 | 色在线免费视频 | 欧美综合一区二区 | 观看毛片 | 欧美日韩视频在线 | 一本色道久久综合亚洲精品高清 | 国产欧美日韩在线观看 | 狠狠操av | 在线亚洲人成电影网站色www | 97视频久久 | 国产精品国产三级国产aⅴ中文 | 黑人一级黄色大片 | 日韩精品一区二区三区视频播放 | 亚洲一区二区精品视频 | 国产色片 | 精品视频在线观看 | www.天天操.com | 青青久久 | 日日噜噜噜夜夜爽爽狠狠视频, | 狠狠干天天干 | 欧美视频在线播放 |