Gitlab官方對資料刪除事件的詳細說明

Gitlab官方對資料刪除事件的詳細說明
導讀GitLab.com 官方網站發布聲明稱由於其產品資料庫問題導致的網站無法正常訪問。據國外媒體報道稱 Gitlab 網站疲憊的系統管理員深夜在進行資料庫維護時，使用 rm -rf 刪了300GB 生產環境資料。等到清醒過來緊急按下ctrl + c，只有4.5GB保留下來。然後恢複備份失敗，網站宕了10個小時。

我們（Gitlab）網站的一個資料庫發生了嚴重事故。我們（GitLab.com）丟失了 6 小時的資料庫資料。Git / wiki 存放庫和自託管安裝不受影響。丟失生產資料是不可接受的。

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

我們正在從 6 小時前的Database Backup中恢複資料。這意味著在 GitLab.com 再次生效的時候，17:20 UTC和 23:25 UTC 之間資料庫丟失的任何資料都將恢複。

Git資料（存放庫和維基）和 GitLab的自受管理的執行個體不受影響。

事件一：

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

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

措施

1.根據IP地址阻止了濫發垃圾郵件者

2.刪除了使用存放庫作為某種形式的CDN 導致 47 000 個IP 使用同一個帳戶登入（導致高DB負載）的使用者

3.已移除使用者發送垃圾郵件（通過建立程式碼片段）

事件二：

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

措施

1. 嘗試修複 db2，此時遺失資料約4 GB

2.db2.cluster 拒絕複製，/var/opt/gitlab/postgresql/data 擦拭以保證複製

3.db2.cluster 拒絕串連到 db1，max_wal_senders太低。此設定是用來限制數量 WAL (= replication)的用戶端

4.團隊成員1調整max_wal_senders 到 32上db1，重啟 PostgreSQL 。

5.PostgreSQL 因同時開啟訊號量太多而拒絕重啟。

6.團隊成員1調整 max_connections 8000 到 2000。PostgreSQL 重啟成功（儘管8000已經使用了近一年）

7.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 上公布資訊。

1.我們正在執行緊急資料庫維護，https://t.co/r11UmmDLDE 將離線

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

遇到的問題

1. 預設情況下，LVM 快照每 24 小時採取一次。為了資料庫的工作負載平衡，團隊成員 1 在停電前 6小時手動操作過。

2.定期備份似乎也只能每24小時執行一次，雖然團隊成員1目前仍未能找出它們的儲存位置。團隊成員2表示 ，這些似乎沒有奏效，產生的檔案大小只有幾個位元組。

3.團隊成員3：看起來 pg_dump 可能會失敗，因為 PostgreSQL 的 9.2 二進位檔案正在運行，而不是 9.6 的二進位檔案。這是因為 omnibus 只使用 Pg 9.6 ，如果 data / PG_VERSION 設定為 9.6，但在 workers 上這個檔案不存在。因此，它預設為 9.2，靜默失敗。因此沒有做出 SQL 轉儲。Fog gem 可能已清理舊備份。

4.為Azure 伺服器啟用 Azure 中的磁碟快照，而不是 DB 伺服器。

5.同步過程在 Webhooks 資料同步到暫存後刪除。我們只能從過去24小時的定期備份中提取內容，否則將丟失

6.複製過程是超級脆弱，容易出錯，依賴少數隨機 shell 指令碼並記錄

7.我們的備份到 S3 顯然也不運行：bucket 是空的

8.因此，換句話說，部署的 5 個備份/複製技術中沒有一個可靠地運行或設定。我們最終還原了6 小時的備份。

9.pg_basebackup 將等待主機啟動複製進程，據另一個生產工程師稱，這可能需要 10 分鐘。這可能導致進程被卡住。使用 “strace” 運行進程沒有提供的有用資訊。

恢複

我們正在使用臨時資料庫中的Database Backup來立即恢複。

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

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

1.2017年2月1日00:36 -備份 db1.staging.gitlab.com 資料

2.2017年2月1日00:55 -在 db1.cluster.gitlab.com 安裝 db1.staging.gitlab.com

3.從分段複製資料 /var/opt/gitlab/postgresql/data/ 到產生 /var/opt/gitlab/postgresql/data/

4.2017年2月1日01:05 - nfs-share01 伺服器 徵用臨時儲存/var/opt/gitlab/db-meltdown

5.2017年2月1日01:18 - 複製剩餘的產生資料，包括pg_xlog，升級為20170131-db-meltodwn-backup.tar.gz

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

本文地址：http://www.linuxprobe.com/gitlab-remove-explain.html