サポートコンソール開発者トライアルの開始お問い合わせ

7.5. Debezium コネクターを実行するための PostgreSQL の設定

本リリースの Debezium では、ネイティブの pgoutput 論理レプリケーションストリームのみがサポートされます。pgoutput プラグインを使用するように PostgreSQL を設定するには、レプリケーションスロットを有効にし、レプリケーションの実行に必要な権限を持つユーザーを設定します。

詳細は以下を参照してください。

7.5.1. Debezium pgoutput プラグインのレプリケーションスロットの設定

PostgreSQL の論理デコード機能はレプリケーションスロットを使用します。レプリケーションスロットを設定するには、postgresql.conf ファイルに以下を指定します。 

wal_level=logical
max_wal_senders=1
max_replication_slots=1

これらの設定は、PostgreSQL サーバーを以下のように指示します。

  • wal_level - 先行書き込みログで論理デコードを使用します。
  • max_wal_senders - WAL 変更の処理に、1 つの個別プロセスの最大を使用します。
  • max_replication_slots - WAL の変更をストリーミングするために作成される 1 つのレプリケーションスロットの最大を許可します。

レプリケーションスロットは、Debezium の停止中でも Debezium に必要なすべての WAL エントリーを保持することが保証されいます。したがって、以下の点を避けるために、レプリケーションスロットを注意して監視することが重要になります。

  • 過剰なディスク消費量。
  • レプリケーションスロットが長期間使用されないと発生する可能性がある、あらゆる状態 (カタログの肥大化など)。

詳細は、レプリケーションスロットに関する PostgreSQL のドキュメント を参照してください。

注記

PostgreSQL ログ先行書き込みの設定 や仕組みを理解していると、Debezium PostgreSQL コネクターを使用する場合に役立ちます。

7.5.2. Debezium コネクターの PostgreSQL パーミッションの設定

PostgreSQL サーバーを設定して Debezium コネクターを実行するには、レプリケーションを実行できるデータベースユーザーが必要です。レプリケーションは、適切なパーミッションを持つデータベースユーザーのみが実行でき、設定された数のホストに対してのみ実行できます。

セキュリティーで説明されているように、スーパーユーザーはデフォルトで必要な REPLICATION および LOGIN ロールを持っていますが、Debezium レプリケーションユーザーの権限を昇格しないことが推奨されます。代わりに、必要最低限の特権を持つ Debezium ユーザーを作成します。

前提条件

  • PostgreSQL の管理者権限。

手順

  1. ユーザーにレプリケーションの権限を付与するには、少なくとも REPLICATION および LOGIN権限を持つ PostgreSQL ロールを定義し、そのロールをユーザーに付与します。以下はその例です。 

    CREATE ROLE <name> REPLICATION LOGIN;

7.5.3. Debezium が PostgreSQL パブリケーションを作成できるように権限を設定

Debezium は、PostgreSQL ソーステーブルの変更イベントを、テーブル用に作成された パブリケーション からストリーミングします。パブリケーションには、1 つ以上のテーブルから生成される変更イベントのフィルターされたセットが含まれます。各パブリケーションのデータは、パブリケーションの仕様に基づいてフィルターされます。この仕様は、PostgreSQL データベース管理者または Debezium コネクターが作成できます。Debezium PostgreSQL コネクターに、パブリケーションの作成やレプリケートするデータの指定を許可するには、コネクターはデータベースで特定の権限で操作する必要があります。

パブリケーションの作成方法を決定するオプションは複数あります。通常、コネクターを設定する前に、キャプチャーするテーブルのパブリケーションを手動で作成することが推奨されます。しかし、Debezium がパブリケーションを自動的に作成し、それに追加するデータを指定できるように、ご使用の環境を設定できます。

Debezium は include list および exclude list プロパティーを使用して、データがパブリケーションに挿入される方法を指定します。Debezium がパブリケーションを作成できるようにするオプションの詳細は、publication.autocreate.modeを参照してください。

Debezium が PostgreSQL パブリケーションを作成するには、以下の権限を持つユーザーとして実行する必要があります。

  • パブリケーションにテーブルを追加するためのデータベースのレプリケーション権限。
  • パブリケーションを追加するためのデータベースの CREATE 権限。
  • 最初のテーブルデータをコピーするためのテーブルの SELECT 権限。テーブルの所有者には、テーブルに対する SELECT 権限が自動的に付与されます。

テーブルをパブリケーションに追加する場合は、ユーザーはテーブルの所有者である必要があります。ただし、ソーステーブルはすでに存在するため、元の所有者と所有権を共有する仕組みが必要です。共有所有権を有効にするには、PostgreSQL レプリケーショングループを作成した後、既存のテーブルの所有者とレプリケーションユーザーをそのグループに追加します。

手順

  1. レプリケーショングループを作成します。 

    CREATE ROLE <replication_group>;

  2. テーブルの元の所有者をグループに追加します。 

    GRANT REPLICATION_GROUP TO <original_owner>;

  3. Debezium レプリケーションユーザーをグループに追加します。 

    GRANT REPLICATION_GROUP TO <replication_user>;

  4. テーブルの所有権を <replication_group> に移します。 

    ALTER TABLE <table_name> OWNER TO REPLICATION_GROUP;

Debezium がキャプチャ設定を指定するためには、の値が publication.autocreate.mode を filtered に設定する必要があります。

7.5.4. Debezium コネクターホストでのレプリケーションを許可するように PostgreSQL を設定

Debezium による PostgreSQL データのレプリケーションを可能にするには、データベースを設定し、PostgreSQL コネクターを実行するホストでのレプリケーションを許可する必要があります。データベースとのレプリケーションが許可されるクライアントを指定するには、エントリーを PostgreSQL ホストベースの認証ファイル pg_hba.conf に追加します。pg_hba.conf ファイルの詳細は、the PostgreSQL のドキュメントを参照してください。

手順

  • pg_hba.conf ファイルにエントリーを追加して、データベースホストでレプリケートできる Debezium コネクターホストを指定します。以下に例を示します。

    pg_hba.conf ファイルの例です。

    local   replication     <youruser>                          trust   1
host    replication     <youruser>  127.0.0.1/32            trust   2
host    replication     <youruser>  ::1/128                 trust   3

    1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
    ローカル (つまりサーバーマシン上) で <youruser> のレプリケーションを許可するようにサーバーに指示します。
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    IPV4 を使用してレプリケーションの変更を受信することを、localhost の <youruser> に許可するようサーバーに指示します。
    3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
    IPV6 を使用したレプリケーション変更の受信を localhost の <youruser> に許可するようサーバーに指示します。
注記

ネットワークマスクの詳細は、PostgreSQL のドキュメント を参照してください。

7.5.5. Debezium WAL ディスク領域の消費を管理するための PostgreSQL の設定

場合によっては、WAL ファイルによって使用される PostgreSQL ディスク領域が、異常に急上昇したり増加することがあります。このような場合、いくつかの理由が考えられます。

  • コネクターがデータを受信した最大の LSN は、サーバーの pg_replication_slots ビューの confirmed_flush_lsn 列で確認できます。この LSN よりも古いデータは利用できず、データベースがディスク領域を解放します。

    また、pg_replication_slots ビューの restart_lsn 列には、コネクターが必要とする可能性のある最も古い WAL の LSN が含まれています。confirmed_flush_lsn の値が定期的に増加し、restart_lsn の値に遅延が発生する場合は、データベースは領域を解放する必要があります。

    データベースは、通常バッチブロックでディスク領域を解放します。これは想定内の動作であり、ユーザーによるアクションは必要ありません。

  • 追跡されるデータベースには多くの更新がありますが、一部の更新のみがコネクターの変更をキャプチャーするテーブルおよびスキーマに関連します。この状況は、定期的なハートビートイベントで簡単に解決できます。コネクターの heartbeat.interval.ms コネクター設定プロパティーを設定します。

  • PostgreSQL インスタンスには複数のデータベースが含まれ、その 1 つがトラフィックが多いデータベースです。Debezium は、他のデータベースと比較して、トラフィックが少ない別のデータベースで変更をキャプチャーします。レプリケーションスロットがデータベースごとに機能し、Debezium が呼び出しされないため、Debezium は LSN を確認できません。WAL はすべてのデータベースで共有されているため、Debezium が変更をキャプチャーするデータベースによってイベントが出力されるまで、使用量が増加する傾向にあります。これに対応するには、以下を行う必要があります。

    • heartbeat.interval.ms コネクター設定プロパティーを使用して、定期的なハートビートレコードの生成を有効にします。
    • Debezium が変更をキャプチャーするデータベースから変更イベントを定期的に送信します。

    新しい行を挿入したり、同じ行を定期的に更新することで、別のプロセスがテーブルを定期的に更新します。次に PostgreSQL は Debezium を呼び出して、最新の LSN を確認し、データベースが WAL 領域を解放できるようにします。このタスクは、heartbeat.action.query コネクター設定プロパティーを使用して自動化できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.