PostgreSQL での災害復旧に遅延レプリケーションを使用した方法

レプリケーションはバックアップではありません。 か否か？ ここでは、遅延レプリケーションを使用してショートカットを誤って削除した場合に回復する方法を説明します。

インフラスペシャリスト GitLab が作業を担当します GitLab.com - 自然界で最大の GitLab インスタンス。 3 万人のユーザーと 7 万近くのプロジェクトを擁する、専用アーキテクチャを備えた最大のオープンソース SaaS サイトの XNUMX つです。 PostgreSQL データベース システムがなければ、GitLab.com インフラストラクチャはうまく機能しません。また、データが失われる可能性がある障害が発生した場合にフォールト トレランスを確保するにはどうすればよいでしょうか。 このような災害が起こる可能性は低いですが、私たちは十分に備えており、さまざまなバックアップおよびレプリケーションのメカニズムを備えています。

レプリケーションはデータベースをバックアップする手段ではありません (下記参照）。 しかしここでは、遅延レプリケーションを使用して誤って削除したデータを迅速に回復する方法を見ていきます。 GitLab.com ユーザー ショートカットを削除しました プロジェクトのために gitlab-ce マージリクエストやタスクとの接続が失われました。

遅延レプリカを使用すると、わずか 1,5 時間でデータを復元できました。 それがどのように起こったかを見てください。

PostgreSQL を使用したポイントインタイムリカバリ

PostgreSQL には、データベースの状態を特定の時点に復元する組み込み関数があります。 いわゆる ポイントインタイムリカバリ (PITR) を使用し、レプリカを最新の状態に保つのと同じメカニズムを使用します。つまり、データベース クラスター全体の信頼できるスナップショット (ベース バックアップ) から始めて、特定の時点までの一連の状態変更を適用します。

この機能をコールド バックアップに使用するために、基本的なデータベース バックアップを定期的に作成し、アーカイブに保存します (GitLab アーカイブは Googleクラウドストレージ）。 また、先行書き込みログ (先行書き込みログ、WAL）。 これらすべてを準備すると、災害復旧のための PITR を実行できます。障害が発生する前に作成されたスナップショットから開始し、障害が発生するまで WAL アーカイブからの変更を適用します。

遅延レプリケーションとは何ですか?

遅延レプリケーションは、WAL からの変更を遅延して適用します。 つまり、トランザクションは XNUMX 時間以内に発生しました Xただし、遅延してレプリカに表示されます d 時間内に X + d.

PostgreSQL には、バックアップ リカバリとストリーミング レプリケーションという 2 つの方法で物理データベース レプリカを設定できます。 アーカイブからの復元、基本的には PITR と同様に動作しますが、継続的に動作します。WAL アーカイブから変更を常に取得し、レプリカに適用します。 あ ストリーミングレプリケーション 上流のデータベース ホストから WAL ストリームを直接取得します。 私たちはアーカイブ リカバリを好みます。アーカイブの方が管理が簡単で、運用クラスターと同等の通常のパフォーマンスが得られます。

アーカイブからの遅延リカバリを設定する方法

回復オプション ファイルに記載されている recovery.conf。 例：

standby_mode = 'on'
restore_command = '/usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-fetch -p 4 "%f" "%p"'
recovery_min_apply_delay = '8h'
recovery_target_timeline = 'latest'

これらのパラメータを使用して、バックアップ リカバリを備えた遅延レプリカを構成しました。 ここで使われているのは ウォーリー WAL セグメントを抽出するには (restore_command) をアーカイブから取得し、変更は XNUMX 時間後に適用されます (recovery_min_apply_delay）。 レプリカは、クラスターのフェイルオーバーなどによるアーカイブ内のタイムラインの変更を監視します (recovery_target_timeline).

С recovery_min_apply_delay 遅延を伴うストリーミング レプリケーションを設定することもできますが、レプリケーション スロットやホット スタンバイ フィードバックなどに関連する落とし穴がいくつかあります。 WAL アーカイブを使用すると、それらを回避できます。

パラメーター recovery_min_apply_delay PostgreSQL 9.3 でのみ登場しました。 以前のバージョンでは、遅延レプリケーションの場合、組み合わせを構成する必要がありました。 リカバリ管理機能 (pg_xlog_replay_pause(), pg_xlog_replay_resume()) または、遅延の間、WAL セグメントをアーカイブに保持します。

PostgreSQL はどのようにしてこれを行うのでしょうか?

PostgreSQL が遅延リカバリをどのように実装するのかを見るのは興味深いです。 を見ようよ recoveryApplyDelay(XlogReaderState)。 から呼び出されます メインリピートループ WAL からのエントリごとに。

static bool
recoveryApplyDelay(XLogReaderState *record)
{
    uint8       xact_info;
    TimestampTz xtime;
    long        secs;
    int         microsecs;

    /* nothing to do if no delay configured */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* no delay is applied on a database not yet consistent */
    if (!reachedConsistency)
        return false;

    /*
     * Is it a COMMIT record?
     *
     * We deliberately choose not to delay aborts since they have no effect on
     * MVCC. We already allow replay of records that don't have a timestamp,
     * so there is already opportunity for issues caused by early conflicts on
     * standbys.
     */
    if (XLogRecGetRmid(record) != RM_XACT_ID)
        return false;

    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;

    if (xact_info != XLOG_XACT_COMMIT &&
        xact_info != XLOG_XACT_COMMIT_PREPARED)
        return false;

    if (!getRecordTimestamp(record, &xtime))
        return false;

    recoveryDelayUntilTime =
        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);

    /*
     * Exit without arming the latch if it's already past time to apply this
     * record
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Shortened:
        // Use WaitLatch until we reached recoveryDelayUntilTime
        // and then
        break;
    }
    return true;
}

要するに、遅延はトランザクションのコミット タイムスタンプに記録された物理時間に基づいているということです (xtime）。 ご覧のとおり、遅延はコミットにのみ適用され、他のエントリには影響しません。すべての変更は直接適用され、コミットは遅延されるため、構成された遅延の後にのみ変更が表示されます。

遅延レプリカを使用してデータを復元する方法

本番環境で XNUMX 時間の遅延があるデータベース クラスターとレプリカがあるとします。 例を使用してデータを回復する方法を見てみましょう 誤ってショートカットを削除してしまう.

その問題について知ったとき、私たちは、 アーカイブの復元は一時停止されました 遅延レプリカの場合:

SELECT pg_xlog_replay_pause();

一時停止すると、レプリカがリクエストを繰り返すリスクはなくなりました。 DELETE。 すべてを理解するのに時間が必要な場合に便利です。

重要なのは、遅延レプリカがリクエストの直前に到達する必要があるということです。 DELETE。 物理的に除去される時刻はほぼわかっていました。 削除しました recovery_min_apply_delay そして追加しました recovery_target_time в recovery.conf。 これは、レプリカが遅延なく適切な瞬間に到達する方法です。

recovery_target_time = '2018-10-12 09:25:00+00'

タイムスタンプを使用する場合は、見逃さないように余分な値を減らす方が良いでしょう。 確かに、減少が大きければ大きいほど、より多くのデータが失われます。 繰り返しますが、リクエストを逃した場合は、 DELETE、すべてが再度削除されるため、最初からやり直す必要があります（または、PITR 用のコールド バックアップを作成することもできます）。

遅延された Postgres インスタンスを再起動すると、指定された時間まで WAL セグメントが繰り返されました。 この段階での進行状況を追跡するには、次のように質問します。

SELECT
  -- current location in WAL
  pg_last_xlog_replay_location(),
  -- current transaction timestamp (state of the replica)
  pg_last_xact_replay_timestamp(),
  -- current physical time
  now(),
  -- the amount of time still to be applied until recovery_target_time has been reached
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

タイムスタンプが変更されなくなったら、リカバリは完了です。 アクションはカスタマイズ可能 recovery_target_action再試行後にインスタンスを閉じる、昇格する、または一時停止します (デフォルトでは一時停止されています)。

データベースは、その残念なリクエストの前の状態に戻りました。 これで、たとえばデータをエクスポートできるようになります。 削除されたラベル データと問題へのすべてのリンク、およびマージ リクエストをエクスポートし、運用データベースに移動しました。 損失が大規模な場合は、レプリカを昇格させてメインとして使用できます。 しかし、回復した時点以降のすべての変更は失われます。

タイムスタンプの代わりに、トランザクション ID を使用することをお勧めします。 たとえば、DDL ステートメント ( DROP TABLE)、を使用して log_statements = 'ddl'。 トランザクション ID があれば、 recovery_target_xid リクエストの前にトランザクションまですべてを実行しました DELETE.

作業に戻るのは非常に簡単です。すべての変更を削除します。 recovery.conf そしてPostgresを再起動します。 レプリカはまもなく再び XNUMX 時間の遅延が発生する予定であり、今後のトラブルに備えています。

回復給付金

コールド バックアップの代わりに遅延レプリカを使用すると、アーカイブからイメージ全体を復元するのに何時間も費やす必要がなくなります。 たとえば、基本的な 2 TB のバックアップ全体を取得するには XNUMX 時間かかります。 そして、（最悪の場合）望ましい状態に回復するには、日次 WAL 全体を適用する必要があります。

遅延レプリカは、次の XNUMX つの点でコールド バックアップよりも優れています。

1. 基本バックアップ全体をアーカイブから削除する必要はありません。
2. WAL セグメントには、繰り返す必要がある XNUMX 時間の固定ウィンドウがあります。

また、WAL から PITR を作成できるかどうかを常にチェックしており、遅延レプリカの遅延を監視することで、WAL アーカイブの破損やその他の問題にすぐに気づきます。

この例では、復元に 50 分かかりました。つまり、速度は 110 時間あたり XNUMX GB の WAL データでした (アーカイブはまだオンでした) AWS S3）。 合計 1,5 時間で問題を解決し、データを復元しました。

結果: 遅延レプリカが役立つ場合とそうでない場合

誤ってデータを失い、設定された遅延時間内にこの問題に気づいた場合は、応急処置として遅延レプリケーションを使用してください。

ただし、レプリケーションはバックアップではないことに注意してください。

バックアップとレプリケーションには異なる目的があります。 コールド バックアップは、誤って作成した場合に役立ちます。 DELETE または DROP TABLE。 コールド ストレージからバックアップを作成し、テーブルまたはデータベース全体の以前の状態を復元します。 しかし同時にリクエストは DROP TABLE は、作業中のクラスター上のすべてのレプリカにほぼ即座に複製されるため、ここでは通常のレプリケーションは役に立ちません。 レプリケーション自体は、個々のサーバーがレンタルされているときにデータベースを利用可能な状態に保ち、負荷を分散します。

遅延レプリカを使用する場合でも、データセンターの障害、隠れた損傷、またはすぐには気付かないその他のイベントが発生した場合、安全な場所にコールド バックアップが必要になる場合があります。 ここではレプリケーションだけでは役に立ちません。

注意。 上の GitLab.com 現在、システム レベルでのデータ損失に対する保護のみを行っており、ユーザー レベルでのデータの回復は行っていません。

出所： habr.com