まず、論理レプリケーションと物理レプリケーションの基本的な違いをいくつか紹介します。
- 物理レプリケーションでは、複数のインスタンスが同じメジャー バージョンとオペレーティング システム プラットフォームである必要があります。マスター インスタンスが Windows 環境の PostgreSQL15 である場合、スレーブ インスタンスもこの環境とバージョンである必要があります。論理レプリケーションの要件はありません。
- 物理レプリケーションでは、WAL アーカイブ ファイルを直接転送し、インスタンスから実行をリプレイします。これは、リアルタイムの WAL アーカイブ リカバリとして理解できるため、遅延が少なく、パフォーマンスが高くなります。、
- 論理レプリケーションは、単純に WAL アーカイブ ファイル内の情報を解析し、標準 SQL ステートメントに処理し、実行のためにリポジトリに渡すこととして理解できますが、WAL を直接転送する場合と比較すると、パフォーマンスが低下し、遅延が大きくなります。
- 物理レプリケーションでは、論理レプリケーションのようにデータベースやデータ テーブルを手動で作成する必要はありません。物理レプリケーションでは WAL を直接復元するため、DDL 操作が含まれますが、論理レプリケーションでは DDL 操作を独自に実行する必要があります。
- 論理レプリケーションはより柔軟です。コピーするライブラリを指定できます。インスタンスから、他のビジネス用の他のライブラリを作成することもできます。物理レプリケーションはインスタンス全体です。スレーブ インスタンスとマスター インスタンス間の 100% の整合性最大でも読み取り操作のみを実行できます。
Windows システムへの PostgreSQL のインストール方法については、以前のブログ Windows システムへの PostgreSQL 手動インストールと構成方法を直接参照してください。
高いパフォーマンスを追求する場合は、物理レプリケーションを使用する、一貫性の高いデータベース レプリケーション バックアップ ソリューションをお勧めします。
物理レプリケーション モードでマスター/スレーブ サブスクリプションを構築するには、まずマスター インスタンスの postgresql.conf ファイルを調整する必要があり
ます
。
使用する synchronous_commit = Remote_apply モードは同期レプリケーション モードであるため、同期レプリケーションとして理解できます。クライアントはマスター インスタンスと同様にトランザクションをコミットした後、synchronous_standby_names で構成されたすべてのノードが Remote_apply を完了し、マスター インスタンスがスタンバイ データベースにトランザクションの正常な送信のステータスを返す前のデータ。s という名前のサブスクリプションを作成した後、プライマリ インスタンスの postgresql.conf ファイルを再度開き、synchronous_standby_names = 's' を調整して設定します
。
複数のスレーブ インスタンスがマスター インスタンスから同期される場合、synchronous_standby_names は次の構成モードも使用できます。
- synchronous_standby_names='s1' は、 s1 スタンバイ マシンが復帰後に送信できることを意味します。
- synchronous_standby_names='FIRST 2 (s1,s2,s3)' は、 3 つのスタンバイ マシン s1、s2、および s3 の最初の 2 つの s1 と s2 が、メイン インスタンスに戻った後に送信できることを意味します。
- synchronous_standby_names='ANY 2 (s1,s2,s3)' は、 3 つのスタンバイ マシン s1、s2、および s3 のうちの任意の 2 つがメイン インスタンスに戻って送信できることを意味します。
- synchronous_standby_names='ANY 2 (*)' は、 すべてのスタンバイ マシンのうち任意の 2 台のスタンバイ マシンがメイン インスタンスに戻ってサブミットできることを意味します。
- synchronous_standby_names='*' は、 任意のホストと一致することを意味します。つまり、任意のホストが戻って送信できます。
ここで注意すべき点の 1 つは、これは同期レプリケーション中の PostgreSQL の既知の問題であるということです。プライマリ インスタンスとスタンバイ データベース s1 が同期モードにあり、構成ポイントから synchronous_standby_names が synchronous_standby_names='s1' として構成されていると仮定します。一見すると、プライマリ インスタンスがクライアントに正常なトランザクション操作応答を返す前に、データが s1 に送信され、s1 が正常に応答する必要があるように見えますが、実際には、スタンバイ データベースがダウンしているとき、プライマリ インスタンスがトランザクション操作では、s1 スタンバイ データベースの戻りを待っているとき、s1 データベースがハングアップしているため、この操作は必ずタイムアウトになります。アクティブ ノードとスタンバイ ノード間の通信がタイムアウトしても、プライマリ ノードは戻ります。トランザクションがクライアントに正常に送信されたことを示すコマンドであり、クライアントの操作は引き続き成功しますが、同時に各トランザクション操作はこのタイムアウト プロセスを通過する必要があるため、クライアント上のすべてのトランザクション操作は相対的に停止します。
たとえば、各挿入ではプライマリ インスタンスとスタンバイ データベース間の通信タイムアウト プロセスが実行されるため、各挿入アクションが完了するまでに約 30 秒かかり、アプリケーションが非常にスタックしてしまいます。現時点では、これは (非常にスタックした) 独立モードで実行されているメイン インスタンスと同等です。この状況は、スタンバイ データベースがオンラインに戻った後に通常に戻ります (スタンバイ データベースが短時間で復元できない場合は、メイン インスタンスの synchronous_standby_names 設定を調整して、s1 スタンバイ データベースのトランザクションが検証を待機しており、単一データベース操作モードに変更してインスタンスを再起動した後はスタックしません) を削除できますが、注意が必要です。プライマリ インスタンスがスタンバイ データベースから独立して実行されている場合、この時点でプライマリ インスタンスに障害 (ハードディスクの破損など) が発生すると、データ損失が発生します。したがって、保証レベルを高めるために、少なくとも 2 つのスレーブ インスタンスを用意することをお勧めします。
次に、メインインスタンスの pg_hba.conf を調整し、レプリケーション モードの接続ホワイトリスト設定を追加する必要があります。
ホスト レプリケーションすべて 0.0.0.0/0 scram-sha-256
構成ファイルを調整した後は、必ずマスター インスタンスを再起動してください。
マスター インスタンスが再起動された後、マスター インスタンスに接続してレプリケーション スロットを作成する必要もあります。デフォルトでは、WAL アーカイブ ファイルは循環的にクリーンアップされるため、問題が発生します。スレーブ インスタンスがハングアップし、長時間オフラインになる場合は、メイン インスタンスの WAL ファイルが循環的に削除されたことが原因である可能性があります。この場合、セカンダリ インスタンスが復元されて再びオンラインになったとしても、WAL アーカイブの一部が削除されるため、プライマリ インスタンスのファイルがクリーンアップされているため、プライマリ インスタンスのデータの進行状況に追いつくことができません。エラーが直接報告されます。このシナリオの存在により、レプリケーション スロットの概念が PostgreSQL に登場しました。マスター インスタンスは複数のレプリケーション スロットを作成でき、1 つのレプリケーション スロットはスレーブ インスタンスにバインドされます。レプリケーション スロットの利点は、スレーブ インスタンスは WAL を取得します。ファイルは後でクリーンアップされますが、上記のスクロール サイクルの自動クリーンアップには問題ありません。
レプリケーション スロットのメンテナンスはメイン インスタンスで実行されます。作成、クエリ、および削除のステートメントは次のとおりです。
レプリケーション スロットの作成SELECT * FROM pg_create_physical_replication_slot('slot1');
すべてのレプリケーション スロットをクエリするSELECT slot_name, slot_type, active FROM pg_replication_slots; slot_name | slot_type | active
レプリケーションスロットを削除するSELECT * FROM pg_drop_replication_slot('slot1')
この時点で、マスター インスタンスの構成は完了です。次のステップは、スレーブ インスタンスを準備することです。マスター インスタンスの実行を直接停止し、PostgreSQL フォルダーとデータ全体をパックして圧縮し、次の場所にコピーします。新しいサーバーをスレーブ インスタンスとして起動します。
ここでは、クラウド サーバー上で PostgreSQL を直接パックして圧縮し、それをスレーブ インスタンスとしてローカル解凍にコピーすることを選択します。
ローカル解凍後、スレーブ インスタンスとして次の調整を行う必要があります。 postgresql.conf
Primary_conninfo = 'host=xxxx port=5432 user=postgres password=xxxxxx application_name=s'
Primary_slot_name = 'slot1'
Primary_conninfoの主な内容 は、プライマリ インスタンスの接続文字列情報であり、次に application_name を追加します。application_name は、 以前に プライマリ インスタンスで構成した synchronous_standby_namesに関連付けられています 。 プライマリ インスタンスのすべてのトランザクション操作は前に構成しており、待機する必要があります。 s という名前のスタンバイ データベースが同期的に実行されます。実行後、
primary_slot_name はレプリケーション スロットの名前です。 スレーブ インスタンスが使用するために、以前にスロット 1のレプリケーション スロットを作成しました。
ここで注意すべき点は、構成中に複数のスレーブ インスタンスがある場合、1 つのスレーブ インスタンスが 1 つのレプリケーション スロットに対応し、1 つの application_name にバインドされるということです。
次に、データ ディレクトリに空のファイル
standby.signalを作成します。
このファイルは実際にはシグナル マークであり、現在のインスタンスが読み取り専用インスタンスとして識別され、データの挿入には使用できません。
次に、スタンバイ データベースを起動すると、通常は次のインターフェイスが表示されます。
この時点で、マスター インスタンス上にデータベースを作成していくつかの操作を実行し、スレーブ インスタンスに接続してみると、双方が相互に同期していることがわかります。
スレーブ インスタンスとマスター インスタンスの関連付けを解除する場合、操作は次のとおりです。 マスター
インスタンスの postgresql.conf から synchronous_standby_names を見つけて 、s ノードの設定
#synchronous_standby_names='s
を削除します。 スレーブ ノードが 1 つしかない場合は、次に # を直接追加して synchronous_standby_names にコメントを付けます。調整後にマスター インスタンスを再起動します
。
次に、スレーブ インスタンスの postgresql.conf を開き、
#primary_conninfo
#primary_slot_name
をコメントしてノード情報を構成し、データ ディレクトリ内の standby.signalファイルを削除して 、スレーブ インスタンスを再起動します。
ここまで、Windows 環境での PostgreSQL 物理レプリケーション高可用性アーキテクチャ データベース サービスの構築について説明してきましたが、ご不明な点がございましたら、記事の下にコメントするか、プライベート メッセージをお送りください。活発な議論や意見交換を歓迎します。