sql >> データベース >  >> RDS >> PostgreSQL

ストリームレプリケーションと論理レプリケーションの違い

    TL; DR ：論理レプリケーションは行ごとの変更を送信し、物理レプリケーションはディスクブロックの変更を送信します。一部のタスクには論理レプリケーションが適していますが、他のタスクには物理レプリケーションが適しています。

    PostgreSQL 12（更新時現在）では、論理レプリケーションは安定していて信頼性がありますが、かなり制限されていることに注意してください。この質問をする場合は、物理レプリケーションを使用してください。

    ストリーミングレプリケーションは可能 論理レプリケーション。それはすべて少し複雑です。

    WAL-出荷とストリーミング

    PostgreSQLでマスターからレプリカにデータを送信する主な方法は2つあります。

    • WAL-配送 または継続的なアーカイブ 、個々の先行書き込みログファイルがpg_xlogからコピーされます。 archive_commandによって マスター上で他の場所に実行されています。 restore_command レプリカのrecovery.confで構成されます レプリカで実行してアーカイブをフェッチし、レプリカがWALを再生できるようにします。

      これは、ポイントインタイムレプリケーションに使用されるものです。 （PITR）、これは継続的なバックアップの方法として使用されます。

      マスターサーバーへの直接ネットワーク接続は必要ありません。特にarchive_timeoutがないと、レプリケーションに長い遅延が発生する可能性があります。 設定。 WALシッピングは同期レプリケーションには使用できません。

    • ストリーミングレプリケーション 、各変更は、発生時にTCP/IP接続を介して1つ以上のレプリカサーバーに直接送信されます。レプリカには、マスターがrecovery.confで構成された直接ネットワーク接続が必要です。 のprimary_conninfo オプション。

      レプリカが追いつくのに十分な速さである限り、ストリーミングレプリケーションにはほとんどまたはまったく遅延がありません。 同期レプリケーションに使用できます 。 PITRにストリーミングレプリケーションを使用することはできないため、継続的なバックアップにはあまり使用されません。マスターにテーブルをドロップすると、おっと、レプリカにもドロップされます。

    したがって、2つの方法の目的は異なります。

    非同期ストリーミングと同期ストリーミング

    その上、同期があります および非同期 ストリーミングレプリケーション：

    • 非同期ストリーミングレプリケーション レプリカは、マスターが高速/ビジーのときにマスターに遅れをとることができます。マスターがクラッシュすると、まだ複製されていないデータが失われる可能性があります。

      非同期レプリカがマスターよりも大幅に遅れている場合、max_wal_sizeの場合、マスターはレプリカが必要とする情報を破棄する可能性があります。 （以前はwal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal (was max_wal_sizeの場合、pg_xlog）がいっぱいになり、ディスク領域が解放されるまでマスターの動作が停止する可能性があります。 高すぎるか、スロットが使用されています。

    • 同期レプリケーション レプリカがトランザクションの受信を確認するまで、マスターはコミットを終了しません。マスターがクラッシュしてもデータが失われることはなく、レプリカにフェイルオーバーする必要があります。マスターは、レプリカが必要とするデータを破棄したり、xlogをいっぱいにして、レプリカの遅延のためにディスク領域を使い果たしたりすることはありません。代わりに、レプリカに問題がある場合、マスターの速度が低下したり、動作を停止したりする可能性があり、ネットワーク遅延のためにマスターのパフォーマンスに常にある程度の影響があります。

      複数のレプリカがある場合、一度に同期できるのは1つだけです。 synchronous_standby_namesを参照してください 。

    同期ログ配布を行うことはできません。

    実際には、ログ配布と非同期レプリケーションを組み合わせて、マスターに影響を与えるリスクを冒すことなく、レプリカが大幅に遅れた場合にレプリカを再作成する必要がないように保護できます。これは、レプリカがマスターの背後にある距離を監視して、許容可能なディザスタリカバリの制限内にあることを確認することと組み合わせて、多くの展開にとって理想的な構成です。

    論理的vs物理的

    その上に 論理があります vs物理的 PostgreSQL 9.4で導入されたストリーミングレプリケーション：

    • 物理ストリーミングレプリケーション 変更は、「リレーション12311のディスクページ18のオフセット14で、16進値0x2342beef1222 ....でタプルを書き込んだ」のように、ほぼディスクブロックレベルで送信されます。

      物理レプリケーションはすべてを送信します ：PostgreSQLインストール内のすべてのデータベースの内容、すべてのデータベース内のすべてのテーブル。インデックスエントリを送信し、VACUUM FULLすると、まったく新しいテーブルデータを送信します。 、ロールバックしたトランザクションなどのデータを送信します。そのため、大量の「ノイズ」が発生し、大量の超過データが送信されます。また、レプリカが完全に同一である必要があるため、一時テーブルやログに記録されていないテーブルの作成など、トランザクションを必要とすることはできません。レプリカをクエリするとレプリケーションが遅れるため、レプリカに対する長いクエリをキャンセルする必要があります。

    代わりに、レプリカに変更を適用するのは簡単で効率的であり、レプリカは確実にマスターとまったく同じです。 DDLは、他のすべてと同様に透過的に複製されるため、特別な処理は必要ありません。また、大きなトランザクションが発生したときにストリーミングできるため、大きな変更があった場合でも、マスターでのコミットとレプリカでのコミットの間にほとんど遅延がありません。

    物理レプリケーションは成熟しており、十分にテストされており、広く採用されています。

    • 論理ストリーミングレプリケーション 、9.4の新機能で、変更をより高いレベルで、はるかに選択的に送信します。

    一度に1つのデータベースのみを複製します。行の変更のみを送信し、コミットされたトランザクションに対してのみ送信します。バキュームデータやインデックスの変更などを送信する必要はありません。データベース内の一部のテーブルに対してのみデータを選択的に送信できます。これにより、論理レプリケーションが多く行われます。 帯域幅効率が向上します。

    より高いレベルで動作するということは、レプリカデータベースでトランザクションを実行できることも意味します。一時テーブルとログなしテーブルを作成できます。必要に応じて、通常のテーブルでも。外部データラッパー、ビュー、関数の作成など、好きなものを使用できます。クエリの実行時間が長すぎる場合でも、クエリをキャンセルする必要はありません。

    論理レプリケーションを使用して、PostgreSQLでマルチマスターレプリケーションを構築することもできます。これは、物理レプリケーションでは不可能です。

    ただし、その代わりに、（現在）大きなトランザクションが発生したときにストリーミングすることはできません。彼らがコミットするまで待たなければなりません。そのため、マスターでコミットしてからレプリカに適用されるまでの間に長い遅延が発生する可能性があります。

    トランザクションを厳密にコミット順に再生するため、小さな高速トランザクションが大きなトランザクションの背後でスタックし、かなりの遅延が発生する可能性があります。

    DDLは自動的に処理されません。マスターとレプリカの間でテーブル定義の同期を自分で維持する必要があります。そうでない場合、論理レプリケーションを使用するアプリケーションには、これを行うための独自の機能が必要です。これを正しく行うのは複雑な場合があります。

    適用プロセス自体は、「指示された場所にいくつかのバイトを書き込む」よりも複雑です。また、物理レプリケーションよりもレプリカで多くのリソースを必要とします。

    現在の論理レプリケーションの実装は、成熟していないか、広く採用されていないか、特に使いやすいものではありません。

    オプションが多すぎるので、どうしたらよいか教えてください

    ふぅ。複雑ですねまた、遅延レプリケーション、スロット、max_wal_sizeの詳細についても触れていません。 、タイムライン、プロモーションの仕組み、Postgres-XL、BDR、マルチマスターなど。

    では、何をすべきか ？

    正しい答えは1つではありません。それ以外の場合、PostgreSQLはその一方向のみをサポートします。ただし、一般的な使用例はいくつかあります。

    バックアップと障害復旧の場合 pgbarmanを使用する 基本バックアップを作成し、WALを保持して、継続的なバックアップを簡単に管理できるようにします。定期的にpg_dumpを取得する必要があります 追加保険としてのバックアップ。

    データ損失のリスクがゼロの高可用性の場合 ストリーミング同期レプリケーションを使用します。

    高可用性と低データ損失リスクおよびパフォーマンスの向上 非同期ストリーミングレプリケーションを使用する必要があります。フォールバックに対してWALアーカイブを有効にするか、レプリケーションスロットを使用します。 Icingaなどの外部ツールを使用して、レプリカがマスターの背後にある距離を監視します。

    参考資料




    1. PDOを使用した複数のデータベース

    2. 非同期fnのモジュールエクスポート結果

    3. SQLエラーが発生しました：ORA-01843：有効な月ではありません

    4. DjangoAutoFieldの開始値を変更する