PostgreSQLデータをリモートサイトに複製する方法

大規模なデータベースを使用するビジーなデータベース環境では、リアルタイムのデータレプリケーションが必要になることがよくあります。多くの場合、アプリケーションでは、分析やその他の重要なビジネスオペレーションのニーズのために、本番データをリモートサイトにリアルタイムで複製する必要があります。

DBAは、さまざまな要件を満たすために、データがリモートサイトに継続的に複製されるようにする必要もあります。ただし、これらの要件は、データベース全体を複製することであるとは限りません。データのサブセットのみを複製する必要がある場合もあります（テーブルまたはテーブルのセット、または分析やレポートなどにSQLを使用した複数のテーブルからのデータなど）

このブログでは、テーブルをリモートデータベースにリアルタイムで複製する方法に焦点を当てます。

テーブルレベルのレプリケーションとは何ですか？

テーブルレベルのレプリケーションは、特定のテーブルまたはテーブルのセットのデータを、分散環境でリモートでホストされている1つのデータベース（ソース）から別のデータベース（ターゲット）にレプリケートするメカニズムです。テーブルレベルのレプリケーションにより、テーブルデータが継続的に分散され、レプリケートされた（ターゲット）サイト間で一貫性が保たれます。

テーブルレベルのレプリケーションを使用する理由

テーブルレベルのレプリケーションは、大規模で複雑な高度に分散された環境では不可欠なニーズです。私の経験では、レポートの目的で、テーブルのセットを本番データベースからデータウェアハウスに複製する必要が常にありました。レポートが最新のデータを取得していることを確認するには、データを継続的に複製する必要があります。重要な環境では、データの古さは許容できないため、本番環境で発生するデータの変更は、ターゲットサイトにすぐに複製する必要があります。これは、効率的でスムーズなテーブルレプリケーションを確保するために、DBAがさまざまな要因を予測する必要があるための実際の課題になる可能性があります。

テーブルレベルのレプリケーションが解決するいくつかの要件を見てみましょう。

• レポートは、データウェアハウジングなど、本番環境以外の環境のデータベースで実行できます
• 複数のサイトからデータを抽出する分散アプリケーションを備えた分散データベース環境。分散型Webまたはモバイルアプリケーションの場合、同じデータのコピーを複数の場所で利用できるようにして、さまざまなアプリケーションのニーズに対応する必要があります。テーブルレベルのレプリケーションが優れたソリューションになる可能性があります。
• 地理的に分散したさまざまなデータセンターまたはクラウドインスタンスにあるさまざまなデータベースのデータを一元化されたデータベースで利用できるようにする必要があるPayrollアプリケーション

テーブルレベルのレプリケーションに影響を与えるさまざまな要因-何を探すべきか

前述のように、DBAは、効果的なテーブルレベルのレプリケーションシステムを設計および実装するために、さまざまなリアルタイムコンポーネントと要素を考慮する必要があります。

テーブル構造

収容しているデータテーブルのタイプは、レプリケーションのパフォーマンスに大きな影響を与えます。テーブルがより大きなサイズのバイナリデータを含むBYTEA列に対応している場合、レプリケーションのパフォーマンスが低下する可能性があります。ネットワーク、CPU、およびディスクに対するレプリケーションの影響を慎重に評価する必要があります。

データサイズ

移行するテーブルが大きすぎると、最初のデータ移行にリソースと時間がかかるため、DBAは本番データベースが影響を受けないようにする必要があります。

インフラストラクチャリソース

信頼性が高く安定したパフォーマンスのレプリケーションシステムを構築できるようにするには、インフラストラクチャに十分なリソースを用意する必要があります。どのインフラストラクチャコンポーネントを考慮する必要がありますか？

CPU

データレプリケーションはCPUに大きく依存しています。本番環境から複製する場合、CPUが使い果たされて、本番環境のパフォーマンスに影響を与える可能性があります。

ネットワーク

レプリケーションのパフォーマンスにとって重要です。ソースデータベースとターゲットデータベース間のネットワーク遅延は、レプリケーションを高速化するのに十分な帯域幅があることを確認するために、ストレステストによって評価する必要があります。また、同じネットワークが他のプロセスやアプリケーションによって使い果たされる可能性があります。したがって、容量計画はここで行う必要があります。

メモリ

レプリケーションを高速化するために十分なデータがキャッシュされるようにするには、十分なメモリが利用可能である必要があります。

ソーステーブルの更新

ソーステーブルのデータ変更が多い場合、レプリケーションシステムは、変更をできるだけ早くリモートサイトに同期する機能を備えている必要があります。レプリケーションは、リソースを大量に消費する可能性のある多数の同期要求をターゲットデータベースに送信することになります。

インフラストラクチャの種類（データセンターまたはクラウド）もレプリケーションのパフォーマンスに影響を与え、課題を引き起こす可能性があります。監視の実装も課題になる可能性があります。遅延があり、ターゲットデータベースに特定のデータがない場合、監視が困難であり、同期できない可能性があります

テーブルレプリケーションを実装する方法

PostgreSQLでのテーブルレベルのレプリケーションは、市場で入手可能なさまざまな外部ツール（商用またはオープンソース）を使用して、またはカスタムビルドのデータストリームを使用して実装できます。

これらのツールのいくつか、それらの機能と機能を見てみましょう...

スロニー

Slonyは、特定の個々のテーブルを1つのPostgreSQLデータベースから別のデータベースにリアルタイムで非同期的に複製するために使用される最も一般的なツールの1つです。これは、あるサイトのデータベースから別のサイトへのテーブル（またはテーブルのセット）のデータ変更のトリガーベースのレプリケーションを実行するPerlベースのツールです。非常に信頼性が高く、長年の開発の歴史があります。信頼性は高く、トリガーベースのツールであるため、レプリケーション設定の管理が複雑になる可能性があります。

Slonyのいくつかの機能を見てみましょう...

Slonyを使用する利点

• マスターからスレーブまたは複数のスレーブへのレプリケーション方法をサポートし、水平方向の読み取りのスケーラビリティを強化します。言い換えれば、スレーブは書き込み可能ではありません
• 単一のマスターに複数のスレーブを構成することが可能であり、カスケードレプリケーション手法もサポートします
• スイッチオーバーおよびフェイルオーバーメカニズムをサポートします
• 多数のテーブルをグループで並行して複製できます
• PostgreSQLインスタンスの異なるメジャーバージョン間で複製できるため、Slonyはデータベースのアップグレードに最適なオプションです
• インストールが簡単

Slonyを使用するデメリット

• DDLレプリケーションをサポートしていません
• 特定のスキーマ変更により、レプリケーションが中断される可能性があります
• レプリケーションイベントは、データベース内のSlony固有のログテーブルに記録されるため、メンテナンスのオーバーヘッドが発生する可能性があります。
• 大規模なデータセットを含む膨大な数のテーブルを複製する場合、パフォーマンスとメンテナンスが深刻な問題を引き起こす可能性があります
• トリガーベースのレプリケーションであるため、パフォーマンスに影響を与える可能性があります

ブカルド

Bucardoは、PostgreSQL用の別のオープンソースperlベースのレプリケーションシステムであり、2つ以上のPostgreSQLインスタンス間で特定のテーブルデータの非同期レプリケーションをサポートします。 BucardoがSlonyと異なる点は、マルチマスターレプリケーションもサポートしていることです。

bucardoが実装に役立つさまざまなタイプのレプリケーションメカニズムを見てみましょう...

• マルチマスターレプリケーション：テーブルは2つ以上のPostgreSQLインスタンス間で双方向にレプリケートでき、トランザクションデータは双方向に同期されます
• マスタースレーブ：マスターのテーブルからのデータは非同期でスレーブに複製され、スレーブは読み取り操作に使用できます
• フルコピーモード（マスタースレーブ）：Bucardo-/スレーブからすべてのデータを削除して、マスターからスレーブノードにデータ全体を複製します

ブカルドを使用する利点

• インストールが簡単
• マルチマスター、マスタースレーブ、およびフルコピーレプリケーションモードをサポートします
• データベースのアップグレードに使用できます
• 異なるPostgreSQLバージョン間でレプリケーションを実行できます

ブカルドを使用するデメリット

• トリガーベースのレプリケーションであるため、パフォーマンスが課題になる可能性があります
• DDLのようにスキーマを変更すると、レプリケーションが中断する可能性があります
• 多数のテーブルを複製すると、メンテナンスのオーバーヘッドが発生する可能性があります
• インフラストラクチャリソースは、レプリケーションのパフォーマンスを向上させるために最適化する必要があります。そうしないと、一貫性を実現できません。

PostgreSQL論理レプリケーション

論理レプリケーションはPostgreSQLの革新的な組み込み機能であり、WALレコードを介して個々のテーブルをレプリケートするのに役立ちます。 WALベースのレプリケーション（ストリーミングレプリケーションと同様）であることは、他のテーブルレプリケーションツールと比較した場合、論理的に際立っています。 WALレコードを介してデータを複製することは、ネットワーク上でデータを複製するための最も信頼性が高く、パフォーマンスの高い方法です。市場に出回っているほとんどすべてのツールは、論理レプリケーションを除いて、トリガーベースのレプリケーションを提供します。

PostgreSQL論理レプリケーションを使用する利点

• 単一のテーブルまたはテーブルのセットをレプリケーションする場合の最適なオプション
• レポートまたは分析の目的で、特定のテーブルをさまざまなデータベースから1つのデータベース（データウェアハウジングやレポートデータベースなど）に移行する必要がある場合は、このオプションが適しています。
• トリガーの手間はありません

PostgreSQL論理レプリケーションを使用することのデメリット

• WALファイル/WALアーカイブファイルの管理ミスは、論理レプリケーションに課題をもたらす可能性があります
• プライマリキーまたは一意のキーがないとテーブルを複製できません
• DDLとTRUNCATEは複製されません
• WALを削除すると、レプリケーションの遅延が増える可能性があります。つまり、レプリケーションとWAL管理は、レプリケーションが中断しないように相互に補完する必要があります。
• 大きなオブジェクトは複製できません

PostgreSQL論理レプリケーションと、PostgreSQL論理レプリケーションとストリーミングレプリケーションの違いをよりよく理解するのに役立つその他のリソースを次に示します。

外部データラッパー

外部データラッパーは実際にはデータを複製しませんが、実際にデータを複製せずにDBAが複製と同様のことを実現するのに役立つため、PostgreSQLのこの機能を強調したいと思います。これは、データがソースからターゲットに複製されず、ターゲットデータベースのアプリケーションからデータにアクセスできることを意味します。ターゲットデータベースには、ソーステーブルのホストとデータベースの詳細を含むリンクを持つテーブル構造のみがあり、アプリケーションがターゲットテーブルをクエリすると、データベースリンクと同様に、データがソースデータベースからターゲットデータベースにプルオーバーされます。 FDWが役立つ場合は、ネットワークを介してデータを複製するオーバーヘッドを完全に回避できます。多くの場合、データが物理的に存在していなくても、リモートのターゲットデータベースでレポートを実行できる状況に陥ります。

FDWは、次の状況で優れたオプションです-

• ソースデータベースに小さくて静的なテーブルがある場合、データを複製する価値はありません
• ソースデータベースに非常に大きなテーブルがあり、ターゲットデータベースで集計クエリを実行している場合は、非常に有益です。

外部データラッパーを使用する利点

• データの複製を完全に回避できるため、時間とリソースを節約できます
• 実装が簡単
• プルオーバーされたデータは常に最新です
• 頭上でのメンテナンスは不要

外部データラッパーを使用することのデメリット

• ソーステーブルの構造変更は、ターゲットデータベースのアプリケーション機能に影響を与える可能性があります
• ネットワークに大きく依存しており、実行されているレポートの種類によっては、ネットワークのオーバーヘッドが大きくなる可能性があります。
• クエリが実行されるたびにクエリが数回実行されると、パフォーマンスオーバーヘッドが予想されます。データは、ソースデータベースからネットワーク経由でプルする必要があり、ソースデータベースにパフォーマンスオーバーヘッドをもたらす可能性もあります。
• ソースに負荷がかかると、ターゲットデータベースのアプリケーションのパフォーマンスに影響を与える可能性があります

結論

• テーブルの複製は、ビジネスのさまざまな重要な目的に役立ちます
• 分散環境での分散並列クエリをサポートできます
• 同期を実装することはほぼ不可能です
• インフラストラクチャには十分な容量が必要であり、コストがかかります
• レポートおよび分析の目的で統合された一元化されたデータベースを構築するための優れたオプション