
こんな感じでした。
何らかの理由で、ホットスタンバイデータベースレプリカ(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時間のバックアップからの回復が進行中です
→ 文書の全文はこちら