昨日、1月31日、Gitlabサービスは本番データベースを誤って破壊しました（gitリポジトリ自体は影響を受けませんでした）。
こんな感じでした。
何らかの理由で、ホットスタンバイデータベースレプリカ（PostgreSQL）が遅れ始めました（レプリカが唯一のものでした）。 しばらくの間、gitlabの従業員がさまざまな設定などで状況に影響を与えようとした後、すべてを消去してレプリカを再び注ぐことを決めました。 レプリカのデータフォルダーを消去しようとしましたが、サーバーを混同してウィザードで消去しました（db2.cluster.gitlab.comではなくdb1.cluster.gitlab.comでrm -rfを実行しました）。
興味深いことに、システムには5種類のバックアップ/レプリカがありましたが、どれも機能しませんでした。 秋の6時間前に偶然作成されたLVMスナップショットしかありませんでした。
ここで、私は彼らの文書から要約された引用を引用します。 見つかった問題：
1）デフォルトでは、LVMスナップショットは24時間に1回のみ取得されます。
2）YPはまだそれらの保存場所を把握できていませんが、定期的なバックアップも24時間に1回しか行われていないようです。
3）Azureのディスクスナップショットは、NFSサーバーでは有効になりますが、DBサーバーでは有効になりません。
4）同期プロセスは、データをステージングに同期すると、webhookを削除します。 過去24時間の定期的なバックアップからこれらを取得できない場合、それらは失われます。
5）複製手順は非常に壊れやすく、エラーが発生しやすく、少数のランダムなシェルスクリプトに依存しており、文書化が不十分です。
6）S3へのバックアップも明らかに機能しません。バケットは空です
7）バックアップが失敗したときのアラート/ページングはありません。これは開発ホストでも見られます。
したがって、彼らは、5つのバックアップ/レプリケーション技術のうち、gitlabを結論づけ、何も確実に機能しなかったので、当然のように=>したがって、ランダムに作成された6時間のバックアップからの回復が進行中です
→
文書の全文はこちら