252
技術社區[雲棲]
Gitlab 官方對整個數據刪除事件的詳細說明
昨天，我們（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 上公布信息。
我們正在執行緊急數據庫維護，https://t.co/r11UmmDLDE 將脫機
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” 運行進程沒有提供的有用信息。
恢複
我們正在使用臨時數據庫中的數據庫備份來立即恢複。
我們不小心刪除了生產數據，可能必須從備份中還原。穀歌文檔與現場筆記 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獲得的驚人支持
文章轉載自 開源中國社區 [https://www.oschina.net]
最後更新：2017-07-03 16:02:00