このページでは、pglogical 拡張機能の概要、メリット、制限事項について説明します。
概要
pglogical 拡張機能は、PostgreSQL 用に設計された堅牢で柔軟な論理レプリケーション ツールであり、高可用性（HA）と障害復旧（DR）もサポートしています。
従来のバイナリ レプリケーション（一般に物理レプリケーションと呼ばれます）では、ファイルシステムとブロックレベルで変更がレプリケートされ、ターゲット システムに物理ミラーが作成されます。物理レプリケーションは堅牢でデータベース クラスタ全体を保護しますが、単方向のみで、基盤となるデータベース データファイルと write-ahead log（WAL）ファイルへのアクセスが必要です。
一方、pglogical 拡張機能は、プロバイダ データベースから SQL 変更を抽出して複製し、1 つ以上のサブスクライバー データベースに対して再生します。このレプリケーションは論理レプリケーションと呼ばれます。
pglogical 拡張機能を使用すると、次のことができます。
- 複数の AlloyDB Omni データベース間でデータを複製します。
- AlloyDB Omni と Google Cloud AlloyDB 間でデータを複製します。
- AlloyDB Omni と、サードパーティのクラウド サービスに含まれる多くの PostgreSQL ディストリビューション間でデータを複製します。
利点
pglogical 拡張機能による論理レプリケーションには、次の利点があります。
選択的レプリケーション: フィルタとルールを柔軟に設定して、複製するデータと複製先を決定できます。どのテーブルを含めるか、新しいテーブルを含めるかどうか、新しいテーブルをどのように処理するかを選択できます。列フィルタと行フィルタを追加することもできます。サブスクライバーがプロバイダからの後続の時点を表すようにする場合は、オプションの
apply delayを追加できます。双方向およびマルチプライマリ レプリケーション: すべてのメンバー データベースは読み取り/書き込み状態で開かれ、完全に使用できます。各エンドポイント データベースはプロバイダとサブスクライバーの両方として機能するため、高度なレプリケーション シナリオを作成でき、異なるエンドポイントでデータ更新を行うことができます。
クラウド プロバイダのサポート: Google などのクラウド プロバイダは、
pglogical拡張機能の価値を認識し、Google Cloud SQL for PostgreSQL や AlloyDB などのクラウド サービスに統合しています。他のクラウド プロバイダにも、オプションとしてpglogical拡張機能が含まれているため、マルチクラウドまたはハイブリッド クラウドの構成が可能です。クロス バージョン レプリケーション: pglogical は実際の SQL ステートメントを複製するため、PostgreSQL のメジャー バージョン間でレプリケーションできます。特に、プロバイダのソース データベースがサブスクライバーのターゲット データベースよりもバージョンが低い場合は、クロスバージョン レプリケーションを信頼性を持って実装できます。
pglogical拡張機能は、バージョン 9.4 以降など、古いバージョンの PostgreSQL の多くをサポートしています。そのため、従来システムを扱っていて、AlloyDB Omni や Google Cloud AlloyDB で使用されているような、より新しいバージョンの PostgreSQL にデータを複製する必要があるシナリオに最適です。
要約すると、pglogical 拡張機能は、古いバージョンの PostgreSQL と、Google Cloud SQL for PostgreSQL や AlloyDB などの Cloud マネージド サービスとの互換性を備えた、機能豊富な論理レプリケーション ソリューションを提供します。
論理レプリケーションの制限事項
他のリレーショナル データベース プラットフォームで使用されるものも含め、すべての論理レプリケーション テクノロジーにはある程度の制限があり、不適切な管理を行うとレプリケーション プロセスが中断する可能性があります。
信頼性の高い実装を行うには、次の点に注意してください。
- レプリケーション スコープ外の、データベース スコープとクラスタ スコープのオブジェクトを処理する方法に関する考慮事項。
pglogical拡張機能は、データベース レベルで、指定されたテーブルとシーケンスのセットにのみ作用します。関数やプロシージャなどの他のオブジェクト タイプは、他の方法で複製する必要があります。 - すべてのレプリケーション テーブルに主キーを設定することをおすすめします。テーブルの
REPLICA IDENTITY機能を使用して、行を一意に識別する列をpglogical拡張機能に通知できます。可能であれば、この方法は避けてください。主キーのないテーブルは、本質的に静的であり、UPDATEDまたはDELETEDになることはなく、INSERTSのみをサポートします。このようなテーブルには主キーは必要ありません。 - サブスクライバー データベース内のトリガーとシーケンスの管理。デフォルトでは、トリガーは
ORIGINトリガーまたはLOCALトリガーとして定義され、行が複製されたときにサブスクライバー データベースでトリガーされません。すべてのトリガーをチェックし、トリガーにREPLICAオプションが設定されていることを確認して、必要でない限りサブスクライバー側でトリガーがトリガーされないようにする必要があります。 - 競合の解決は、
who winsルールを介して手動または自動で処理します。 - データ定義言語（DDL）コマンドのレプリケーション。すべてのエンドポイントに手動で実装するか、プロバイダ データベースで適切な
pglogicalAPI 関数を使用して、サブスクライバー データベースに DDL を自動的にレプリケートします。 - 新しく作成されたテーブルとシーケンスが、プライマリ データベースのレプリケーション セットに手動または自動で追加されるようにします。
- レプリケーション トポロジ内のすべてのエンドポイント間に、堅牢で高パフォーマンス、信頼性の高い、安全な TCP ネットワークが存在することを確認します。
pglogical 拡張機能のその他の制限事項には、次のようなものがあります。
- 現在、
pglogicalバージョン 2.4.3 にはスーパーユーザー権限が必要です。 - ほとんどのテーブルとシーケンスは複製できますが、他のオブジェクト タイプは
pglogical拡張機能によって複製されず、TEMPORARYテーブルとUNLOGGEDテーブルは複製されません。 - DDL を複製するには、pglogical API 関数を使用する必要があります。ネイティブ DDL コマンドは、
TRUNCATEコマンドを除き、複製されません。 - テーブルとシーケンスごとにオブジェクト レベルで動作し、データベースごとにデプロイされます。つまり、
usersやrolesなどのクラスタ スコープのオブジェクトなど、一部のオブジェクトはレプリケーションから除外され、個別に管理する必要があります。