Clever Geek Handbook

sudo rm -rf、たたは2017/01/31からのGitLab.comデヌタベヌスでのむンシデントの蚘録



圌はゆっくりず酔っおいたが、それでもゞャンプで酔っ払った。 そしお、悟りの瞬間に、圌は目の前で完党になじみのない郚屋で切り刻たれたオヌクのテヌブル、圌の手に描かれた剣、呚りのお金のないドンをたたくのを芋たずき、圌は家に垰る時だず思った。 しかし、手遅れでした。



アルカディずボリス・ストルガツキヌ

GitLab.comの管理者の1人がレプリケヌションを修正し、コン゜ヌルを混同し、メむンのPostgreSQLデヌタベヌスを削陀したため、OpenSourceの䞖界にずっお重芁なむベントが2017幎1月31日に発生したした。その結果、倧量のナヌザヌデヌタが倱われ、サヌビス自䜓がオフラむンになりたした。 さらに、5぀の異なるバックアップ/レプリケヌション方法はすべお動䜜䞍胜であるこずが刀明したした。 デヌタベヌスが削陀される6時間前に誀っおLVMむメヌゞから回埩したした。 圌らが蚀うように、それは起こりたす。 しかし、私たちはプロゞェクトチヌムに敬意を衚さなければなりたせん。圌らはすべおをナヌモアで扱う匷さを芋出し、頭を倱いたせんでした。Twitterですべおに぀いお曞いお、実際には、チヌムがリアルタむムで投皿した内郚ドキュメントを共有するこずで、驚くべきオヌプン性を瀺したした展開むベントの説明。







それを読んでいるず、あなたは文字通り貧匱なYPのように感じたす。苊しい䞀日の埌の午埌11時にPostgresずの闘争に倱敗し、疲れお目を现めお、臎呜的なsudo rm -rf



を戊闘サヌバヌのコン゜ヌルに抌し蟌み、Enterを抌したす。 しばらくしお、圌は自分がしたこずを理解し、削陀をキャンセルしたすが、手遅れです-これ以䞊のベヌスはありたせん...







このケヌスの重芁性ず倚くの点で有益なため、むンシデントの䜜業䞭にGitLab.comスタッフが䜜成した圌のゞャヌナルレポヌトをロシア語に完党に翻蚳するこずにしたした。 カットの䞋で結果を芋぀けるこずができたす。







それでは、それがどのようであったかを詳现に調べたしょう。







2017幎1月31日からのGitLab.comデヌタベヌスに関するむンシデント



泚このむンシデントはデヌタベヌスに圱響したした問題ずマヌゞリク゚ストを含む。 gitリポゞトリずwikiペヌゞは圱響を受けたせんでした。







YouTubeでラむブ -問題を議論しお解決する方法に埓っおください







  1. 被った損倱
  2. タむムラむンUTCで瀺される時間
  3. 埩旧-2017/01/31 23:00玄17:20 UTCからのバックアップ
  4. 問題点
  5. からの助け

    • HugOpsここず、人々が芪切に反応した他の堎所からのTwitter投皿を远加したす
    • スティヌブン・フロスト
    • サム・マクロヌド


被った損倱



  1. 箄6時間でデヌタが倱われたした。
  2. 4,613の通垞プロゞェクト、74のフォヌク、350の茞入品が倧䜓倱われたした。 Gitリポゞトリは倱われないため、デヌタが倱われる前にナヌザヌ/グルヌプが存圚しおいたプロゞェクトを再䜜成できたすが、これらのプロゞェクトの問題を埩元するこずはできたせん。
  3. 箄4979玄5000のコメントを倱いたした。
  4. 朜圚的に倱われた707人のナヌザヌKibanaのログによるず、より正確に蚀うのは困難です。
  5. 1月31日17:20より前に䜜成されたWebフックは埩元され、埌に䜜成されたす-は倱われたす。


タむムラむンUTCで瀺される時間



  1. 2017/01/31 1600/1700-21:00

    • YPはステヌゞングでpgpoolずレプリケヌションの蚭定に取り組んでおり、LVMスナップショットを䜜成しお戊闘デヌタをステヌゞングにロヌドしたす。たた、このデヌタを䜿甚しお他のレプリカぞのデヌタベヌスのロヌドを高速化できるこずを期埅しおいたす。 これは、デヌタ損倱の玄6時間前に発生したす。
    • レプリケヌションの蚭定には問題があり、非垞に時間がかかりたす初期同期pg_basebackupの堎合のみ玄20時間。 YPはLVMスナップショットを䜿甚できたせんでした。 この段階での䜜業は䞭断されたしたYPは、その日は働いおいなかった別の同僚の助けが必芁だったため、たたGitLab.comのスパム/高負荷のために。
  2. 2017/01/31 21:00- スパマヌによるサむトの負荷の急増 -Twitter | たるみ

    • IPアドレスでナヌザヌをブロックしたす。
    • CDNずしおリポゞトリを䜿甚するためのナヌザヌの削陀。その結果、47,000人のIPナヌザヌが同じアカりントでログむンしたしたデヌタベヌスの負荷が高くなりたす。 情報は、テクニカルサポヌトおよびむンフラストラクチャチヌムに転送されたした。
    • スパムのナヌザヌを削陀するスニペットを䜿甚 -Slack
    • デヌタベヌスの負荷は通垞に戻り、いく぀かのPostgreSQLテヌブルのバキュヌムが手動で開始され、倚数の空の行が削陀されたした。
  3. 2017/01/31 22:00- レプリケヌションラグに関する譊告を受け取りたした -Slack

    • db2の修正を詊みたすが、この段階では4 GB遅れおいたす。
    • db2.clusterは耇補を拒吊し、ディレクトリ/ var / opt / gitlab / postgresql / dataはクリヌンな耇補を確保するためにクリヌンアップされたす。
    • db2.clusterはdb1ぞの接続を拒吊し、max_wal_sendersが䜎すぎるず誓いたす。 この蚭定は、WALレプリケヌションクラむアントの数を制限するために䜿甚されたす。
    • YPはdb1によっおmax_wal_sendersを32にむンクリメントし、PostgreSQLを再起動したす。
    • PostgreSQLは、開いおいるセマフォが倚すぎお起動しないこずを誓いたす。
    • YPはmax_connectionsを8000から2000に削枛し、PostgreSQLが起動したす8000でほが1幎間正垞に動䜜したずいう事実にもかかわらず。
    • db2.clusterはただ耇補を拒吊したすが、接続に぀いお䞍平を蚀うこずはなくなり、代わりにハングし、䜕もしたせん。
    • この時点で、YPは絶望感を抱き始めたす。 その日前に、圌は遅すぎたので珟地時間の23:00頃䜜業を終了するこずを発衚したしたが、予期しない耇補の問題のためにそのたたでした。
  4. 2017/01/31 23:00頃

    • YPは、おそらくpg_basebackupがデヌタディレクトリのクリヌンさに぀いおあたりにもtoo慢すぎるず考え、それを削陀するこずにしたした。 数秒埌、圌はdb2.cluster.gitlab.comではなくdb1.cluster.gitlab.comでコマンドを実行したこずに気付きたした 。
    • 2017/01/31 23:27YPは削陀をキャンセルしたすが、手遅れです。 箄310 GBのうち、残っおいるのは4.5- Slackだけです。


埩旧-2017/01/31 23:00〜1720 UTCからのバックアップ



  1. 掚奚される埩旧方法

    1. db1.staging.gitlab.comをGitLab.comに移行したす玄6時間のバックログ。

      • CW同期䞭に削陀されたWebフックに問題がありたす。
    2. LVMスナップショットを埩元したす6時間遅れお。
    3. シドファむルを回埩しようずしおいたすか

      • CW䞍可胜 rm -Rvf SidOK。
      • JEJおそらく手遅れですが、ドラむブをすぐに読み取り専甚モヌドに切り替えるず圹立ちたすか たた、䜜業プロセスで䜿甚されおいるファむル蚘述子を取埗するこずは可胜ですか http://unix.stackexchange.com/a/101247/213510による。
      • YPPostgreSQLはすべおのファむルを垞に開いたたたにしないため、これは機胜したせん。 たた、Azureはデヌタを非垞に迅速に削陀するように芋えたすが、他のレプリカぞのデヌタ転送はそれほど高速ではありたせん。 ぀たり、ディスク自䜓のデヌタは埩元できたせん。
      • SHdb1ステヌゞングサヌバヌでは、別のPostgreSQLプロセスがdb2からの運甚デヌタのストリヌムをgitlab_replicatorディレクトリに泚ぎ蟌むようです。 レプリケヌションラグによるず、db2は2016-01-31 05:53に返枈されたため、gitlab_replicatorが停止したした。 幞いなこずに、ここたでのデヌタは無傷に芋えるため、Webフックを回埩できる堎合がありたす。
  2. 実行されたアクション

    1. 2017/02/01 23:00-00:00db1.staging.gitlab.comからdb1.cluster.gitlab.com本番にデヌタを埩元するこずが決定されたした。 6時間遅れおおり、Webフックは含たれおいたせんが、これが利甚可胜な唯䞀のスナップショットです。 YPは、 sudoで始たるコマンドを実行しないほうが良いず蚀い、JNに制埡を移したす。
    2. 2017/02/01 00:36-JNデヌタdb1.staging.gitlab.comをバックアップしたす。
    3. 2017/02/01 00:55-JNdb1.cluster.gitlab.comにdb1.staging.gitlab.comをマりントしたす。

      • ステヌゞング / var / opt / gitlab / postgresql / data /から本番 / var / opt / gitlab / postgresql / data /にデヌタをコピヌしたす。
    4. 2017/02/01 01:05-JNnfs-share01サヌバヌは、/ var / opt / gitlab / db-meltdownの䞀時ストレヌゞずしお割り圓おられたす。
    5. 2017/02/01 01:18-JN圧瞮されたpg_xlog '20170131-db-meltodwn-backup.tar.gz'を含む残りの本番デヌタをコピヌしたす。
    6. 2017/02/01 01:58-JNステヌゞから本番ぞの同期を開始しおいたす。
    7. 2017/02/01 02:00-CW状況を説明するために展開ペヌゞが曎新されたした。 リンク
    8. 2017/02/01 03:00-ARrsyncは玄50完了しおいたすファむルの数。
    9. 017/02/01 04:00-JNrsyncは玄56.4を実行したしたファむル数に関しお。 デヌタ転送は、us-eastずus-east-2間のネットワヌク垯域幅、およびステヌゞングサヌバヌのディスクパフォ​​ヌマンスの制限60 Mb / sの理由で䜎速です。
    10. 2017/02/01 07:00-JN/ var / opt / gitlab_replicator / postgresqlでdb1ステヌゞングの未凊理デヌタのコピヌを芋぀けたした。 us-eastでdb-crutch VM仮想マシンを起動しお、このデヌタを別のマシンにバックアップしたした。 残念ながら、120 GBのRAMに制限されおおり、ワヌクロヌドは匕き出されたせん。 このコピヌは、デヌタベヌスのステヌタスを確認し、Webフックデヌタをアップロヌドするために䜿甚されたす。
    11. 2017/02/01 08:07-JNデヌタ送信が遅いデヌタ量の42が送信されたす。
    12. 2017/02/02 16:28-JNデヌタ転送が終了したした。
    13. 2017/02/02 16:45-以䞋は埩旧手順です。
  3. 回埩手順

    1. [x]-16:36 UTCに撮圱されたDB1サヌバヌのスナップショットたたは2たたは3を取埗したす。
    2. [x]-db1.cluster.gitlab.comをPostgreSQL 9.6.1に曎新したす。これには9.6.0が含たれおおり、ステヌゞングは​​9.6.1を䜿甚したすそうしないず、PostgreSQLが起動しない堎合がありたす。

      • 8.16.3-EEをむンストヌルしたす.1。
      • chef-noopをchef-clientに移動したす手動で無効にされたした。
      • ホストでchef-clientを実行したす16:45に実行。
    3. [x]-DBの実行-16:53 UTC

      • 起動を監芖し、すべおがうたくいったこずを確認したす。
      • バックアップを䜜成したす。
    4. [x]-゚ラヌがステヌゞングに入らないように、Sentry DSNを曎新したす。
    5. [x]-すべおのテヌブルの識別子を10k増やしお、新しいプロゞェクト/コメントを䜜成する際の問題を回避したす。 https://gist.github.com/anonymous/23e3c0d41e2beac018c4099d45ec88f5を䜿甚しお、すべおのシヌケンス1行に1぀を含むテキストファむルを読み取りたす。
    6. [x]-Rails / Redisキャッシュをクリアしたす。
    7. [x]-可胜な限りWebフックを埩元しおください。

      • [x] Webフックを削陀する前に取埗したスナップショットを䜿甚しおステヌゞングを実行したす。
      • [x] Webフックが所定の䜍眮にあるこずを確認しおください。
      • [x]「web_hooks」テヌブルのSQLダンプデヌタのみを䜜成したすデヌタがある堎合。
      • [x] SQLダンプを運甚サヌバヌにコピヌしたす。
      • [x] SQLダンプを䜜業デヌタベヌスにむンポヌトしたす。
    8. [x]-ワヌカヌが接続できるかどうかをRailsコン゜ヌルで確認したす。
    9. [x]-ワヌクフロヌを埐々に開始したす。
    10. [x]-展開ペヌゞを無効にしたす。
    11. [x]-@gitlabstatusでフラッシュしたす。
    12. [x]-さらなる蚈画/アクションを蚘述するクラッシュ関連タスクを䜜成したす
      非衚瀺のテキスト


      []-名前空間が既存のナヌザヌ/グルヌプに察応する堎合、Project゚ントリがないProject Gitリポゞトリの新しい゚ントリを䜜成したす。

      • PC- これらのリポゞトリのリストを䜜成しお、デヌタベヌスが存圚するかどうかを確認できるようにしたす 。


      []-䞍明な倱われた名前空間を持぀リポゞトリを削陀したす。

      • AR-前のポむントからのデヌタに基づいたスクリプトの䜜成。


      [x]-スパムナヌザヌを再床削陀したす再床問題が発生しないようにしたす。

      • [x] 47,000個のIPアドレスを持぀CDNナヌザヌ。


    13. デヌタ埩旧埌に䜜成

      1. PS1圢匏/色の端末を倉曎するタスクを䜜成しお、䜿甚されおいる環境がすぐにわかるようにしたす実動たたはステヌゞング実動は赀、ステヌゞングは​​黄色。 デフォルトでは、すべおのナヌザヌに察しお、bashプロンプトで完党修食ホスト名たずえば、「db1」ではなく「db1.staging.gitlab.com」を衚瀺したす https ://gitlab.com/gitlab-com/infrastructure/issues/1094
      2. デヌタPostgreSQLディレクトリのrm -rfを無効にする方法は これが実行可胜か必芁かはわかりたせん通垞のバックアップがある堎合。
      3. バックアップのアラヌトを远加S3ストレヌゞなどを確認したす。バックアップサむズの倉化を瀺すグラフを远加し、サむズが10以䞊枛少したずきに譊告を衚瀺したす  https : //gitlab.com/gitlab-com/infrastructure/issues/1095 。
      4. 管理者がこの情報を簡単に確認できるように、最埌に成功したバックアップの時刻をデヌタベヌスに远加するこずを怜蚎しおください。  https://gitlab.zendesk.com/agent/tickets/58274でクラむアントが提案。
      5. 2016-05-13から機胜しおいるずいう事実にもかかわらず、PostgreSQLが8000に蚭定されたmax_connectionsで突然問題を匕き起こした理由を理解したす。 この問題の予想倖の出珟は、絶望ず絶望感の䞻な原因です https ://gitlab.com/gitlab-com/infrastructure/issues/1096
      6. WAL / PITRアヌカむブによるレプリケヌションのしきい倀の増加を確認するこずも、曎新が倱敗した埌に圹立ちたす https : //gitlab.com/gitlab-com/infrastructure/issues/1097
      7. サヌビスの起動埌に発生する可胜性のある問題を解決するためのナヌザヌ向けのガむドを䜜成したす。
      8. AzCopyを䜿甚しお、あるデヌタセンタヌから別のデヌタセンタヌにデヌタを移動する実隓Microsoftは、これはrsyncよりも高速に実行する必芁があるず述べおいたす。

        • これはWindows固有のものであるようであり、Windowsの専門家たたはリモヌトで、ただしこの質問を十分に理解しおいる、これを正しくテストできる人はいたせん。


    問題点



    1. デフォルトでは、LVMスナップショットは24時間に1回のみ取埗されたす。 幞いなこずに、YPはクラッシュの6時間前に手動で䜜成したした。
    2. 定期的なバックアップも1日に1回しか行われおいないようですが、YPはただそれらの保存堎所を把握しおいたせん。 JNによるず、それらは機胜したせん。サむズが数バむトのファむルが䜜成されたす。

      • SH9.6ではなくPostgreSQL 9.2のバむナリが実行されるため、pg_dumpは正しく機胜しないようです。 これは、デヌタ/ PG_VERSIONが9.6に蚭定されおいるが、このファむルが䜜業ノヌド䞊にない堎合、オムニバスはPg 9.6のみを䜿甚するためです。 その結果、9.2はデフォルトで起動し、䜕もせずに静かに終了したす。 その結果、SQLダンプは䜜成されたせん。 Fog-gemは叀いバックアップをクリアした可胜性がありたす。
    3. Azureのディスクスナップショットは、NFSサヌバヌ甚、デヌタベヌスサヌバヌ甚に含たれおいたす-いいえ。
    4. 同期プロセスは、ステヌゞングでデヌタを同期した埌、Webフックを削陀したす。 24時間以内に䜜成された通垞のバックアップからそれらを匕き出すこずができない堎合、それらは倱われたす。
    5. レプリケヌション手順は非垞に壊れやすく、ランダムなシェルスクリプトに䟝存する゚ラヌが発生しやすく、文曞化が䞍十分であるこずが刀明したした。

      • SH埌で、gitlab_replicatorディレクトリのスナップショットを䜜成し、レプリケヌション構成を削陀し、別のPostgreSQLサヌバヌを起動するこずで、ステヌゞングデヌタベヌスの曎新が機胜するこずがわかりたした。
    6. S3バックアップも機胜したせん。フォルダヌは空です。
    7. バックアップの䜜成に倱敗した堎合の信頌できる通知システムはありたせんが、dev-hostで同じ問題が発生するようになりたした。


    蚀い換えるず、䜿甚されおいる5぀のバックアップ/レプリケヌション方法のうち、機胜するものはありたせん。 =>珟圚、6時間前に䜜成された䜜業甚バックアップを埩元しおいたす。









    http://monitor.gitlab.net/dashboard/db/postgres-stats?panelId=10&fullscreen&from=now-24h&to=now







    からの助け



    Hugopsここに、twitterたたは他の人が芪切に反応した堎所からの投皿を远加したす


    スティヌブン・フロスト



    • https://twitter.com/net_snow/status/826622954964393984 @gitlabstatusこんにちは、私はPG開発者であり、あなたの仕事が奜きです。 䜕かお手䌝いできたら教えおください。圹に立おおうれしいです。


    サム・マクロヌド



    • こんにちはSid、/ LVMデヌタベヌスに問題があるのは残念ですが、これは非垞に䞍快です。 いく぀かのPostgreSQLクラスタヌマスタヌ/スレヌブがあり、レポヌトでいく぀かのこずに気付きたした。

      1. Slonyを䜿甚したすが、これはあなた自身が知っおいるものであり、これは誇匵ではありたせん。http //howfuckedismydatabase.comでも笑っおいたすが、ストリヌミングレプリケヌションを担圓する組み蟌みのPostgreSQLバむナリは非垞に信頌性が高く高速です。それに切り替えたす。
      2. 接続プヌルの䜿甚に぀いおは蚀及されおいたせんが、postgresql.confでの数千の接続に぀いお述べおいたす。パフォヌマンスの点で非垞に悪く、非効率的です。 実際には、256を超えるアクティブな接続がある堎合、垂盎方向ではなく氎平方向にスケヌリングする必芁がありたす。
      3. レポヌトには、フェむルオヌバヌおよびバックアッププロセスの信頌性が䜎いこずが蚘茉されおいるため、postgresqlフェむルオヌバヌ甚の簡単なスクリプトを䜜成および文曞化したした。必芁に応じお、転送したす。 バックアップに関しおは、日䞭の増分バックアップではpgbarmanを䜿甚し、barmanずpg_dumpを䜿甚しお1日2回フルバックアップも行いたす。パフォヌマンスず信頌性の芳点から、バックアップずpostgresqlデヌタのあるディレクトリを異なるディスクに保存するこずが重芁です。
      4. ただAzureにいたすか 内郚DNS、NTP、ルヌティング、およびストレヌゞには倚くの奇劙な問題があるため、できるだけ早くそこから出るこずをお勧めしたす。たた、すべおが内郚にどのように配眮されおいるかに぀いおのいく぀かの恐ろしい話も聞きたした。


    PostgreSQLのセットアップに重点を眮いたSidずSamの長い察応
    • PostgreSQLの蚭定にサポヌトが必芁な堎合はお知らせください。この件に぀いおは十分な経隓がありたす。
    • 倧t マクロヌド別の質問デヌタベヌスはどのくらいのディスク容量を必芁ずしたすか テラバむトですか、それずもギガバむトですか
    • 倧t マクロヌドフェむルオヌバヌ/レプリケヌションスクリプトを投皿したした
    • pgpoolを芋おいるこずもわかりたす-代わりにpgbouncerをお勧めしたす
    • 倧t マクロヌドpgpoolには倚くの問題がありたす。私たちはそれをよくテストし、捚おたした。
    • 倧t McLeodたた、TwitterやGitLabをサポヌトする他の䜕かを䜿っお䜕か公に発蚀できるかどうか、そしおこの問題に取り組む際の透明性に぀いおも教えおください。 私が始めたずき、infoxchangeでSANスプリットブレむンがあり、文字通り私を吐きたした-私はずおも緊匵したした
    • Sid Sijbrandijこんにちは、サム、助けおくれおありがずう。 これを公開ドキュメントにコピヌしお、チヌムの他のメンバヌがこれを実行できるようにしおください。
    • 倧t マクロヌドフェヌルオヌバヌスクリプト
    • Sid Sijbrandijあなたが曞いたものはすべお。
    • もちろん、いずれにせよ、これは公開リポゞトリですが、理想的ではありたせん。これからはほど遠いですが、うたく機胜したす。結果を出さずにホストを垞に混乱させたすが、すべおが異なる堎合がありたす。
    • はい、もちろん、あなたも私の掚奚事項を転送するこずができたす。

    • PostgreSQLを実行しおいるVMずPostgreSQL.confに぀いおの情報を送信できる堎合は、改善方法に関する掚奚事項を提䟛したす。







    • Sid: Slony 9.2 9.6, .

      : , , : PostgreSQL .







    • Rails (25 ). 20 20 - 10 000 , 400 ( Unicorn — ).

      : PostgreSQL- , ; pg_bouncer — . , , pgpool . , , . Pgpool ORM/db-.


    : https://wiki.postgresql.org/wiki/Number_Of_Database_Connections









    : active/active PostgreSQL-, , ?







    : ? ?







    * おそらく、Samからの質問、GitLab.comチヌムの回答、および最終的な掚奚事項が蚘茉されたセクションは、しばらくの間補充され、むンシデント自䜓に盎接関係しなくなりたす。オリゞナルがただ安定しおいないため、ただ翻蚳に含めおいたせん。







    おわりに



    , GitLab , , , . , Twitter Google Docs, , , , .







    , : "Database (removal) specialist" ( [] ), - 1 http://checkyourbackups.work/ , :









    出所







    どのような結論を導き出すこずができたすか







    1. .
    2. ( , Azure).
    3. LVM — , , GitLab.com, .
    4. dev/stage/prod- .
    5. dev/stage/prod- /.
    6. — , .
    7. , .


    関連リンク









More articles:


All Articles