【故障公告】14:30-15:30左右，數據庫服務器異常情況引發全站故障
今天下午14:30左右，先是發現博客後台出現502（博客後台的 pod 健康檢查時會連接數據庫，如果連接過慢造成健康檢查失敗，pod 會重啟，如果所有 pod 都因健康檢查失敗而重啟，這時訪問就會出現502）。過了一會，其中1個 pod 重啟成功，博客後台恢復正常。
原以為只是一次短暫的波動，但隨即發現博客站點響應速度變慢，難道數據庫服務器又要出現 CPU 100%了，趕緊登錄阿里雲RDS控制台查看監控，CPU 正常，查看 CloudDBA 性能優化也沒有異常的 SQL，看來數據庫沒出問題。
雖然貌似數據庫沒問題，但響應速度慢的問題越來越嚴重，大量請求執行緩慢，日誌中記錄了大量執行時間超過10秒的請求，查看數據庫的其他監控指標，發現了一個異常情況，數據庫連接數飆升。
14:38 開始日誌中開始出現大量連接超時的錯誤，這時訪問園子從大量請求響應緩慢變成了大量500。
“”Microsoft.Data.SqlClient.SqlException (0x80131904): 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. This failure occurred while attempting to connect to the Principle server. The duration spent while attempting to connect to this server was – [Pre-Login] initialization=15112; handshake=0;
—> System.ComponentModel.Win32Exception (258): Unknown error 258
從阿里雲RDS的監控指標看，除了連接數飆升，其他指標都沒有明顯的異常，真不知道問題究竟出在哪裡，只能拿出處理數據庫故障的治標不治本的絕招——主備切換，第一次切換後問題依舊。這時你也許會想，看你每次圖省事用絕招，這次不靈了吧。你太小看這個絕招了，它可以多次使用，一次不行，可以再來一次。於是，我們進行了第二次主備切換，也就是切換回原來的數據庫實例，然後就恢復正常了。神奇的絕招，CPU 高用它，連接數高也可以用它。
非常抱歉，這次故障給您帶來了很大的麻煩，請您諒解。
就在我們寫這篇博文期間，博客後台又出現了502，而這次數據庫一切正常，但博客後台的3個pod全部因健康檢查失敗而宕機。博客後台採用的基於k8s的藍綠部署，之前版本的pod還在運行中，於是切換到之前的pod恢復正常，之前的pod與502的pod主要不同之處是部署不同的k8s節點上，問題比想像的還要詭異。
註：我們的數據庫服務器用的是阿里雲 RDS SQL Server 2016 標準版，16核CPU，32G內存。應用部署在用阿里雲服務器自己搭建的 Kubernetes 集群上。
