數據庫復制故障讓五臺 PostgreSQL 服務器中的三臺徹底趴下。

在一起典型的故障事件中，GitLab昨天無意中觸發了數據庫故障切換，因此降低了性能。

由此引發的“大腦分裂問題”讓這家代碼收集網站試圖靠單單一臺數據庫服務器postgres-02來服務廣大用戶，同時竭力恢復另外三臺數據庫服務器。

這個問題最初出現在美國時間周四凌晨1：30左右，因此而來的重構工作仍在繼續之中。

GitLab.com的推文內容如下：

 由于數據庫負載，我們目前正在調查GitLab.com上的性能下降和錯誤。

意外的故障切換被觸發后，亞歷克斯•漢塞爾卡（Alex Hanselka）寫道，雖然服務器群“繼續追隨真正的主服務器”，但這起事件顯然令人痛苦：

“由于postgres-01是出岔子的主服務器，我們關閉了它。我們在調查時發現，postgres-03和postgres-04都試圖追隨postgres-01。正因為如此，我在寫這個問題單（issue）時，我們正在postgres-03上重構復制內容，完成后又在postgres-04上重構復制內容。”

我們在繼續調查GitLab上的性能下降問題。想了解詳情，請參閱:https://docs.google.com/document

影響性能的還有備份（由于故障切換之前沒有完整的pg_basebackup，所以需要備份）；由于Sidekiq集群導致龐大的查詢，GitLab只好關閉了該集群。

問題剛出來時就是這個情況：近20個小時后，故障工單還沒有完結。

一開始，postgres-03的備份以每小時75GB的速度執行，直到23：00（晚上11點）后才完成。仍有其他數據庫任務需要完成，但是從安德魯•紐迪蓋特（Andrew Newdigate）的帖子來看，性能開始恢復正常。

自21：30 UTC以來，持續集成/持續交付（CI/CD）隊列恢復常態?，F在管道以平常的速度來加以處理。

這里還附有時間表：https://docs.google.com/document

至少備份奏效了：2017年2月，備份故障讓數據復制錯誤雪上加霜：“所以換句話說，在部署的5種備份/復制方法中，沒有一個可靠地運行或一開始就設置好。”

在一臺登臺服務器（staging server）上發現了丟失的數據；作了深刻的反復之后，營銷副總裁蒂姆•安格拉德（Tim Anglade）告訴IT外媒The Register，他深知GitLab的重要性，這是“對許多人的項目和公司來說很重要的網站。”

不得不說，切實有效的備份至少表明已汲取了一些經驗教訓。