PostgreSQL Configuration for BDR

BDRnodeに影響を与えるいくつかのPostgreSQL構成パラメーターがあります。これらのパラメータは各ノードで異なるように設定できますが、一般的にはお勧めできません。

BDRのPostgreSQL設定

BDRを正しく実行するには、次のPostgreSQL設定が必要です。

  • wal_level- BDRはロジカルデコーディングに依存するため、logicalに設定する必要があります。

  • shared_preload_libraries-これにはbdrが含まれている必要がありますが、 必要に応じて、前後のその他のエントリ、ただし「pglogical」は 含まれる

  • track_commit_timestamp-競合を解決するには、「on」に設定する必要があります 競合する行のタイムスタンプを取得します。

BDRでは、これらのPostgreSQL設定を適切な値に設定する必要がありますが、これはクラスターのサイズとスケールによって異なります。

  • logical_decoding_work_mem-ロジカルデコーディングで使用されるメモリバッファサイズ。 これより大きいトランザクションはバッファをオーバーフローさせて保存されます ローカルディスクに一時的に。デフォルトは64MBですが、もっと高く設定することもできます。

  • max_worker_processes- BDRはレプリケーションにバックグラウンドワーカーを使用します メンテナンスタスクが必要なため、十分なワーカースロットが必要です。 正しく動作します。ワーカーの正しい最小数の式は次のとおりです。 PostgreSQLインスタンスごとに1つ+そのインスタンスのデータベースごとに1つ+ 4 BDR対応データベースBDRノードの同等なごとに1つ+それぞれに1つ データベースごとに、 BDRグループの同等なごとにライタが有効になりノード。 ノードの実行中に、追加のワーカープロセスが一時的に必要になる場合があります BDRグループから削除されました。 ノードすべての同等なごとに2つ必要です。

  • max_replication_slots-max_wal_sendersと同じ。

  • wal_sender_timeoutおよびwal_receiver_timeout-方法の決定 ノードはすぐにそのCAMOパートナーを切断されたと見なします 再接続; CAMO Failure Scenariosを参照 詳細。

N個の同等なを持つグループの通常の実行では、 BDRにはN個のスロット/ウォルセンダーが必要であることに注意してください。同期中、 BDRは一時的にanotherN-1スロット/ walsenderを使用するため、この時々のピーク需要に対応するために上記のパラメーターを十分に高く設定するよう注意してください。

並列適用をオンにすると、スロットの数を上記の式 *ライターからNスロットに増やすニーズがあります。これは、max_replication_slotsがレプリケーション起点の最大数も設定し、パラレルアプライの機能の一部がライタごとに余分なオリジンを使用するためです。

WALデコーダーが有効な場合、WALデコーダープロセスでは、 BDRグループごとに1つの追加のレプリケーションスロットが必要になります。

単一のデータベースを使用する4ノードBDRグループの一般に安全な推奨値は、max_replication_slotsおよびmax_worker_processesを50およびmax_wal_sendersに少なくとも10に設定することです。

また、これらのパラメーターを変更するには、ローカルノード：max_worker_processes、max_wal_senders、max_replication_slotsを再起動する必要があることに注意してください。

アプリケーションでは、これらのパラメーターを設定することもできます。詳細については、[耐久性とパフォーマンスオプション]の章を参照してください。

  • synchronous_commit- BDRレプリケーションの耐久性とパフォーマンスに影響します physical replicationと同様の方法で。

  • synchronous_standby_names-上記と同じ

EDB PG拡張およびEDB PG BDRの詳細設定

次のPostgres設定は、最大1回のコミット（CAMO）で考慮する必要があります。これは、PG拡張とのBDRの組み合わせでのみ使用可能な機能です。これらの一部はPG Extendedでのみ利用可能です。他のコミュニティバージョンには既に存在しますが、CAMOと組み合わせてBDRにのみ関連するようになります。

  • synchronous_replication_availability-オプションでasyncにできます ノードの継続を許可することにより可用性を高め、 CAMOパートナーが切断された後にコミットします。デフォルトでは waitの値、ノードは無期限に待機し、 CAMOパートナーが再接続して送信した後にのみコミットする 確認。

  • snapshot_timestamp-の使用をオンにします timestamp-based snapshotsを使用して、使用するタイムスタンプを設定します。

BDR固有の設定

また、設定可能なBDR固有の構成設定もあります。特に明記しない限り、値は任意のユーザがいつでも設定できます。

競合処理

  • bdr.default_conflict_detection-デフォルトの競合検出メソッドを設定します 新しく作成されたテーブルの場合。と同じ値を受け入れます bdr.alter_table_conflict_detection()

グローバルシークエンスパラメータ

  • bdr.default_sequence_kind-デフォルトのsequence kindを設定します。

DDL処理

  • bdr.default_replica_identity-REPLICA IDENTITYのデフォルト値を設定します 新しく作成されたテーブル。 REPLICA IDENTITYは、どの情報が 更新または削除された行を識別するために、ログ先行書き込みに書き込まれます。

    • 受け入れられる値は次のとおりです。

    • -DEFAULT-プライマリキーの列の古い値があれば、それを記録します（これはデフォルトのPostgreSQLの動作です）。 -FULL-行のすべての列の古い値を記録します。 -NOTHING-古い行に関する情報を記録しません。

    • 詳細については、PostgreSQL documentationを参照してください。

    • BDRは、テーブル固有の構成またはbdr.default_replica_identityを介して、テーブルのレプリカアイデンティティがFULLでない限り、PRIMARY KEYまたはUNIQUE制約のないテーブルでUPDATEsおよびDELETEsを複製できません。

    • bdr.default_replica_identityがDEFAULTであり、テーブルに`UNIQUE`制約がある場合、`REPLICA      IDENTITY`として自動的に選択されません。テーブルの作成時に、または上記の文書で説明されているように、後で明示的に設定ニーズがあります。

    • テーブルのレプリカアイデンティティをFULLに設定すると、書き込まれるWALのボリュームと、テーブルのワイヤ上で複製されるデータの量が増加します。

  • bdr.ddl_replication-ノード間でDDLを自動的に複製します（デフォルト 「オン」）。

    • このパラメータは、bdr_superuserロールまたはスーパーユーザロールによってのみ設定できます。

    • bdr.ddl_replication = offを使用してDDLを実行するか、 BDR管理関数を呼び出すと、管理者が介入できるまでレプリケーションが停止する状況が発生する可能性があります。詳細については、the DDL replication chapterを参照してください。

    • bdr.ddl_replicationがoffに設定されると、LOGレベルのログメッセージがPostgreSQLサーバーログに出力されます。さらに、この設定により、キャプチャされたDDLコマンドまたはBDRレプリケーション機能のレプリケーションがスキップされたされるたびに、WARNING-levelメッセージが書き込まれます。

  • bdr.role_replication-ノード間でROLEコマンドを自動的に複製します （デフォルトは「オン」）。このパラメータは、スーパーユーザのみが設定可能です。この設定 bdr.ddl_replicationもオンになっている場合にのみ機能します。

    • 外部メソッドを使用せずにこれをオフにして、保証のノード間でロールを同期させると、管理者が介入するまで複製DDLがレプリケーションを中断する可能性があります。

    • 詳細については、Role manipulation statements in the DDL replication chapterを参照してください。

  • bdr.ddl_locking- DDLのグローバルロックのオペレーションモードを構成します。

    • このパラメータは、bdr_superuserロールまたはスーパーユーザロールによってのみ設定できます。

    • 可能なオプションは次のとおりです。

    • -オフ-DDL操作にグローバルロックを使用しない-オン-すべてのDDL操作にグローバルロックを使用するDDLリレーションのグローバルDMLロックを取得して書き込みを防止する必要があるDDL操作にのみグローバルロックを使用する

    • bdr.ddl_replicationがoffに設定されると、LOGレベルのログメッセージがPostgreSQLサーバーログに出力されます。さらに、この設定が原因でグローバルロック手順がスキップされたされるたびに、WARNINGメッセージが書き込まれます。一部のステートメントでは、2つのWARNINGが発生するのが正常です。1つはDMLロックをスキップし、もう1つはDDLロックをスキップします。

  • bdr.truncate_locking-デフォルトではFalse、この構成オプションは TRUNCATEコマンドのロック動作。 （真の場合）TRUNCATEするかどうかを決定します bdr.ddl_locking設定に従います。

グローバルロック

  • bdr.ddl_locking-上記で説明。

  • bdr.global_lock_max_locks-可能なグローバルロックの最大数 ノードで保持されます（デフォルトは1000）。 Postgresサーバーのスタートにのみ設定できます。

  • bdr.global_lock_timeout-待機の最大許容期間を設定します グローバルロックの場合（デフォルトは10分）。値がゼロの場合、このタイムアウトは無効になります。

  • bdr.global_lock_statement_timeout-の最大許容期間を設定します グローバルロックを保持するステートメント（デフォルトは60分）。 値がゼロの場合、このタイムアウトは無効になります。

  • bdr.global_lock_idle_timeout-最大許容持続時間を設定します グローバルロックを保持しているトランザクションのアイドル時間（デフォルトは10分）。 値がゼロの場合、このタイムアウトは無効になります。

ノード管理

  • bdr.replay_progress_frequency-レプリケーション位置を送信する間隔 残りのクラスターへの情報（デフォルトは1分）。

  • bdr.standby_slot_names-これらのスロットが受信と確認を要求する レプリケーションは他のものよりも先に変更されます。これは主に次の場合に便利です フェイルオーバーのための物理的スタンバイの使用、またはサブスクライブ専用ノードの使用時。

汎用レプリケーション

  • bdr.writers_per_subscription-あたりのデフォルトのライター数 サブスクリプション（ BDRでは、これも変更できます グループの場合はbdr.alter_node_group_config）。

  • bdr.max_writers_per_subscription-ライターの最大数 サブスクリプションごと（上記の設定の上限を設定）。

  • bdr.xact_replication-現在のトランザクションを複製します（デフォルトは「オン」）。

    • これをオフにmakeと、トランザクション全体がローカルのみになります。つまり、トランザクションはBDRおよびその他すべての論理デコードのダウンストリームターゲットによるロジカルデコーディングロジカルデコーディングから可視なくなります。データは、ロジカルスタンバイノードを含む他のノードには転送されません。

    • このパラメータは、bdr_superuserロールまたはスーパーユーザロールによってのみ設定できます。

    • このパラメータは、bdr.permit_unsafe_commands = onを除き、SET LOCALコマンドを使用して現在のトランザクション内でのみ設定できます。

!!! Note * トランザクションレプリケーションが無効になっている場合でも、WALは生成されますが、これらの変更はオリジンでフィルタリングされます。

!!! Warning * bdr.xact_replicationをオフにすると、ノード間でデータの不整合が発生します。ノード間のデータの相違から回復する場合、またはレプリケーションを続行するには単一ノードの変更が必要なレプリケーション状況でのみ使用してください。ご自身のリスクで使用してください。

  • bdr.permit_unsafe_commands-コマンドの安全性チェックを無効にするオプション

    • 一般的な使用には安全でないと見なされます。

    • bdr_superuserまたはPostgreSQLスーパーユーザが必要です。

!!! Warning * 通常安全と見なされないコマンドは、一貫性のない結果を生成するか、レプリケーションを完全に中断する可能性があります。ご自身のリスクで使用してください。

  • bdr.batch_inserts-内の1つのテーブルへの連続挿入数 単一のトランザクションは、そのテーブルの挿入のバッチ処理をオンにします。

    • このオプションを使用すると、挿入のセットではなく、ラージのデータを内部的にCOPYとしてレプリケーションできます。また、ノード結合中の初期データのコピー方法も示します。

  • bdr.maximum_clock_skew

    • これにより、bdr.maximum_clock_skew_actionをトリガーする前に、着信トランザクションコミットタイムスタンプとサブスクライバーの現在の時刻との最大の差と見なされる値が指定されます。

    • これにより、現在再生されているトランザクションのタイムスタンプが、サブスクライバーの現在の時刻と比較して将来にあるかどうかが確認されます。そして、その差がbdr.maximum_clock_skewよりも大きい場合、bdr.maximum_clock_skew_action設定で指定されたアクションを実行します。

デフォルトは-1です。つまり、クロックスキューを無視します（チェックはオフになります）。すべてのサーバーのクロックが同期されているときに0を設定することは有効です。トランザクションを再生しているという事実は、過去にコミットされたことを意味します。

  • bdr.maximum_clock_skew_action

    • これは、bdr.maximum_clock_skewよりも高いクロックスキューが検出された場合に実行するアクションを指定します。

    • このオプションには2つの可能な値があります。

    • -WARN-この事実に関するワーニングを記録します。サーバーログのフラッディングを防ぐため、警告は最大で毎分1回（デフォルト）記録されます。 -WAIT-現在のローカルタイムスタンプが、リモートコミットタイムスタンプからbdr.maximum_clock_skewを引いたものよりも古くなるまで待機します。

bdr.standby_slot_names

このオプションは通常、フェイルオーバー構成で使用され、このBDRノードのフェイルオーバー候補のストリーミング物理的レプリカが、サブスクライバーに可視になる前に保証の変更を受信してフラッシュします。これにより、プロバイダーのスタンバイへのフェイルオーバーでコミットが消滅しないことが保証されます。

名前がカンマ区切りのb_tran_1リストにリストされているレプリケーションスロットは、 BDRノードwalsenderonによって特別に処理されます。

BDRのロジカルレプリケーションwalsenderは、ノードが他のBDR複製クライアントにそれらの変更を送信する前に、すべてのローカル変更が送信され、bdr.standby_slot_namesのレプリケーションスロットにフラッシュされることを保証します。事実上、名前付きスロットのリストと他のすべてのレプリケーションクライアントとの間に同期レプリケーションバリアを提供します。

レプリケーションスロットはbdr.standby_slot_namesにリストされます。論理スロットと物理的スロットの両方が機能しますが、通常は物理的スロットに使用されます。

このセーフガードがないと、サブスクライバーがコミットを受信し、フェイルオーバー候補がまだ受信していないためにフェイルオーバー時にプロバイダーから消失するという2つの異常が発生する可能性があります。

  • 1人以上のサブスクライバの場合、サブスクライバは変更を適用したが、新しい プロバイダーは、受信した変更と競合する新しいトランザクションを実行場合があります。 プロバイダーに関する限り、それは決して起こりませんでした。

および/または

  • 2人以上のサブスクライバの場合、フェイルオーバーの時点で、すべてのサブスクライバが適用されているわけではありません サブスクライバーは現在、一貫性のない、和解できない状態になっています コミットを受信しなかったサブスクライバーには、コミットを取得する方法がないためです。 今。

bdr.standby_slot_namesを設定すると、プロバイダーのフェールオーバー候補のレプリカが維持されない場合、（デザインにより）サブスクライバーがプロバイダーに遅れることになります。したがって、監視は不可欠です。

bdr.standby_slot_namesが役立つ別のユースケースは、サブスクライバーのみを使用する保証です。これにより、サブスクライバーのみのノードが他のBDRノードのいずれよりも先に移動しないようにします。

bdr.standby_slots_min_confirmed

BDRサブスクライバーにデータを送信する前に確認する必要があるbdr.standby_slot_namesの数を制御します。

bdr.writer_input_queue_size

このオプションは、レシーバがライタプロセスにデータを送信するために使用する共有メモリキューのサイズを指定するために使用されます。ライタプロセスが停止した場合や進行が遅い場合、キューがいっぱいになり、レシーバプロセスも停止する可能性があります。したがって、このキューに十分な共有メモリを提供することが重要です。デフォルトは1MBで、最大許容サイズは1GBです。任意のストレージサイズ指定子を使用してGUCを設定できますが、デフォルトはキロバイトです。

bdr.writer_output_queue_size

このオプションは、ライタプロセスからデータを受信するためにレシーバが使用する共有メモリキューのサイズを指定するために使用されます。ライタがラージのデータを送信することは想定されていないため、比較的小さなサイズのキューで十分です。デフォルトは32kB、最大許容サイズは1MBです。任意のストレージサイズ指定子を使用してGUCを設定できますが、デフォルトはiskBです。

bdr.min_worker_backoff_delay

指定されたワーカーがeverybdr.min_worker_backoff_delayミリ秒よりも頻繁に再起動されるのを防ぐことにより、 BDRバックグラウンドワーカの起動を制限します。時間単位のサフィックスがサポートされています。

!!! Note * 現在、この設定はレシーバワーカーにのみ影響します。つまり、主にサブスクリプションがエラーまたは接続障害時に再接続を試みる速度に影響します。

デフォルトは1秒です。遅延は起動から起動までに適用される時間制限であるため、ワーカーの1sのデフォルト値は、1秒あたり最大1回の（再）起動に制限されます。

バックオフ遅延設定が変更され、 PostgreSQL構成が再ロードされると、現在のすべてのバックオフ待機がリセットされます。さらに、bdr.worker_task_reset_backoff_all()ファンクションが提供され、管理者はすべてのバックオフ間隔をすぐにエキスパイアにすることができます。

共有メモリ内の追跡テーブルは、各タイプのワーカーの最終起動時間を記憶するために維持されます。この追跡テーブルは永続的ではありません。これは、クリーンでないバックエンド終了後のクラッシュリカバリ中のソフト再起動など、 PostgreSQLの再起動によってクリアされます。

ビュー`bdr.worker_tasks <monitoring#bdr.worker_tasks>`__を使用してこの状態を検査し、管理者が現在有効なバックオフレート制限を確認できるようにします。

レート制限の目的で、労働者は「タスク」によって分類されます。このキーは、 ワーカーロール、データベースoid、サブスクリプションID、サブスクリプションライタID、拡張ライブラリ名前とファンクション名前、拡張機能が提供するワーカー名前、同期ライターのリモートリレーションIDで構成されます。 NULLは、特定の分類子が適用されない場合に使用されます。たとえば、マネージャワーカーにはサブスクリプションIDがなく、レシーバーにはライタIDがありません。

CRDT

  • bdr.crdt_raw_value-CRDT Data Typesの出力フォーマットを設定します。 デフォルトの出力（この設定が結果の場合）は、現在の 基本CRDTタイプの値（例、crdt_pncounterのbigint）。 onに設定すると、戻り値は CRDT値。例、マルチプルのノードからの状態を含めることができます。

最大準備トランザクション

  • max_prepared_transactions-対処するために十分に高く設定する必要があります 同時準備トランザクションの最大数 明示的な2フェーズコミット、CAMOまたはEagerによるクラスター トランザクション。制限を超えると、ノードが ローカルの二相コミットまたはCAMOトランザクション クラスター上の熱心なトランザクション。 Postgresサーバーのスタートにのみ設定できます。 （EDB Postgres Extended）

熱心な複製

  • bdr.commit_scope-コミットスコープをglobalに設定すると有効になります （デフォルト）。

  • bdr.global_commit_timeout-グローバルの両方のステージのタイムアウト 二相コミット（デフォルトは60秒）およびCAMOで保護されたトランザクション CAMOを待機する時間の制限として、コミットフェーズで パートナー。

!!! Note * これは、 EDB Postgres Extendedでのみ利用可能です。

最大1回コミットする

  • bdr.enable_camo-CAMO機能を有効にして制御するために使用されます。 デフォルトはoffです。 CAMOはトランザクションごとにオンに切り替えることができます これをremote_write、remote_commit_asyncに設定する、または remote_commit_flush。下位互換性のために、値 on、true、および1は、最も安全なremote_commit_flushモードを設定します。 falseまたは0もCAMOを無効にします。

  • bdr.standby_dsn-接続のマニュアルオーバーライドを許可します 以来変更された場合にCAMOパートナーに到達するための文字列（DSN） ローカルノードのクラッシュ。通常は設定しないでください。 Postgresサーバーのスタートにのみ設定できます。

  • bdr.camo_local_mode_delay-で適用されるコミット遅延 通常発生するオーバーヘッドをエミュレートCAMOのローカルモード CAMOパートナーはトランザクションを確認する必要があります。デフォルトは5ミリ秒です。 0に設定すると、この機能が無効になります。

  • bdr.camo_enable_client_warnings-アクティビティが CAMOプロパティができないデータベースで実行 保証されています。これはデフォルトで有効になっています。十分な情報に基づいたユーザーが選択できます これを無効にして、ログに記録される警告の量を減らします。

!!! Note * これは、 EDB Postgres Extendedでのみ利用可能です。

トランザクションストリーミング

  • bdr.default_streaming_mode-トランザクションストリーミングの制御に使用 加入者ノード。許可される値は、off、writer、file、autoです。 デフォルトはautoです。 offに設定されている場合、サブスクライバーは要求しません トランザクションストリーミング。他の許容値のいずれかに設定されている場合、 サブスクライバーがトランザクションストリーミングを要求し、パブリッシャーが提供します サポートしている場合はこれ（ PostgreSQLを使用したBDR 4.0からサポートを利用できます） 14、 EDB Postgres Extended 13およびEPAS 14）およびグループレベルで構成されます。のために 詳細については、Transaction Streamingを参照してください。

タイムスタンプベースのスナップショット

  • bdr.timestamp_snapshot_keep-の有効なスナップショットを保持する期間 タイムスタンプベースのsnapshotの使用（デフォルト0、過去のスナップショットを保持しないことを意味します）。 上記のsnapshot_timestampも参照してください。 （EDB Postgres Extended）

監視とログ

  • bdr.debug_level- BDRが書き込みに使用するログレベルを定義します デバッグメッセージ。デフォルト値はdebug2です。見たいなら 詳細なBDRデバッグ出力、bdr.debug_level = 'log'を設定します。

  • bdr.trace_level-上記と同様に、これはログレベルを定義します BDRトレースメッセージに使用します。のすべてのノードでトレースを有効にする BDRクラスターは、 EDBサポートが問題を診断するのにヘルプます。 Postgresサーバーのスタートにのみ設定できます。

!!! Warning * bdr.debug_levelまたはbdr.trace_levelを> = log_min_messagesの値に設定すると、非常にラージのログ出力が生成される可能性があるため、ディスクスペースの枯渇を防ぐためにログフィルタリング、アーカイブ、ローテーションの計画が整っていない限り、稼動環境で長期間有効にしないでください。

  • bdr.track_subscription_apply-の適用統計を追跡 各サブスクリプション。

  • bdr.track_relation_apply-それぞれの適用統計を追跡 リレーションの

  • bdr.track_apply_lock_timing-追跡時の追跡ロックタイミング リレーションの統計。

内部

  • bdr.raft_keep_min_entries-保持するエントリの最小数 ログ圧縮を行うときにログをラフティングする（デフォルトは100）。値0は無効になります ログ圧縮。 警告：ログの圧縮が無効になっている場合、ログは 永遠にサイズが大きくなります。 Postgresサーバーのスタートにのみ設定できます。

  • bdr.raft_response_timeout-ネットワーク障害をアカウントして、 実装されたラフトコンセンサスプロトコルは、 一定の時間。このタイムアウトのデフォルトは30秒です。

  • bdr.raft_log_min_apply_duration-ステートマシンを移動するには 転送すると、Raftは内部ログにエントリを追加します。通常時 オペレーション、追加には数ミリ秒しかかかりません。これは その追加アクションの期間の上限しきい値。 INFOメッセージが記録されます。これは、 実際の問題。このパラメータのデフォルト値は3000ミリ秒です。

  • bdr.raft_log_min_message_duration-コンセンサスリクエストをログするタイミング。 ログコンセンサスリクエストの往復時間を測定し、 時間がこのパラメータを超える場合のINFOメッセージ。デフォルト値 このパラメータの最大値は5000ミリ秒です。

  • bdr.raft_group_max_connections-接続の最大数 PostgresサーバーのすべてのBDRグループ全体。これらの接続は運ぶ グループのノード間のbdrコンセンサスリクエスト。これのデフォルト値 パラメータは100接続です。 Postgresサーバーのスタートにのみ設定できます。

  • bdr.backwards_compatibility-バージョンを指定します 下位互換性があり、同じ数値フォーマットで bdr.bdr_version_num、たとえば30618。の正確な動作を可能にします 以前のBDRバージョン、これが一般に望ましくない効果をもたらす場合でも。 デフォルトは現在のBDRバージョンです。これはリリースから変更されるため リリースするには、構成内で明示的に使用しないことをお勧めします 値が現在のバージョンと異なる場合を除き、ファイル。

  • bdr.track_replication_estimates-レプリケーションの見積もりを用語で追跡する 同等なの適用率とキャッチアップ間隔。この情報は CAMOなどのプロトコルで使用して、 同等なノード。このパラメータはデフォルトで有効になっています。 （EDB Postgres Extended）

  • bdr.lag_tracker_apply_rate_weight-同等なからの遅れをモニタします ローカルノードからWALを適用するという点で、移動を計算します 遅延追跡の適用率の平均。このパラメータは、 この移動平均における新しい計算値の寄与度 計算。デフォルト値は0.1です。 （EDB Postgres Extended）