災害復旧の実装

セルゲイ・ブラダマン（アヴィート）

みなさん、こんにちは。私の名前はセルゲイ・バーレディアンです。データベース管理者としてAvitoで働いています。 私はそのようなシステムで働いています：







これは、2 TB、4サーバー-1マスター、3スタンバイの中央ベースです。 また、londisteベースの論理レプリケーション（これはSkytoolsによるもの）、外部スフィンクスインデックス、DWHなどの外部システムへのさまざまなアップロードもあります。 また、xrpcと呼ばれるリモートプロシージャコールの分野でも独自の開発を行っています。 16塩基のストレージ。 もう1つの数字は、バックアップに6時間かかり、その復旧には約12時間かかることです。 これらのシステムのさまざまな事故が発生した場合、私たちのサイトの簡単なサイトは10分以内で完了します。



これらのシステムのさまざまな接続を想像しようとすると、次のようになります。







そして、事故でこれをすべて失わないようにするにはどうすればいいですか？



事故とは何ですか？







私は主にサーバー損失のクラッシュを考慮しますが、ウィザードのプラスはデータ爆発のような事故である可能性もあります。





始めましょう。







一部の管理者がどこでもなく誤って更新したとします。 このようなケースが何度かありました。 それから身を守る方法は？ 私たちは、12時間の遅延でWALを使用するスタンバイがあるという事実で自分を守ります。 このような事故が発生した場合、このデータをスタンバイから取得し、マスターにアップロードしました。







マスターに発生する可能性がある2番目のクラッシュは、サーバーの損失です。 非同期レプリケーションを使用します。サーバーを失った後、スタンバイプロモーションを行う必要があります。 そして以来 非同期複製があるため、接続されたシステムを復元するにはさまざまな手順を実行する必要があります。 私たちのマスターは中心であり、データソースです。したがって、マスターが切り替わり、レプリケーションが非同期である場合、トランザクションの一部が失われ、システムの一部が新しいマスターにとって達成不可能な未来にあることがわかります。







手でやることはすべて難しいので、すぐにスクリプトを実行する必要があります。 事故はどのように見えますか？ 外部システムでは、ウィザードに表示されなくなった広告が表示され、検索時にsphinxが存在しない広告を発行し、シーケンスが元に戻り、特にこのため論理レプリカも機能しなくなりました（londiste）。







しかし、すべてがそれほど悪いわけではなく、すべて復元することができます。 私たちは座って考え、回復手順を計画しました。 特に、DWHを再度アンロードできます。 そして直接、なぜなら 簡単な10分の時間があれば、月次レポートでは、これらの失われたアイテムの変更は単に表示されません。



xrpcを復元する方法は？ ジオコーディング、ウィザードでの非同期プロシージャの呼び出し、およびユーザーカルマの計算に使用されるxrpcがあります。 したがって、何かをzeokodiliする場合、つまり 彼らはそれを住所から地図上の座標に変換し、その後この住所は消えました。ジオコーディングされたままです。同じ住所をジオコーディングしないのは2回目なので、何も復元する必要はありません。 ローカルプロシージャコールは非同期です。 それはローカルであり、1つのデータベース上、さらには1つのデータベース上にあるため、データベースを切り替えたときに一貫性があります。 また、何も復元する必要はありません。 ユーザーのカルマ。 ユーザーが何か悪いことをした後、事故が発生し、これらの悪いアイテムを紛失した場合、ユーザーのカルマも復元できないと判断しました。 彼はこれらの悪いことをしました。







Sphinxサイト。 2つのスフィンクスがあります-1つはサイト用、もう1つはバックオフィス用です。 サイトであるSphinxは、10分ごとにインデックス全体を完全に再構築するように実装されています。 したがって、事故が発生して回復し、10分後にインデックスが完全に再構築され、マスターに対応しました。 バックオフィスについても、重要ではないと判断しました。復旧後に変更された広告の一部を埋めることができ、さらに月に一度バックオフィススフィンクス全体を完全に再構築すると、これらの緊急アイテムはすべて削除されます。



シーケンスが後方にジャンプしないように復元する方法は？ item_id、user_id、支払い主キーなど、私たちにとって重要なシーケンスを選択しました。そして、事故の後、それらを10万個前にスクロールしました（十分であると判断しました）。



システムを使用して論理複製を復元します。これは、論理レプリカのUNDOを作成するlondisteのパッチです。







パッチを元に戻す-これらは3つのチームです。 コマンド自体と、論理レプリカ用の2つの元に戻す追加/削除コマンド。 また、londisteでリプレイし、マスターからPostgresセッション変数にTICK_IDを渡すようにフラグを追加しました。







これは、Undoの実装で直接必要です。 実装されています-すべてのサブスクライバーテーブルでトリガーされるだけです。 トリガーは、どの操作が直接発生したかを履歴プレートに書き込みます。 ターゲット表。 これはtick_idをマスターに渡し、このエントリーで記憶しています。 したがって、事故が発生したとき、論理レプリカは将来のものであり、到達不可能な未来からの変更を復元するためにクリーンアップする必要があります。 これは、逆クエリを実行することによって行われます。 挿入の場合は削除を行い、更新の場合は以前の値で更新し、削除の場合は挿入します。







手でこのすべてを行うのではなく、スクリプトで行います。 このスクリプトの特徴は何ですか？ それぞれ3つの非同期スタンバイがあり、切り替える前に、マスターに最も近いものを見つける必要があります。 次に、このスタンバイを選択し、アーカイブから残りのWALを再生するまで待機し、将来のマスター用に選択します。 次に、Postgres 9.2を使用します。 このバージョンの機能は、スタンバイを新しいプロモーションとマスターに切り替えるために、停止する必要があることです。 理論的には、9.4ではこれはできなくなりました。 したがって、昇格、シーケンスの前方への移動、Undoプロシージャの実行、スタンバイの実行を行います。 そして興味深い点もあります。スタンバイが新しいマスターに接続するまで待つ必要があります。 これを行うには、新しいマスターのタイムラインが適切なスタンバイに表示されるのを待ちます。







そして今、PostgresにはそのようなSQL関数がないことがわかり、スタンバイのタイムラインを理解することは不可能です。 しかし、この方法で解決します。Postgresレプリケーションプロトコル経由でスタンバイに接続でき、最初のコマンドの後、スタンバイは赤で強調表示されたタイムラインを通知します。



これは回復ウィザードのスクリプトです。







さらに進みましょう。 一部の外部システムがバラバラになった場合、どうすれば直接回復できますか。 たとえば、スタンバイ。 なぜなら 先ほど言ったように、スタンバイが3つあり、そのうちの1つが落ちたら残りのスタンバイに切り替えます。 最後の手段として、すべてのスタンバイを失っても、マスターにトラフィックを切り替えることができます。 一部のトラフィックはここで失われますが、原則として、サイトは機能します。 まだこのようなトリックがありました-最初は常にバックアップから新しいスタンバイを作成し、その後SSD'shnyサーバーを取得しましたが、バックアップからスタンバイを復元し続けました。 その後、バックアップから取得した場合、リカバリには12時間かかり、ワーキングスタンバイからpg_basebackupを取得しただけであれば、はるかに短い時間がかかることが判明しました。 スタンバイが複数ある場合は、確認してみることができます。







スフィンクスのサイトが壊れた場合。 サイトスフィンクスは、インデックス全体を完全に再構築するように作成されており、サイトスフィンクスはすべてアクティブなサイト広告です。 現在、サイト上のすべての3,000万または3,500万の広告は、このシステムによってインデックス付けされています。 インデックス作成は別の論理レプリカから行われます。インデックス作成のために特別に準備され、すべてがメモリ内に配置されるように作成されます。インデックス作成は非常に迅速に行われるため、10分ごとに完全にゼロからインデックス作成を行うことができます。 論理レプリカがいくつかあります。 そして、レプリカを失った場合、そのリザーブに切り替えます。 そして、スフィンクスに何かが起こった場合、10分後に完全にインデックスが再作成され、すべてが正常になります。







エクスポートをDWHに復元するにはどうすればよいですか？ 何かをエクスポートし、DWHで事故が発生し、最新のデータの一部が失われたとします。 別の論理レプリカを介してDWHをエクスポートし、過去4日間はこのレプリカに保存されます。 手でエクスポートスクリプトを再呼び出しし、このデータをすべてアップロードできます。 さらに、半年で別のアーカイブがあります。 または、最後の手段として、 いくつかのスタンバイがあり、そのうちの1つを取得して、一般に、DWHのマスターからのすべてのデータを一時停止および再アップロードできます。







Xrpcはpgq（これらはSkytoolsです）の上に実装されており、これのおかげでこのようなトリッキーなことができます。 実際、Pgqはデータベース内の単なるテーブルであり、イベントはそこに格納されます。 写真のように見えます。 イベント時間とトランザクションIDがあります。 xrpcクライアントを復元したら、このキューを取得して戻り、レシーバーにないイベントを再度再生できます。







Xdb-いくつかのデータベースのリポジトリがあります。 16台の基地が8台の車にあります。 このストレージは次のように予約されています-Postgresバイナリレプリケーションは、あるマシンから別のマシンに単純に設定されます。 つまり 最初のマシンは、2番目にスタンバイ、3番目に2番目、1番目に8番目に予約されています。 さらに、WALをプレイする場合、4日間の遅延もあります。つまり、実際には、これらのノードのいずれかを4日間でバックアップします。







次に、レプリカの詳細を説明します。 Postgresの機能に基づいて論理レプリカを作成しました。これはマスターのビューであり、目的のテーブルの遅延トリガーです。 これらのトリガーは、別のラベルに書き込む特別な機能をトリガーします。 実体化された表現と見なすことができます。 さらに、このプレートはロンディストが論理的なカブに複製されることを意味します。







直接、どういうわけかこのように見えますが、これについては詳しく説明しません。







論理レプリカサーバー自体、なぜこれが一般的に必要なのですか？ これは別のサーバーです。 それはすべてがそこにメモリにあるという事実によって特徴付けられます、すなわち shared_buffersは、このプレート全体とそのインデックスが完全に適合するサイズです。 これにより、たとえば、1つのカブが1秒間に7000トランザクションを処理し、1000個のイベントがマスターからマスターにキューイングされるなど、このような論理レプリカの大きな負荷を処理できます。 なぜなら これはlondisteとpgqによって実装された論理レプリカです。この論理レプリカで既に失われているトランザクションを追跡するという便利なことがあります。 このことに基づいて、元に戻すなどの操作を実行できます。







すでに2つのレプリカがあると言いましたが、切り替えるだけで回復できます。 1つのレプリカが失われた場合、2番目のレプリカに切り替えます。 これは、pgqが複数のコンシューマーが1つのキューにサブスクライブすることを許可しているためです。 カブが落ちた後、そのコピーを復元する必要があります。 これを単にlondisteで行う場合、レプリカサイトでは4時間、スフィンクスでは8時間かかります。 スフィンクスへの便利なインデックス作成のためにデータをカットするトリガーがそこで呼び出され、これはすべて非常に長いです。 しかし、落ちたカブを作成する別の方法があることが判明しました-pg_dumpを動作させることができます。







しかし、単にpg_dumpでlondisteを実行すると、londisteは失われたトランザクションの現在の位置のマスターと論理レプリカの両方を監視するため、動作しません。 したがって、まだ追加の手順を実行する必要があります。 tick_idウィザードでダンプを復元した後、復元されたカブのtick_idと一致するように修正する必要があります。 その場合、pg_dumpを介してコピーします。これには15分しかかかりません。







アルゴリズム自体は次のようになります。







バックアップはクラッシュから保護するように設計されていますが、バックアップ自体で直接クラッシュすることもあります。 たとえば、Postgresでは、WALアーカイブコマンドは、WALがアーカイブに書き込まれたときにfsynkが行うべきことを示していません。 しかし、これは重要なことであり、アーカイブの緊急再起動などから身を守ることができます。 さらに、バックアップは外部クラウドにコピーされるという事実によっても確保されています。 しかし、計画では、2つのアクティブなアーカイブサーバーを作成して、archive_commandが両方のWALに書き込むようにします。 また、最初はWALアーカイブサーバー自体で直接受信するためにpg_receivexlogで実験したと言うこともできますが、9.2では使用することはほとんど不可能であることが判明しました。これはfsynkではなく、ウィザードから既に受信したWALを追跡しないためですチェックポイントでクリーニングできます。 Postgresは今やっています。 そして、おそらく将来的にはarchive_commandを使用せず、結局pg_receivexlogを使用します。







自宅ではストリーミングを使用しません。 つまり 私が話していたことは、すべてWALアーカイブのみに基づいています。 これは、ストリーミング時にアーカイブを提供するのが難しいという事実のために行われました。 たとえば、アーカイブをスタンバイから取得した場合、バックアップは完了しますが、ウィザードはまだ、バックアップの復元に必要なこれらのすべてのWALをアーカイブできません。 そして、壊れたバックアップを取得します。 これは、たとえば、バックアップを取得するスタンバイが、私たちのように12時間遅れている場合に回避できます。 または、Postgres 9.5では、このような問題が発生しないようにarchive_mode = alwaysを設定しました。 スタンバイから静かにバックアップを取り、アーカイブのWALをスタンバイから直接受信することも可能です。







バックアップするだけでは十分ではありません。すべてが正しくバックアップされているかどうかを確認する必要があります。 テストサーバーでこれを行い、このために特別なバックアップ検証スクリプトを作成しました。 サーバーを復元し、サーバーログでエラーメッセージを実行した後にチェックする内容に基づいています。 また、クラスターに復元された各データベースに対して、check_backupという特別なチェック関数が呼び出され、追加のチェックが実行されます。 特に、最後のトランザクションの日付が最後のアナウンスの日付と1分以内で異なる必要があるという検証。 つまり ホールがない場合、バックアップは正しく復元されていると考えられます。







スライドでは、バックアップをチェックするときにログで分析する特定のエラーを確認できます。



以前は、データベース全体のバキュームを実行してテーブルを読み取ることでバックアップをチェックしましたが、復元されたバックアップのレポートをカウントし、レポートが正しく計算された場合、穴がなく、奇妙な値があり、バックアップが正しく行われたため、拒否することにしました。







私は非同期複製について話しましたが、時々同期を取りたいと思います。 Avitoは多くのサービスで構成されており、これらのサービスの1つは支払いサービスです。 そして、それが選択されているという事実のために、同期レプリケーションを行うことができます。 別のベースで動作します。 このような大きな負荷はなく、ネットワークの標準的な遅延により、そこで同期レプリケーションを有効にできます。







最後に何が言えますか？ それでも、レプリケーションは同期的であるという事実にもかかわらず、このモードで作業および回復できます。接続されたシステムを見ると、それらを復元する方法を見つけることができます。 バックアップもテストすることが重要です。







別のそのような発言。 回復スクリプトがあります。最後にDNSを変更する必要があります。 マスターまたはスレーブがあります-これはDNSで修正されています。 DNSを自動的に切り替えるために、ZooKeeperなどの何らかのシステムの使用を検討しています。 そのような計画。

このレポートは、高負荷システムHighLoad ++の開発者の会議で行われた最高のスピーチの1つの転写です 。 現在、2016年の会議を積極的に準備しています。今年は11月7日と8日にSkolkovoでHighLoad ++が開催されます。



Avitoチームは従来、非常に強力なパフォーマンスを提供しています。たとえば、今年は次のようになります。

• データセンター間の移行の経験 / Mikhail Tyurin
• メイン検索のSphinx 3.0およびRTインデックスAvito / Andrey Smirnov、Vyacheslav Kryukov;

また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！