今天下午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 叢集上。