今天下午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 集群上。
【更新】5月8日早上9:30左右又出現了一會數據庫連接數飆升訪問速度變慢的問題，目前排查分析下來懷疑與我們因網站整改增加的關鍵詞過濾有關。在進入每天的訪問高峰之前（這2次故障都是發生在這個時間段），會有大量的博文從數據庫讀取並建立緩存，而增加的關鍵詞過濾操作就發生在寫入緩存之前，這個操作開銷很大，會造成很多博文不能快速建立緩存。
