PostgreSQL configuration for BDR¶
いくつかのPostgreSQL構成パラメーターはBDRノードに影響します。これらのパラメーターは各ノードで個別に設定できますが、一般的にはお勧めしません。
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はレプリケーションとメンテナンスのタスクにバックグラウンドワーカーを使用するため、正常に動作するには十分なワーカースロットが必要です。各データベースのBDR最小BDR数の式は次のとおりです。 BDRグループ内のピアノードごとに有効になっているライターごとにBDRグループからノードを削除するときに、一時的により多くのワーカープロセスが必要になる場合があります。max_wal_senders—すべてのピアノードごとに2つ必要です。max_replication_slots—max_wal_sendersと同じ。wal_sender_timeoutおよびwal_receiver_timeout—ノードがCAMOパートナーを切断または再接続と見なす速度を決定します。詳細は CAMO failure scenarios を参照してください。
N個のピアノードを持つグループの通常の実行では、 BDRにはN個のスロットとWAL送信者が必要です。同期中、 BDRは別のN - 1個のスロットとWAL送信者を一時的に使用するため、この時折のピーク需要に合わせてパラメーターを十分に高く設定してください。
パラレル適用をオンにすると、スロット数を式*ライターからNスロットに増やす必要があります。これは、
max_replication_slots
もレプリケーション起点の最大数を設定し、パラレル適用の一部の機能はライタごとに追加のオリジンを使用するためです。
デコードワーカー が有効になっている場合、このプロセスにはBDRグループごとに1つの追加のレプリケーションスロットが必要です。
これらのパラメーターを変更するには、ローカルノードを再起動する必要があります。max_worker_processes
、max_wal_senders 、max_replication_slots 。
アプリケーションでこれらのパラメーターを設定することもできます。詳細は Durability and performance options を参照してください。
synchronous_commit— BDRレプリケーションの耐久性とパフォーマンスに影響します。物理レプリケーション と同様に。
synchronous_standby_names—上記と同じ。
BDR固有の設定¶
BDR固有の構成設定を設定することもできます。特に断りのない限り、値はいつでも設定できます。
競合処理¶
bdr.default_conflict_detection—新しく作成されたテーブルのデフォルトの競合検出方法を設定します。bdr.alter_table_conflict_detection() と同じ値を受け入れます。
グローバルシーケンスパラメーター¶
bdr.default_sequence_kind—デフォルトの sequence kind を設定します。デフォルト値はdistributedで、これは、snowflakeidがint8シーケンス（つまりbigserial）およびint4（つまりserial）およびint2シーケンスに使用されることを意味します。
DDL処理¶
bdr.default_replica_identity—新しく作成されたテーブルのREPLICA IDENTITYのデフォルト値を設定します。REPLICA IDENTITYは、更新または削除された行を識別するためにログ先行書き込みに書き込まれる情報を定義します。
受け入れられる値は次のとおりです。
DEFAULT—主キーの列の古い値を記録します（これはPostgreSQLのデフォルトの動作です）。 -FULL—行のすべての列の古い値を記録します。 -NOTHING—古い行に関する情報を記録しません。
詳細については、 PostgreSQL documentation を参照してください。
BDRは、 PRIMARY KEY またはUNIQUE
制約のないテーブルでUPDATE およびDELETE
操作を複製できません。例外は、テーブル固有の構成またはbdr.default_replica_identity
によって、テーブルのレプリカIDがFULL である場合です。
bdr.default_replica_identity がDEFAULT
であり、テーブルにUNIQUE
制約がある場合、自動的にREPLICA IDENTITY
として選択されません。上記のように、テーブルの作成時または作成後に明示的に設定する必要があります。
テーブルのレプリカIDを FULL
に設定すると、書き込まれるWALの量とテーブルのネットワークで複製されるデータの量が増加します。
bdr.ddl_replication—ノード間でDDLを自動的に複製します（デフォルトはon）。
このパラメーターは、 bdr_superuserまたはスーパーユーザーロールのみが設定できます。
bdr.ddl_replication = off を使用してDDLを実行するか、
BDR管理機能を呼び出すと、管理者が介入するまでレプリケーションが停止する状況が発生する可能性があります。詳細は DMLおよびDDLレプリケーション を参照してください。
bdr.ddl_replication がoff に設定されている場合は常に、 LOG
レベルのログメッセージがPostgreSQLサーバーログに出力されます。さらに、この設定が原因でキャプチャされたDDLコマンドまたはBDRレプリケーションファンクションのレプリケーションがスキップされるたびに、
WARNING-level メッセージが書き込まれます。
bdr.role_replication—ノード間でROLEコマンドを自動的に複製します（デフォルトはon）。このパラメーターを設定できるのはスーパーユーザーのみです。この設定は、bdr.ddl_replicationがオンになっている場合にのみ機能します。
外部メソッドを使用せずにこれをオフにして、すべてのノードでロールが同期されていることを確認すると、管理者が介入するまでレプリケートされたDDLがレプリケーションを中断する場合があります。
詳細は ロール操作ステートメント を参照してください。
bdr.ddl_locking— DDLのグローバルロックの動作モードを構成します。
このパラメーターは、 bdr_superuserまたはスーパーユーザーロールのみが設定できます。
可能なオプションは次のとおりです。
オフDDL操作にグローバルロックを使用しないでください。 - on -すべてのDDL操作にグローバルロックを使用します。 - dmlグローバルロックは、リレーションのグローバルDMLロックを取得して書き込みを防止する必要があるDDL操作にのみ使用します。
bdr.ddl_replication がoff に設定されている場合は常に、 LOG
レベルのログメッセージがPostgreSQLサーバーログに出力されます。さらに、この設定が原因でグローバルロック手順がスキップされるたびに、
WARNING メッセージが書き込まれます。一部のステートメントで2つの
WARNING
メッセージが表示されるのは正常です。1つはDMLロックをスキップするため、もう1つはDDLロックをスキップするためです。
bdr.truncate_locking—デフォルトではFalseです。この構成オプションはTRUNCATEコマンドのロック動作を設定します。 TRUNCATEが（trueの場合）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.predictive_checks—予測チェックのログレベル（現在、グローバルロックでのみ使用されます）。DEBUG、LOG、WARNING（デフォルト）、またはERRORです。予測チェックは、特定の操作を実行するときに予想されるクラスターの状態の早期の検証です。タイムアウトを待つのではなく、早期に失敗するための操作に使用できます。グローバルロックの用語では、 BDRは、十分なノードが接続されており、グローバルロックに必要なクォーラムを取得するための合理的な遅延制限があることを確認します。
ノード管理¶
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—現在のトランザクションを複製します（デフォルトはon）。
これをオフにすると、BDR全体がローカルのみになります。データは、ロジカルスタンバイノードを含む他のノードに転送されません。
このパラメーターは、 bdr_superuserまたはスーパーユーザーロールのみが設定できます。
このパラメーターは、 SET LOCAL
コマンドを使用して現在のトランザクション内でのみ設定できます。
注釈
トランザクションレプリケーションを無効にしても、WALは生成されますが、これらの変更はオリジンでフィルター処理されます。
警告
bdr.xact_replication をオフにすると、ノード間のデータの一貫性が失われます。ノード間のデータの相違から回復する場合、またはレプリケーションを続行するために単一ノードでの変更が必要なレプリケーションの状況でのみ使用します。ご自身の責任で使用してください。
bdr.permit_unsafe_commands—一般的な使用には安全でないと考えられるコマンドの安全性チェックをオーバーライドするオプション。
bdr_superuser またはPostgreSQLスーパーユーザーが必要です。
警告
通常は安全と見なされないコマンドにより、一貫性のない結果が生成されるか、レプリケーションが完全に中断される可能性があります。ご自身の責任で使用してください。
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分に1回（デフォルト）ログに記録されます。 -WAIT—現在のローカルタイムスタンプが、リモートコミットタイムスタンプからbdr.maximum_clock_skewを引いたものより古くなくなるまで待ちます。bdr.accept_connections— BDRへの接続を有効または無効にするオプション。デフォルトはonです。
bdr_superuser またはPostgreSQLスーパーユーザーが必要です。
bdr.standby_slot_names¶
このオプションは通常、フェールオーバー構成で使用され、このBDRノードのフェールオーバー候補のストリーミング物理レプリカがサブスクライバーに表示される前にすべての変更を受信してフラッシュします。これにより、プロバイダーのスタンバイへのフェールオーバー時にコミットが消えないことが保証されます。
コンマ区切りのbdr.standby_slot_names
リストに名前がリストされているレプリケーションスロットは、
BDRノードのwalsenderによって特別に扱われます。
BDRの論理レプリケーションウォルセンダーは、ノードが他の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
を少なくとも1に設定して、すべての通常のBDRピアノードの論理スロットをリストします。
bdr.standby_slots_min_confirmed¶
BDRサブスクライバーにデータを送信する前に確認する必要があるbdr.standby_slot_names
の数を制御します。
bdr.writer_input_queue_size¶
このオプションは、レシーバーがライタプロセスにデータを送信するために使用する共有メモリーキューのサイズを指定します。ライタプロセスが停止しているか、進行が遅い場合、キューがいっぱいになり、受信プロセスも停止する可能性があります。したがって、このキューに十分な共有メモリを提供することが重要です。デフォルトは1MBで、許可される最大サイズは1GBです。 GUCの設定には任意のストレージサイズ指定子を使用できますが、デフォルトはKBです。
bdr.writer_output_queue_size¶
このオプションは、レシーバーがライタプロセスからデータを受信するために使用する共有メモリーキューのサイズを指定します。ライタは大量のデータを送信することは想定されていないため、比較的小さなサイズのキューで十分です。デフォルトは32 KBで、許可される最大サイズは1 MBです。 GUCの設定には任意のストレージサイズ指定子を使用できますが、デフォルトはKBです。
bdr.min_worker_backoff_delay¶
レート制限BDRバックグラウンドワーカーの起動は、特定のワーカーがbdr.min_worker_backoff_delay
ミリ秒ごとよりも頻繁に再起動されないようにします。エラーが繰り返されると、最大bdr.max_worker_backoff_delay
までジッターが追加されると、バックオフが指数関数的に増加します。
時間単位のサフィックスがサポートされています。
注釈
現在、この設定はレシーバーワーカーにのみ影響します。つまり、主にサブスクリプションがエラーまたは接続エラー時に再接続を試行する速度に影響します。
bdr.min_worker_backoff_delay のデフォルトは1秒です。
bdr.max_worker_backoff_delay の場合は1分です。
バックオフ遅延設定が変更され、PostgreSQL構成がリロードされると、現在のすべてのバックオフがリセットを待機します。さらに、管理者がすべてのバックオフ間隔を強制的に終了できるように、
bdr.worker_task_reset_backoff_all()
ファンクションが提供されています。
各タイプのワーカーの最終起動時刻を記憶するために、共有メモリ内の追跡テーブルが維持されます。この追跡テーブルは永続的ではありません。これは、クリーンでないバックエンドが終了した後のクラッシュ復旧中のソフトリスタートを含む、PostgreSQLの再起動によってクリアされます。
ビュー :ref:``bdr.worker_tasks`<bdr.worker_tasks>` を使用してこの状態を検査できるため、管理者は現在有効なバックオフレート制限を確認できます。
レート制限の目的で、ワーカーはタスクごとに分類されます。このキーは、ワーカーロール、データベース
OID、サブスクリプション
ID、サブスクリプションライタID、拡張機能ライブラリの名前と関数名、拡張機能が提供するワーカー名、および同期ライターのリモート
リレーションシップ ID で構成されます。 NULL
は、特定の分類子が適用されない場合に使用されます。たとえば、マネージャーのワーカーにはサブスクリプションIDがなく、レシーバーにはライタIDがありません。
CRDT¶
bdr.crdt_raw_value—CRDTデータ型を使用した列の競合の処理 の出力フォーマットを設定します。デフォルトの出力（この設定が
off
の場合）は、ベースのCRDTタイプ（たとえば、
crdt_pncounterのbigint）のみを返します。onに設定すると、戻り値はCRDT値の完全な表現を表します。たとえば、複数のノードからの状態を含めることができます。
準備されたトランザクションの最大数¶
max_prepared_transactions—明示的な2フェーズコミット、 CAMO、またはEagerトランザクションによるクラスター全体の同時準備トランザクションの最大数に対処するには、十分に高く設定する必要があります。制限を超えると、ノードでローカル2フェーズコミットまたはCAMOトランザクションを実行できず、クラスター上のすべてのEagerトランザクションが防止されます。これは、Postgresサーバーの起動時にのみ設定できます。
Eager Replication¶
bdr.commit_scope—コミットスコープをglobalに設定すると、eager all node replication （デフォルトは
local）が有効になります。
bdr.global_commit_timeout—グローバル2フェーズコミットの両方のステージ（デフォルトは60秒）と、 CAMOパートナーを待機する時間の制限としての、コミットフェーズでのCAMOで保護されたトランザクションのタイムアウト。
Commit At Most Once¶
bdr.enable_camo— CAMO機能を有効にして制御するために使用されます。デフォルトはoffです。これをremote_write、remote_commit_async、またはremote_commit_flushに設定することで、 CAMOをトランザクションごとにオンにできます。下位互換性のために、値on、true、および1は最も安全なremote_commit_flushモードを設定しますが、falseまたは0もCAMOを無効にします。bdr.standby_dsn—ローカルノードのクラッシュ後に変更された場合、接続文字列（DSN）の手動オーバーライドがCAMOパートナーに到達することを許可します。通常は設定されていません。 Postgresサーバーの起動時にのみ設定できます。bdr.camo_local_mode_delay—トランザクションを確認する必要があるCAMOパートナーで通常発生するオーバーヘッドをエミュレートするためにCAMOのローカルモードで適用されるコミット遅延。デフォルトは5ミリ秒です。この機能を無効にするには0に設定します。bdr.camo_enable_client_warnings— CAMOプロパティを保証できないデータベースでアクティビティが実行された場合に警告を発します。これはデフォルトで有効になっています。十分な情報を得たユーザーは、これを無効にして、ログに記録される警告の量を減らすことができます。synchronous_replication_availability— CAMOパートナーが切断された後にノードが続行してコミットできるようにすることにより、可用性を高めるためにオプションでasyncにすることができます。デフォルト値のwaitでは、ノードは無期限に待機し、 CAMOパートナーが再接続して確認を送信した後にのみコミットします。
トランザクションストリーミング¶
bdr.default_streaming_mode—サブスクライバーノードによるトランザクションストリーミングを制御するために使用されます。許可される値は次のとおりです。off、writer、file、およびauto。デフォルトはautoです。offに設定されている場合、サブスクライバーはトランザクションストリーミングを要求しません。他のいずれかの値に設定されている場合、サブスクライバーはトランザクションストリーミングを要求し、パブリッシャーはそれらをサポートしており、グループレベルで構成されている場合に提供します。詳細については、トランザクションストリーミング を参照してください。
ラグ制御¶
bdr.lag_control_max_commit_delay—許容できる最大許容ポストコミット遅延（ミリ秒単位）。bdr.lag_control_max_lag_size—許容できる最大ラグサイズ（キロバイト）。bdr.lag_control_max_lag_time—許容できる最大遅延時間（ミリ秒）。bdr.lag_control_min_conforming_nodes—許容可能なラグメジャーを下回るために必要なノードの最小数。bdr.lag_control_commit_delay_adjust—コミット遅延のマイクロ調整は、最大コミット遅延時間の割合として測定されます。デフォルト値の0.01%では、最大コミット遅延に到達するには正味100回のインクリメントが必要です。bdr.lag_control_sample_interval—遅延サンプルとコミット遅延のマイクロ調整間の最小時間（ミリ秒）。bdr.lag_control_commit_delay_start—許容可能なラグメジャーの割合として表される、コミット遅延の増分の適用が開始されるラグのしきい値。デフォルト値の1.0%では、許容可能なラグ測定値を超えるまでコミット遅延のインクリメントは開始されません。
より小さい割合を設定することで、より早く「ラグ曲線を曲げ」て、許容可能なラグメジャーで漸近することにより、違反を防止できる場合があります。
タイムスタンプベースのスナップショット¶
snapshot_timestamp—タイムスタンプベースのスナップショット の使用をオンにし、使用するタイムスタンプを設定します。
bdr.timestamp_snapshot_keep—タイムスタンプベースのスナップショットで使用する有効なスナップショットを保持する時間（デフォルトは0、つまり過去のスナップショットを保持しません）。
モニタリングとロギング¶
bdr.debug_level— BDRがデバッグメッセージを書き込むために使用するログレベルを定義します。デフォルト値はdebug2です。詳細なBDRデバッグ出力を見たい場合はbdr.debug_level = 'log'を設定してください。bdr.trace_level—上記と同様に、これはBDRトレースメッセージに使用するログレベルを定義します。 EDB Postgres分散クラスターのすべてのノードでトレースを有効にすると、EDBサポートが問題を診断するのに役立つ場合があります。これは、Postgresサーバーの起動時にのみ設定できます。
警告
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 —ログコンパクションを行うときにRaftログに保持するエントリーの最小数（デフォルト100）。値0はログの圧縮を無効にします。これは、Postgresサーバーの起動時にのみ設定できます。 .. Warning ::
ログの圧縮が無効になっている場合、ログのサイズは永久に大きくなります。
bdr.raft_response_timeout—ネットワーク障害に対応するために、実装されたRaftコンセンサスプロトコルは一定の時間が経過するとリクエストをタイムアウトします。このタイムアウトのデフォルトは30秒です。bdr.raft_log_min_apply_duration—ステートマシンを前進させるために、Raftはエントリをその内部ログに追加します。通常の操作中、追加には数ミリ秒しかかかりません。これにより、その追加アクションの期間に上限しきい値が設定され、それを超えるとINFOメッセージがログに記録されます。これは問題を示している可能性があります。このパラメーターのデフォルト値は3000ミリ秒です。bdr.raft_log_min_message_duration—コンセンサスリクエストをログに記録する場合。 bdrコンセンサスリクエストのラウンドトリップ時間を測定し、時間がこのパラメーターを超える場合は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のようなプロトコルは、この情報を使用してピアノードの準備状況を推定できます。このパラメーターはデフォルトで有効になっています。bdr.lag_tracker_apply_rate_weight—ローカルノードからのWALの適用に関してピアノードがどの程度遅れているかを監視し、ラグトラッキングの適用率の移動平均を計算します。このパラメーターは、新しい計算値がこの移動平均計算にどの程度寄与するかを指定します。デフォルト値は0.1です。
