昨天，我們（Gitlab）網站的一個數據庫發生了嚴重事故。我們（GitLab.com）丟失了 6 小時的資料庫資料（問題，合併請求，使用者，評論，片段等）。Git / wiki 儲存庫和自託管安裝不受影響。丟失生產資料是不可接受的。未來幾天內，我們將會發布此次事故發生的原因及一系列措施的落實情況。

更新 18:14 UTC：GitLab.com 重新線上

截至撰寫本文時，我們正在從 6 小時前的資料庫備份中恢復資料。這意味著在 GitLab.com 再次生效的時候，17:20 UTC和 23:25  UTC 之間資料庫丟失的任何資料都將恢復。

Git資料（儲存庫和維基）和 GitLab的自託管例項不受影響。

以下是本次事件的簡要摘要，詳細內容請查閱文件

事件一：

在 2017/01/31 18:00 UTC ，我們檢測到垃圾郵件傳送者通過建立片段來攻擊資料庫，使其不穩定。然後，我們開始瞭解發生了什麼問題進行故障排除，以及如何防範。

在2017/01/31 21:00 UTC，問題被升級導致在資料庫上的寫入鎖定，這導致網站出現了一些時間段的宕機。

措施：

• 根據IP地址阻止了垃圾郵件傳送者
• 刪除了使用儲存庫作為某種形式的CDN 導致 47 000 個IP 使用同一個帳戶登入（導致高DB負載）的使用者
• 已移除使用者傳送垃圾郵件（通過建立程式碼段）

事件二：

在 2017/01/31 22:00 UTC， – 我們被分頁，因為 DB 複製滯後太遠，導致不能有效地阻止。發生這種情況是因為在輔助資料庫沒有及時處理寫入。

措施：

• 嘗試修復 db2，此時丟失資料約4 GB
• db2.cluster 拒絕複製，/var/opt/gitlab/postgresql/data 擦拭以保證複製
• db2.cluster 拒絕連線到 db1，max_wal_senders太低。此設定是用來限制數量 WAL (= replication)的客戶端
• 團隊成員1調整max_wal_senders 到 32上db1，重啟 PostgreSQL 。
•  PostgreSQL 因同時開啟訊號量太多而拒絕重啟。
• 團隊成員1調整 max_connections 8000 到 2000。PostgreSQL 重啟成功（儘管8000已經使用了近一年）
• db2.cluster 可以連結，但仍然複製失敗，只是掛在那裡沒有執行任何的操作。今晚 23:00 左右（當地時間），團隊成員1明確提到他要簽字，並未想到會突然出現複製問題。

事件三：

在2017年1月31日23：00 左右 —團隊成員1認為， pg_basebackup 拒絕執行是因為 PostgreSQL 的資料目錄存在（儘管是空的），於是決定刪除該目錄。經過一兩秒鐘，他注意到他執行在 db1.cluster.gitlab.com，而不是 db2.cluster.gitlab.com。

在2017年1月31日23:27 時，團隊成員1 -終止刪除操作，但為時已晚。大約 300 GB 左右的資料只剩下約4.5 GB

我們不得不把 GitLab.com 下線，並在 Twitter 上公佈資訊。

遇到的問題

• 預設情況下，LVM 快照每 24 小時採取一次。為了資料庫的工作負載平衡，團隊成員 1 在停電前 6小時手動操作過。
• 定期備份似乎也只能每24小時執行一次，雖然團隊成員1目前仍未能找出它們的儲存位置。團隊成員2表示 ，這些似乎沒有奏效，產生的檔案大小隻有幾個位元組。
• 團隊成員3：看起來 pg_dump 可能會失敗，因為 PostgreSQL 的 9.2 二進位制檔案正在執行，而不是 9.6 的二進位制檔案。這是因為 omnibus 只使用 Pg 9.6 ，如果 data / PG_VERSION 設定為 9.6，但在 workers 上這個檔案不存在。因此，它預設為 9.2，靜默失敗。因此沒有做出 SQL 轉儲。Fog gem 可能已清理舊備份。
• 為Azure 伺服器啟用 Azure 中的磁碟快照，而不是 DB 伺服器。
• 同步過程在 Webhooks 資料同步到暫存後刪除。我們只能從過去24小時的定期備份中提取內容，否則將丟失
• 複製過程是超級脆弱，容易出錯，依賴少數隨機 shell 指令碼並記錄
• 我們的備份到 S3 顯然也不執行：bucket 是空的
• 因此，換句話說，部署的 5 個備份/複製技術中沒有一個可靠地執行或設定。我們最終還原了6 小時的備份。
• pg_basebackup 將等待主機啟動複製程序，據另一個生產工程師稱，這可能需要 10 分鐘。這可能導致程序被卡住。使用 “strace” 執行程序沒有提供的有用資訊。

恢復

我們正在使用臨時資料庫中的資料庫備份來立即恢復。

我們不小心刪除了生產資料，可能必須從備份中還原。谷歌文件與現場筆記 https://t.co/EVRbHzYlk8

GitLab.com 狀態（@gitlabstatus）2017年2月1日

• 2017年2月1日00:36 -備份 db1.staging.gitlab.com 資料
• 2017年2月1日00:55 -在 db1.cluster.gitlab.com 安裝 db1.staging.gitlab.com
• 從分段複製資料 /var/opt/gitlab/postgresql/data/ 到生成 /var/opt/gitlab/postgresql/data/
• 2017年2月1日01:05 – nfs-share01 伺服器 徵用臨時儲存/var/opt/gitlab/db-meltdown
• 2017年2月1日01:18 – 複製剩餘的生成資料，包括pg_xlog，升級為20170131-db-meltodwn-backup.tar.gz

下面的圖表顯示刪除的時間和後續的資料複製。

此外，我們要感謝在Twitter 和其他渠道通過#hugops獲得的驚人支援