GitLab PostgreSQL事後分析

2017年1月31日、GitLabでPostgreSQL DBMSの操作に関連する事故が発生しました。その結果、データの一部が削除され、復旧中にプロジェクトが停止しました。 数ヶ月が経過し、このトピックについて多くのことが書かれました。GitLab自身が徹底的な死亡記事を発表し、何が起こったのか、どのような対策が講じられ、そのような事故を防ぐためにどのような対策が講じられるのかを伝えました。 非常に面白い読書です。Postgresから遠く離れている人でも読むことをお勧めします。



Alexei Lesovskyとのインタビューへのコメントで、コミュニティの一部のメンバーは冗談でGitLabの事故に言及したと不平を言っていましたが、最終的に詳細な報告を行いませんでした。 私たちは改善することに決め、アレクセイに小さな「報告」を書くように依頼しました。 この出版物の主な目的は、死亡記事の詳細な分析を行い、重要なポイントを強調し、それらを分析し、同様の状況で行動する方法に関する推奨事項を提供することです。 そして、もちろん、GitLabチームが将来このような事件を防ぐために講じる計画を検討してください。

私たちが注意を払う年代順のキーポイントのリストは次のとおりです。

1. データベースを実稼働からステージングに転送する手段としてのLVMスナップショット。
2. レプリカがマスターより遅れた場合の対処方法
3. pg_basebackupを正しく行います、パート1。
4. max_wal_sendersのうち、どのように？
5. max_connections = 8000。
6. pg_basebackupの「ハングアップ」、またはpg_basebackupの正しい実行、パート2。
7. strace：これは管理者に適しています。dbaには必ずしも必要ではありません。
8. rmまたはrmではない：機密データをどうするか？
9. バックアップ方法。
10. 本番環境のPostgresの異なるバージョン。
11. 王冠の壊れたメール。

デブリーフィングを始めましょう。 また、最後に2番目のリストがあります。このリストでは、同様のインシデントの再発を防ぐために、これまでに講じた措置または今後講じる措置を簡単に分析します。

1.データベースを実稼働からステージングに転送する手段としてのLVMスナップショット。

ステージング環境を更新するタスクは非常に一般的であるため、確立されたプラクティスとソリューションがすでに登場しています。 そのようなソリューションの1つは、スナップショットを作成し、スナップショットをステージングに転送することです。 このソリューションは非常に便利で簡単にカスタマイズできますが、いくつかの欠点があります。 ほとんどのスナップショットの実装はコピーオンライトに基づいているため、スナップショットが存在するときにスナップショットを作成すると、ディスクストレージに追加の負荷がかかります。 基本的に、これは書き込み集中型のワークロードに関連しています。 待ち時間が重要な場合、これが問題になる可能性があります。

データベースを本番からステージングに転送するより適切な方法は、バックアップです。 カスタマイズされたバックアップがあり、そこからステージングが更新されます。 この状況では、イメージによって追加の負荷が作成されることはなく、復元の成功についてバックアップが間接的にチェックされます。 ステージングが更新されない場合、これはバックアップに何か問題があることを明確に示しています。

2.レプリカがマスターより遅れた場合の対処方法

残念ながら、この記事では、エンジニアがレプリケーションラグの存在をどのように発見したかについては言及していませんが、レプリカが最終的に取り返しのつかないほど落ちたため、手遅れになったと結論付けることができます。 ここでどのような推奨事項を作成できますか？ もちろん、理想的には、アラートでレプリケーションラグを監視します。 ただし、「ニーハイ」方式は、文字、SMS、または他の何かの後続の送信で王冠のスクリプトで遅れをチェックするためにも使用されます。

ストリーミングレプリケーションを使用する場合、ラグモニタリングは、構成後すぐに実行する必要があるものの1つです。 レプリカが遅れ始める理由はたくさんあります。 Postgresのレプリケーションを監視するためにpg_stat_replicationビューがあります-これは非常にクールなものであり、ある程度の経験があり、ラグの原因（ネットワーク、ディスク、長いリクエストなど）を特定することもできます。

レプリカが遅れていることがわかり、取り返しのつかないほど落ちるのがわからない場合、一時的な解決策はwal_keep_segmentsパラメーターを増やすことです。 このパラメータは、通常のリロード（pg_reload_conf（）を参照）でpostgresを再起動せずに更新されますが、価格はディスク領域の使用量の増加である可能性があり、1セグメントは16MBです。 パラメータを増やした後、検索を開始して遅延の原因を取り除くことができます。

また、WALアーカイブを使用していないことを認めていることにも注意してください。これも無駄でした。これはレプリカの復元に役立ちます。 しかし、一般的に、WALアーカイブの役割は、レプリカを保護するタスクだけではありません。 pg_basebackupを介したバックアップがある場合、アーカイブを使用すると、柔軟にリカバリを管理できます（ポイントインタイムリカバリを参照）。

3. pg_basebackupを正しく行います、パート1。

死亡記事からわかるように、pg_basebackupを開始する前に、エンジニアはベースバックアップのコピー先のディレクトリをクリアしました。 実際、pg_basebackupは、ディレクトリが空でないことを検出すると、すぐに終了します。 ただし、機密データを扱う場合は、rmではなくmvを使用することをお勧めします。 小容量ディスクの時代は過ぎ去り、そのようなルールは人生をはるかに楽にします。 これは、ディレクトリだけでなく、データベース内のテーブル、接尾辞_oldなどのデータベースにも適用されます。 これはテラバイトのデータベースでは機能しませんが、オブジェクトの名前を変更し、数週間後に誰もそれを必要としないことを確認して、すぐに削除するよりも静かに削除することをお勧めします。

4. max_wal_sendersは終了しましたが、どうですか？

pg_basebackupを接続するときに、max_wal_sendersの制限を超えたというエラーを超えました。 このパラメーターは、レプリケーションの同時接続の制限を定義します。 覚えているなら、GitLabにはレプリカが1つしかなく、そのレプリカは取り返しのつかないほど落ちました。 したがって、すべての接続は無料である必要があります。 しかし、エンジニアリングチームはエラーに遭遇し、複数のpg_basebackupを同時に実行しようとする以外のオプションはありません。

一般に、これは無意味です。最初のpg_basebackupが機能しない場合、なぜ2番目のpg_basebackupが機能するのですか？ ただし、このエラーが引き続き発生する場合は、max_wal_sendersを変更するにはpostgresを再起動する必要があり（これは受け入れられないことが多い）、誰が接続を取得したか（およびこれらがpg_basebackupsを待機していた）を見つけて停止することを忘れないでください。 なぜ制限を引き上げるのですか？ 同時pg_basebackupをさらに実行するには？

5. max_connections = 8000

次のポイントは、8000に設定された接続制限です。これは、この設定の非常に大きな数値です。 Postgresは、クライアント接続ごとに個別のプロセスが生成されるように配置されています。 これはすべて、システム内のプロセッサコアよりも積極的に動作するpostgresバックエンドがなくなるまでうまく機能します。 その後、プロセスがさらに増加すると、生産性が低下し始めます。

postgresへの多数の接続を維持しないために、pgbouncerが発明されました。これにより、多数のクライアント接続をpostgresへの比較的少数の接続に圧縮できます。 たとえば、同じ8000クライアント接続をpgbouncerで閉じることができ、必要な場合にのみpostgresへの接続を確立します。 繰り返しますが、pgbouncerを使用すると、発生したエラーやpostgresの追加の再起動に時間を浪費することを回避できる可能性があります。

6. pg_basebackupを「ハング」するか、pg_basebackupを正しく実行します（パート2）。

次に進みます：接続の制限は修正されましたが、なぜpg_basebackupがフリーズするのかを理解する必要がありますか？ いわゆるフリーズの理由は、pg_basebackupの詳細にあります。 データベースのコピーを開始する前に、いわゆる処理が完了するまで待つ必要があります。 「チェックポイント」（チェックポイント）。 チェックポイントは、postgresに大きな負担をかける可能性がある手順であり、その結果、パフォーマンスが大幅に低下します。 したがって、システムに負担をかけないために、pg_basebackupはデフォルトで通常のチェックポイントが終了するのを待ちます。その時間と速度はpostgresの設定に依存します。 -c fastパラメーターを指定すると、pg_basebackupは遅滞なく緊急チェックインを開始します。

ご理解のとおり、チェックポイントの終了を待機するプロセスでは、pg_basebackupはメッセージを書き込みません。これはエンジニアにとってトリックです。 ただし、GitLabチームのおかげで、 postgresは改善されます。

7. strace：管理者に適しています。dbaの場合は必ずしも必要ではありません。

さらに、エンジニアはpg_basebackupがフリーズする理由を見つけようとし、これにstraceを使用しました。 私自身の経験から言えば、straceはあなたが必要とするものではないということができます。 straceは、調査中のプロセスがエラーで失敗するか、ある時点で正しく機能しないときに必要です。 topユーティリティを使用すると、プロセスが「ハング」していることがわかります。％CPUフィールドに0が表示されている場合、プロセスは待機している可能性が非常に高くなります。

そして、いわゆる「フリーズ」の原因を調査するには、現在どの機能が実行されているかを理解するためのプロセスのスタックトレースが必要です。 これには、/ proc //スタックと、ある程度の経験があれば、gdbが適しています。 残念ながら、Postgres自体にはプロセスの内容を確認する機会がなく、コピーの開始を待っているため、エンジニアはpg_basebackupの機能を知っている必要があります。

8. rmまたはrm：機密データをどうするか？

ウィザードのデータベースディレクトリが削除された瞬間になりました。 実際、この点は上記の繰り返しです。可能であれば、mvを使用してください。 rmを使用するのは、データが欠落していると言われている人がいないことを確認してからです。

9.バックアップ方法。

そのため、事故が発生したため、バックアップからのリカバリを実行する必要があります。 チームが依存しているバックアップ方法を見てみましょう。

• 毎日のpg_dump：特定の時点（pg_dumpの開始時間）でのみリカバリを提供する、かなり愚かな方法。
• 毎日のLVMスナップショット-データベースに書き込み集中型の負荷がかかっていなければ、この方法に関する苦情はありません。
• Asureの毎日のショット：ここで言うことはありません。使用する必要はありませんでした。
• マスターからのレプリケーション：誤ってデータを削除するとレプリカにレプリケートされるため、レプリケーションはバックアップとは見なされません。 レプリケーションを遅延リカバリで使用できます（recovery_min_apply_delayを参照）が、この状況では、何かが誤って削除された場合のリカバリ方法を理解する必要があります。

何らかの方法で、一般的な推奨事項は次のとおりです。バックアップとしてレプリカを使用しないようにしてください;バックアップのためのツールがあります。 最も好ましいツールは、pg_basebackup + WALアーカイブです。 この方法を使用する主な利点は、既存のアーカイブ内の特定の時点またはトランザクション番号でデータを復元できることです。 ただし、このソリューションには欠点があります-ローカル要件。 各ベースバックアップはインスタンスの完全なコピーであり、アーカイブのサイズはCRUD操作の数に依存します。 したがって、バックアップを設定するときは、ストレージの日数を考慮して、バックアップ用のストレージの合計サイズを考慮する必要があります。

現時点では、このバックアップモデルを実装する製品がいくつかあります。

1. 独自のサーバーがある場合は、バーマン。
2. サーバーがAmazon上にある場合は、WAL-E。

最後に追加できるのは、1）バックアップが正常に行われていることを監視する必要があることです。 2）通常、バックアップが存在します。 3）バックアップからのテスト復元の結果があります。

10.本番環境の異なるバージョンのPostgres。

あなたが欠点を見つけることができる次のポイントは、生産の可能性の異なるバージョンの存在です。 GitLabの場合、これによりバックアップを取得できなくなりました。 したがって、次のメジャーバージョンにアップグレードする計画では、古いpostgresパッケージを削除する必要があります。

11. kroonでメールが壊れています。

私には思えますし、多くの人が私に反対するかもしれませんが、メール通知はかなりまれな通知メカニズムになりつつあります。 それにもかかわらず、どのメカニズムを使用しても、それが実際に機能することを常に確認する必要があります。 私の練習では、SMSコマンドを通知する監視内で、勤務中の管理者に毎晩テストSMSを送信し、オペレーターと天びんですべてが正常であることを確認する機能があった場合がありました。 障害が発生すると、メールスパムが開始され、Webインターフェイスのフラグが点灯しました。これは本当に役立ちました。

GitLabの場合、cronのメールは最初は設定されていませんでした。 冠に重要なものを入れたら、通知について考えてください。

その結果、データベースはLVMイメージから復元され、コピーには18時間かかりました。これは非常に長い期間です。 同時に、写真はステージングであり、これが最も受け入れられるオプションであることが判明しました。 これはすべて、バックアップ戦略の失敗（24時間ごと）と偶然の一致です。 結果は、データの損失を最小限に抑える、より柔軟な回復オプションを使用した、より思慮深いバックアップ方法です。

GitLabチームは、今後同様のイベントを回避するためにとるべき措置に関する情報を投稿しました。 それらについても簡単に見てみましょう。

1.すべてのホストでPS1を更新して、ホストと環境をより明確に区別します（＃1094）。

それは非常に合理的です。 カスタムコマンドラインプロンプトテキストを作成することは、かなり一般的であり、良い習慣です。

2.バックアップのプロメテウス監視（＃1095）。

この方法も非常に合理的に見えますが、バックアップシステム全体を確認して再構築した後で監視を行う必要があります。 監視には、バックアップの経過時間とサイズだけでなく、使用可能なバックアップの数、および回復のために正常にチェックされたコピーに関する情報も含める必要があります。

3. PostgreSQLのmax_connectionsを正しい値に設定します（＃1096）。

800でも多すぎるので、pgbouncerを見て使用することをお勧めします。 ただし、独自の制限があり、それを使用するアプリケーションに課しているため、ここでは事前にテストする必要があります。

4. PostgreSQLのポイントインタイムリカバリと継続的アーカイブを調査します（＃1097）。

はい、これを行う必要があります。

5.本番データベースの1時間ごとのLVMスナップショット（＃1098）。

画像がステージングの更新に使用されたことを考えると、疑わしいアイデアです。 この目的のために、タスク＃1097の一部として作成されたバックアップも非常に適しています。

6.本番データベースのAzureディスクスナップショット（＃1099）。

コメントするのは難しいですが、バックアップの主な機能を複製したい場合は、なぜですか？

7.ステージングをARM環境に移動します（＃1100）。

タスクは奇妙に見えます。 すべてのデータを大幅に変更できるステージングからプロダクションを復元することは、最終的にはそのようなリカバリからの疑わしい取り組みであり、悪化するだけです。

8.本番レプリカを復元します（＃1101）。

もちろん、これはできるだけ早く行う必要があります。 多少なりとも深刻なpostgresインストールは、少なくとも1つのストリーミングレプリカで展開されます。

9. PostgreSQLデータベースバックアップのリカバリの自動テスト（＃1102）。

はい、これは非常に必要なことです。間違いなく必要です。

10. PostgreSQLレプリケーションのドキュメント/ランブックを改善（＃1103）。

はい。指示は、近隣の倉庫の夜間警備員でも回復できるように更新する必要があります。

11. PostgreSQLバックアップを作成するためのpgbarmanを調査します（＃1105）。

はい、バーマンは間違いなく優れたツールですが、GitLabがAmazon S3を使用していることを考えると、WAL-Eが望ましいようです。 ただし、Barman開発者はその可能性を排除せず、BarmanでのAmazon S3のサポートを後援することさえ申し出ます。

12.データベースバックアップおよびリアルタイムレプリケーションの手段としてWAL-Eを使用して調査します（＃494）。

はい、トラッカーにはかなりの数の問題がありますが、問題なく安定して動作します。

13.ストリーミングデータベースの復元を構築します。

はい、ちょうどそのように、バックアップがあり、ステージング環境でのリカバリによるこれらのバックアップの復元のチェックがあります。

14.データの永続性の所有者を割り当てます。

責任者が必ず必要です。 また、＃1103のフレームワークで作成された指示をよく理解しておくことをお勧めします。



詳細な分析をしてくれたAlexeiに感謝します。 Gitlabでの事故と講じられた対策についてのコメントと考えを残してください！ さて、もちろん、私たちは夏にPGデイロシアでサンクトペテルブルクのレシャとこのトピックを議論するために皆を招待します！ :)