SQL Server 2012 AlwaysOn 群集上的定期連接失敗
自上週三以來（所以我們現在正在處理這個問題一周），我們的生產數據庫集群定期出現連接問題。（在 windows 2012 上執行的 alwayson 集群，三台機器，兩台同步和一台非同步）。
當它開始時，我們注意到 SQL 事件日誌中的以下兩條消息自問題出現以來一直在重複；
- 錯誤：18456，嚴重性：14，狀態：46。
- 使用者“xxx”登錄失敗原因：在重新驗證連接上的登錄時，無法打開登錄對像中配置的數據庫“xxx”。$$ CLIENT: xxx.xxx.xxx.xxx $$
我們一直在嘗試幾乎所有事情，目前正處於絕望之中。我們嘗試過的事情；
- 重啟我們的防火牆
- 重啟我們的交換機
- 故障轉移並重新啟動節點（一個接一個）
- 關閉非同步節點，看看是否有任何變化
- 關閉除主節點以外的所有節點以查看是否有任何變化
- 更換開關
- 移除一些網線並在一個 NCI 上執行
- 從伺服器中刪除綁定並故障轉移到此伺服器
這似乎無濟於事。
連接程式碼收到的錯誤從開始事務時的超時到執行查詢的超時不等。（當查找執行時間超過 5000 毫秒的查詢時，該查詢未顯示在 SQL 事件探查器中）。
然而，對我來說最奇怪的錯誤如下；
System.Data.SqlClient.SqlException: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=0; handshake=14991;現在我絕不認為自己是一個真正的 DBA，我管理軟體開發部門，實際上目前正在尋找僱用一個……但是根據我的經驗和我有限的知識，我覺得看不到這些是很奇怪的在我的探查器中超時的查詢…
事實上，我沒有看到任何阻止查詢或以任何方式引起我懷疑的查詢……
在這裡要補充的另一件事是，它似乎是一波又一波的……有時一切都很好，持續 15-25 分鐘，然後在 2-5 分鐘內變得糟糕。這也會發生一整天，所以不是在高峰時間或我們的正常流程執行時。（基本上，我看到我們的 API 嘗試訪問數據庫時出現錯誤，很少有程序在@night 執行，而且沒有一個是定期執行的）。
整個網路也在經歷這種情況，這意味著我可以排除程式碼，因為我們沒有發布任何更改，也沒有以相同的方式連接到數據庫。（一些通過 NHibernate，一些 ADO.NET，一些舊 ADO）
最大的變化發生在網路端，但我們的系統管理員似乎堅持認為不可能，因為沒有任何變化會影響這一點，而且他們在交換機上看不到任何可疑的東西。
這裡有人知道我們接下來可以嘗試/應該看什麼嗎？
至少在某種程度上，這將是迄今為止找到的答案，是的，直到昨晚才完全解決了這個問題。
實際上，我們仍然並不真正信任網路，我們有工程師正在調查這個問題，因為我們也有其他投訴，但是儘管所做的更改是 100% 圍繞基礎設施和網路進行的，但到目前為止，我們唯一設法修復和更改的是 on事情的程式碼結束。
實際上，我們有一個軟體可以查找放入文件夾（熱文件夾）中的文件，並確保我們每 15 分鐘不會錯過任何內容，我們會檢查是否有我們尚未處理的文件。我們有很多這樣的東西，它們總是執行良好，也沒有任何改變。
這是發生的場景；
- 我們開始遇到問題的那一天，一個文件被放置在一個文件夾中並被處理
- 同一天，同樣的文件又被放在那裡
現在它自己的程式碼很糟糕，它執行了 2-20 分鐘，這取決於今天已經被快速重寫，可以在大約 20 秒內執行。導致此問題的程式碼中有兩個重大錯誤；
- 如果文件中的任何行（它是一個 XML 文件）都不是要處理的，則該文件將保留在那裡。每約 15 分鐘觸發一次新的執行（因此下一個問題將無限期地一遍又一遍地發生）
- 每一行都會呼叫一個儲存過程並使用 DataReader 來查看它是否有任何結果，如果有的話，呼叫將移動到下一行而不關閉閱讀器
這兩件事的結合（事實上，這些文件有 100 行，如果不是 1000 行的話）讓我們的系統癱瘓了，跪著乞求結束。
辦公室裡有人指責“連接池”，他可能是對的，他可能不是。老實說，我不確定為什麼這會導致我們的系統受到如此可怕的影響（順便說一句，導致它的程式碼不會在這個軟體上出現異常或問題。這使得它很難找到）。
因此，如果有人能解釋為什麼這會破壞我們的 SQL 伺服器，我會很高興，我所知道的是，作為等待類型的 ASYNC_NETWORK_IO 可能是最大的線索，但我沒有足夠的 DBA 快速找到罪魁禍首。因此，如果有人對我們如何指出這一點有任何想法/疑問，我很樂意給他們解決方案投票。