PostgreSQL論理レプリケーションを最適化する方法

論理レプリケーションまたはPglogicalは、テーブルレベルのWALベースのレプリケーションメカニズムであり、2つのPostgreSQLインスタンス間で特定のテーブルのデータをレプリケートします。 「pglogical」と「LogicalReplication」の間には混乱があるようです。どちらも同じ種類のレプリケーションメカニズムを提供しますが、機能と機能にいくつかの違いがあります。論理レプリケーションは、拡張機能であるpglogicalとは異なり、組み込み機能としてPostgreSQL-10に導入されています。継続的な開発が進行中の「pglogical」は、10より前のバージョンのPostgreSQLを使用してこれらの環境に論理レプリケーションを実装するための唯一のオプションとして残っています。最終的に、pglogicalのすべての機能は論理レプリケーションの一部になります。つまり、pglogical（拡張）はLogical Replication（組み込み機能）になりました。論理レプリケーションの基本的な利点は、拡張機能をインストール/作成する必要がないことです。これは、拡張機能のインストールが制限されている環境に役立ちます。

このブログでは、論理レプリケーションの最適化に焦点を当てます。つまり、このブログで強調表示されている最適化のヒントと手法は、論理レプリケーションと論理レプリケーションの両方に適用されます。

論理レプリケーションは、この種の最初のWALベースのレプリケーションです。 DBAとして、これは、他のトリガーベースのレプリケーションソリューションと比較した場合、はるかに信頼性が高く、パフォーマンスの高いレプリケーションメカニズムになります。 pglogicalレプリケーションのテーブル部分に加えられた変更は、WALレコードを介してリアルタイムでレプリケートされるため、非常に効率的で複雑ではありません。市場に出回っている他のすべてのレプリケーションメカニズムはトリガーベースであり、パフォーマンスとメンテナンスの課題を引き起こす可能性があります。論理レプリケーションが導入されると、トリガーベースのレプリケーションへの依存はほとんどなくなります。

論理レプリケーションを非常に詳細に構成する方法を説明しているブログは他にもあります。

このブログでは、論理レプリケーションを最適化する方法に焦点を当てます。

論理レプリケーションの最適化

まず、「論理レプリケーション」の動作は「ストリーミングレプリケーション」と非常に似ています。唯一の違いは、ストリーミングレプリケーションがデータベース全体をレプリケートするのに対し、論理レプリケーションは個々のテーブルのみをレプリケートすることです。複製する特定の個々のテーブルを選択する場合、予測する必要のある要因/課題があります。

論理レプリケーションに影響を与える要因を見てみましょう。

論理レプリケーションのパフォーマンスに影響を与える要因

論理レプリケーションを最適化することは、データが中断することなくシームレスにレプリケートされるようにするために重要です。設定する前に予測する要素があります。それらを見てみましょう：

• 複製されるテーブルに保存されているデータのタイプ
• テーブル（レプリケーションの一部）のトランザクションアクティブ度
• インフラストラクチャの容量を予測する必要があります
• パラメータの設定は最適に行う必要があります

上記のすべての要因は、論理レプリケーションに大きな影響を与えます。それらを詳しく見てみましょう。

PostgreSQL論理レプリケーションデータ型

テーブルに格納されているデータのタイプを理解することは重要です。レプリケーションのテーブル部分に大きなテキストまたはバイナリオブジェクトが格納されていて、多数のトランザクションが発生した場合、インフラストラクチャリソースの使用率が高いため、レプリケーションの速度が低下する可能性があります。インフラストラクチャの容量は、このような複雑で大きなサイズのデータ​​レプリケーションを処理するのに十分でなければなりません。

アクティブなテーブルがトランザクション的にレプリケーションの一部である方法

トランザクションが非常にアクティブなテーブルを複製する場合、I / Oパフォーマンスの問題、デッドロックなどを考慮する必要があるため、複製が同期に遅れる可能性があります。これにより、本番データベース環境がより健全に見えるとは限りません。複製されるテーブルの数が多く、データが複数のサイトに複製される場合は、CPUの使用率が高くなり、より多くのCPU（またはCPUコア）が必要になる可能性があります。

インフラストラクチャ容量

論理レプリケーションをソリューションとして検討する前に、データベースサーバーのインフラストラクチャ容量が十分であることを確認することが重要です。複製されるテーブルの数が多い場合は、複製ジョブを実行するのに十分なCPUが使用可能である必要があります。

多数のテーブルを複製する場合は、それらをグループに分割して並列に複製することを検討してください。この場合も、レプリケーションに使用できるようにするには複数のCPUが必要になります。レプリケートされるテーブルへのデータ変更が頻繁かつ高い場合、これはレプリケーションのパフォーマンスにも影響を与える可能性があります。

論理レプリケーションのパラメータの最適化

論理レプリケーション機能用に構成されたパラメーターは、レプリケーションが中断しないように最適に調整する必要があります。

まず、構成に必要なパラメーターを見てみましょう。

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

max_wal_sendersの調整

max_wal_sendersは、常にレプリカの数よりも大きくする必要があります。データが複数のサイトに複製される場合、複数のmax_wal_sendersが機能します。したがって、このパラメータが最適な数に設定されていることを確認することが重要です。

max_replication_slotsの調整

一般に、テーブルで発生するすべてのデータ変更は、WALレコードと呼ばれるpg_xlog/pg_walのWALファイルに書き込まれます。 Wal送信者プロセスはそれらのWALレコード（複製されるテーブルに属する）を取得してレプリカに送信し、レプリカサイトのwal_receiverプロセスはそれらの変更をサブスクライバーノードに適用します。

チェックポイントが発生するたびに、WALファイルはpg_xlog/pg_walの場所から削除されます。変更がサブスクライバーノードに適用される前でもWALファイルが削除されると、レプリケーションが中断して遅れることになります。サブスクライバーノードが遅れている場合、レプリケーションスロットにより、サブスクライバーがプロバイダーと同期するために必要なすべてのWALファイルが保持されます。各サブスクライバノードに1つのレプリケーションスロットを設定することをお勧めします。

max_worker_processesの調整

最適な数のワーカープロセッサを構成することが重要です。これは、サーバーが持つことができるプロセスの最大数によって異なります。これは、マルチCPU環境でのみ可能です。 Max_worker_processesは、複数のCPUコアを利用することで、複数のプロセスが生成され、ジョブをより高速に実行できるようにします。論理レプリケーションを使用してデータをレプリケートする場合、このパラメーターは、データをより高速にレプリケートするための複数のワーカープロセスを生成するのに役立ちます。 max_logical_worker_processesと呼ばれる特定のパラメーターがあり、データのコピーに複数のプロセスが使用されるようにします。

max_logical_worker_processesの調整

このパラメーターは、テーブル・データの複製と同期を実行するために必要な論理ワーカー・プロセスの最大数を指定します。この値はmax_worker_processesから取得され、このパラメーター値よりも大きくする必要があります。このパラメーターは、マルチCPU環境で複数のサイトにデータを複製する場合に非常に役立ちます。デフォルトは4です。最大値は、システムがサポートするワーカープロセスの数によって異なります。

max_sync_workers_per_subscriptionの調整

このパラメーターは、サブスクリプションごとに必要な同期プロセスの最大数を指定します。同期プロセスは最初のデータ同期中に行われ、それをより速く行うために、このパラメーターを使用できます。現在、テーブルごとに構成できる同期プロセスは1つだけです。つまり、複数のテーブルを最初に並行して同期できます。デフォルト値は2です。この値はmax_logical_worker_processes値から選択されます。

これらは、論理レプリケーションが効率的かつ高速であることを保証するために調整する必要のあるパラメーターです。論理レプリケーションにも影響するその他のパラメータは次のとおりです。

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

これらのパラメーターは、プロバイダーノードには影響しません。

結論

レプリケーション固有のテーブルは、大規模で複雑なデータベースシステムで発生する一般的な要件です。これは、ビジネスレポートまたはデータウェアハウスの目的である可能性があります。 DBAとして、論理レプリケーションは、実装が簡単で複雑さが少ないため、このような目的に大いに対応できると思います。論理レプリケーションの構成と調整には、かなりの量の計画、設計、およびテストが必要です。リアルタイムで複製されるデータの量を評価して、効率的で見た目が少ない複製システムが導入されていることを確認する必要があります。結論として、PostgreSQL-10で実行されているデータベース、論理レプリケーションが最適な方法であり、PostgreSQLバージョン<10で実行されているデータベースの場合、pglogicalがオプションです。