データベースに保存されている情報を複製することは、データを配布し、問題が発生した場合に備えて災害復旧に使用できるバックアップを確保するために不可欠です。
PostgreSQLレプリケーションには2つの形式があり、どちらにもニッチな用途があります。これらのデータ複製方法の一方または両方を適用する方法を理解すると、データ配布プロセスを合理化できます。最後に必要なのは、データベースで行った重要な作業を失うことです。
PostgreSQLでのストリーミングレプリケーションと論理の長所、短所、ユースケースを見てみましょう。
PostgreSQLでのデータレプリケーションの定義
データレプリケーションとは何かをすでに理解している場合は、先に進んで次のセクションにスクロールダウンできます。ただし、データベースエンジニアリングを初めて使用する場合は、基盤をすばやく設定したいと考えています。
名前が示すように、レプリケーションは、コンピューターサーバー内のあるデータベースから別のサーバー内の別のデータベースにデータを頻繁にコピーするプロセスであるため、すべてのユーザーが同じレベルの情報にアクセスできます。コンピューティングでは、複製を使用してデジタルシステムの障害を排除します。
レプリケーションにより、データサイロが排除され、貴重な情報が保護され、開発が合理化されます。
PostgreSQLでは、レプリケーションには論理レプリケーションとストリーミングレプリケーションの2つのオプションがあります。これらの方法はさまざまなユースケースに最適であり、開発者としては、どちらか一方を使用する傾向が強い場合があります。ただし、両方の使用方法を理解して、さまざまなシナリオでどちらを適用するかを決定できるようにすることをお勧めします。
PostgreSQLでの論理レプリケーション
PostgreSQLv10.0で使用するためにストリーミングレプリケーションが導入されました。論理レプリケーションは、データオブジェクトとその変更をレプリケーションIDに基づいてコピー/レプリケートすることで機能します。
多くの場合、データのIDが主キーです。 PostgreSQLでは、複製されたデータと情報セキュリティをきめ細かく制御できます。
論理という用語は、バイトごとのレプリケーションと正確なブロックアドレスを使用する物理レプリケーションと区別するために使用されます。詳細については、PostgreSQLの公式ドキュメントをご覧ください。
パブリッシュおよびサブスクライブモデルを介して、1つ以上のサブスクライバーがパブリッシャーノード上の1つ以上のパブリケーションをサブスクライブできるようにすることで機能します。サブスクライバーは、パブリケーションから情報を取得し、カスケードレプリケーションまたはより複雑な構成のためにデータを再パブリッシングできます。
論理データレプリケーションは、トランザクションレプリケーションの形式をとることもできます。エンジニアがテーブルをコピーする場合は、このレプリケーション方法を使用して、パブリッシャー側のデータのスナップショットを取得し、サブスクライバーのデータベースに送信できます。
サブスクライバーが元のデータに変更を加えると、パブリッシャーデータベースはリアルタイムで更新を受信します。単一のサブスクリプションを持つパブリケーションでトランザクションの一貫性を確保するには、サブスクライバーはパブリッシャーと同じ順序でデータを適用する必要があります。
PostgreSQLの論理レプリケーションの長所
論理レプリケーションにより、ユーザーは書き込みに宛先サーバーを使用でき、開発者はさまざまなインデックスとセキュリティ定義を使用できます。これにより、パブリッシャーとサブスクライバー間のデータ転送の柔軟性が向上します。
クロスバージョンのサポート
さらに、クロスバージョンのサポートが付属しており、PostgreSQLの異なるバージョン間で設定できます。また、イベントベースのフィルタリングも提供します。パブリケーションには複数のサブスクリプションを含めることができるため、幅広いネットワーク間でデータを簡単に共有できます。
最小サーバー負荷
トリガーベースのソリューションと比較すると、サーバーの負荷が最小限に抑えられ、小さなセットを複製することでストレージの柔軟性が提供されます。上記のように、論理データレプリケーションでは、基本的なパーティションテーブルに含まれるデータをコピーすることもできます。
また、論理データレプリケーションにより、セットアップ中であってもデータ変換が可能になり、パブリッシャー間での並列ストリーミングが可能になることにも言及する必要があります。
PostgreSQLの論理レプリケーションの短所
論理レプリケーションは、シーケンス、ラージオブジェクト、マテリアライズドビュー、パーティションルートテーブル、および外部テーブルをコピーしません。
PostgreSQLでは、論理データレプリケーションはDML操作でのみサポートされます。開発者はDDLを使用したり、切り捨てたりすることはできません。スキーマは事前に定義する必要があります。さらに、相互(双方向)レプリケーションをサポートしていません。
ユーザーがテーブル内のレプリケートされたデータの制約と競合する場合、レプリケーションは停止します。レプリケーションを再開する唯一の方法は、競合の原因が解決された場合です。
意図しない対立はチームの勢いを止める可能性があるため、問題を迅速に解決する方法を理解する必要があります。
競合がすぐに処理されない場合、レプリケーションスロットは現在の状態でフリーズし、パブリッシャーノードは先行書き込みログ(WAL)の蓄積を開始し、ノードは最終的にディスクスペースを使い果たします。
PostgreSQLでの論理レプリケーションのユースケース
多くのエンジニアは、次の目的で論理レプリケーションを使用します。
- 単一のデータベースまたはデータベースサブセット内の変更をサブスクライバーにリアルタイムで配布する
- 複数のデータベースを1つの中央データベースにマージする(多くの場合、分析用)
- PostgreSQLのさまざまなバージョン間でのレプリケーションの作成
- LinuxからWindowsなどの異なるプラットフォーム間でPostgreSQLインスタンス間でレプリケーションを展開する
- 複製されたデータを他のユーザーまたはグループと共有する
- 複数のデータベース間でデータベースサブセットを配布する
PostgreSQLでのレプリケーションのストリーミング
PostgreSQL9.0で使用するためにストリーミングレプリケーションが導入されました。このプロセスは、ログ先行書き込み(WAL)ファイルをマスターまたはプライマリデータベースサーバーからレプリカまたは受信データベースに送信および適用します。 WALは、レプリケーションとデータの整合性を確保するために使用されます。
ストリーミングレプリケーションの仕組み
ストリーミングレプリケーションは、WALがデータを出荷する最大容量に達するまで待機するファイルベースのログ配布に固有のデータ転送間のギャップを埋めるために機能します。
WALレコードをストリーミングすることにより、データベースサーバーはWALレコードをチャンクでストリーミングしてデータを同期します。スタンバイサーバーはレプリカに接続し、WALチャンクが送信されるときにそれらを受信します。
ストリーミングレプリケーションでは、ユーザーは非同期レプリケーションと同期レプリケーションのどちらを設定するかを決定する必要があります。ストリーミングレプリケーションが最初にデプロイされると、デフォルトで非同期レプリケーションになります。
これは、プライマリでの最初の変更とレプリカでのその変更の反映の間に遅延があることを示しています。変更がコピーされる前にマスターがクラッシュした場合、またはレプリカが元のレプリカと同期していないために関連データを破棄して変更を加えた場合、非同期化によってデータが失われる可能性があります。
同期レプリケーションは、リアルタイムで変更を行うため、はるかに安全なオプションです。マスターからレプリカへの転送は、両方のサーバーが情報を確認するまで不完全であると見なされます。データの変更が確認されると、転送は両方のサーバーのWALに記録されます。
非同期レプリケーションと同期レプリケーションのどちらを使用する場合でも、レプリカはネットワーク接続を介してマスターに接続する必要があります。さらに、情報が危険にさらされないように、ユーザーがレプリカのWALストリームへのアクセス権限を設定することが不可欠です。
PostgreSQLでのストリーミングレプリケーションの長所
ストリーミングレプリケーションを使用することの最も重要な利点の1つは、データを失う唯一の方法は、プライマリサーバーと受信サーバーの両方が同時にクラッシュした場合であるということです。重要な情報を渡す場合は、レプリケーションをストリーミングして、作業のコピーが保存されることを保証します。
ユーザーは複数のスタンバイサーバーをプライマリに接続でき、ログはプライマリから接続された各スタンバイにストリーミングされます。レプリカの1つが遅延したり切断されたりした場合、ストリーミングは他のレプリカに続行されます。
ストリーミングレプリケーションを介してログ配布を設定しても、ユーザーがプライマリデータベースで現在実行しているものに干渉することはありません。プライマリデータサーバーをシャットダウンする必要がある場合は、更新されたレコードがレプリカに送信されるまで待機してから、電源を切ります。
PostgreSQLでのストリーミングレプリケーションの短所
ストリーミングレプリケーションは、情報を別のバージョンやアーキテクチャにコピーしたり、スタンバイサーバーの情報を変更したりすることはなく、きめ細かいレプリケーションを提供しません。
特に非同期ストリーミングデータレプリケーションでは、レプリカにまだコピーされていない古いWALファイルは、ユーザーがマスターに変更を加えたときにリサイクルされる可能性があります。重要なファイルが失われないようにするために、ユーザーはwal_keep_segmentsをより高い値に設定できます。
レプリカサーバーにユーザー認証クレデンシャルを設定しないと、機密データを簡単に抽出できます。マスターとレプリカの間でリアルタイムの更新を行うには、ユーザーはレプリケーション方法をデフォルトの非同期レプリケーションから同期レプリケーションに変更する必要があります。
PostgreSQLでのストリーミングレプリケーションのユースケース
多くのエンジニアは、次の目的でストリーミングレプリケーションを使用します。
- サーバー障害やデータ損失が発生した場合に備えて、プライマリデータベースのバックアップを作成する
- レプリケーションの遅延を最小限に抑えた高可用性ソリューションの育成
- プライマリシステムへのストレスの一部を軽減するために大きなクエリを排出する
- データベースワークロードを複数のマシンに分散する、特に読み取り専用フォーマットの場合
将来に向けて何が待ち受けていますか?
PostgreSQL Global Development Groupは、2021年9月30日にPostgreSQL 14のリリースを発表しました。新しいバージョンには、プラットフォームを介したストリーミングと論理レプリケーションの両方のアップグレードがロードされました。
ストリーミングレプリケーションの場合、バージョン14ではユーザーは次のことができます。
- サーバーパラメータを設定します
log_recovery_conflict_waits
長いリカバリ競合待機時間を自動的に報告するには - プライマリサーバーのパラメータを変更するときは(スタンバイをすぐにシャットダウンするのではなく)、ホットスタンバイサーバーでリカバリを一時停止します
- 関数
pg_get_wal_replay_pause_state()
を使用します 回復状態をより詳細に報告する - 読み取り専用サーバーパラメータ
in_hot_standby
を提供します - 多数の共有バッファがあるクラスタでのリカバリ中に、小さなテーブルをすばやく切り捨てます
- Linuxを介したクラッシュリカバリの開始時にファイルシステムの同期を許可する
- 関数
pg_xact_commit_timestamp_origin()
を使用します 指定されたトランザクションで、コミットタイムスタンプとレプリケーションオリジンを返します - 関数
pg_last_committed_xact()
を使用します 返されたレコードに複製起点を追加するには - レプリケーション起点関数を変更するために標準の関数許可コントロールを使用します(デフォルトではスーパーユーザーへのアクセスが制限されます)
論理レプリケーションの場合、バージョン14ではユーザーは次のことができます。
- 論理レプリケーションAPIを使用して、進行中の長いトランザクションをサブスクライバーにストリーミングします
- テーブルの複製中に複数のトランザクションを許可する
- 即時WALログサブトランザクションとトップレベルのXIDアソシエーションを生成します
- 関数
pg_create_logical_replication_slot()
を使用します 2フェーズコミットの論理デコードAPIを強化するため - コマンド完了時にキャッシュ無効化メッセージをWALに追加して、進行中のトランザクションの論理ストリーミングを可能にします
- レプリケーションストリームに送信される論理デコードメッセージを制御します
- より迅速な複製のためにバイナリ転送モードを使用する
- XIDによるフィルターデコード
PostgreSQLはすでにバージョン15に向けて取り組んでおり、2022年の第3四半期にリリースされる予定です。最新バージョンで対処されるレプリケーションに関する問題の1つは、ストリーミングレプリケーションでサーバー環境から継承された変数を使用できないことです。しかし、より多くのユーザーがバージョン14に適応するにつれて、PostgreSQLはレプリケーション機能を改善するためのタスクを追加する可能性があります。
PostgreSQLレプリケーションの簡単な比較:論理レプリケーションとストリーミングレプリケーション
論理レプリケーション | ストリーミングレプリケーション | |
---|---|---|
モデル | パブリッシャーからサブスクライバーへ | マスターからレプリカへ |
トランザクションレプリケーション | はい | いいえ |
レプリケーションのギャップ | 競合するとレプリケーションが停止します | 非同期–プライマリとレプリカ間のデータ転送の間に遅延が発生する可能性があります。同期–接続されているすべてのサーバーが同時にクラッシュした場合にのみデータが失われます |
さまざまなプラットフォームまたはPostgreSQLバージョン間でのレプリケーション | はい | いいえ |
セキュリティ | データアクセスはサブスクライバーに制限されています | データを安全に保つためにアクセス資格情報を設定する必要があります |
レプリケーションのサイズ | きめ細かい複製に適しています | 大規模な複製に適しています |
特に便利 | 複数のシステムを1つのデータベースに統合する | バックアップデータベースの作成 |
結論
このガイドが、レプリケーション機能を設定する際に役立つことを願っています。 ScaleGridがPostgreSQLの展開にどのように役立つかについて質問がある場合、または他に知りたいことがある場合は、多くのデータベースエキスパートの1人に連絡してください。
|