昨天，我們（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 上公布資訊。
gitlab.com 狀态（@gitlabstatus）2017年1月31日
遇到的問題
預設情況下，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” 運作程序沒有提供的有用資訊。
恢複
我們正在使用臨時資料庫中的資料庫備份來立即恢複。
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獲得的驚人支援