max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に定義されたレプリケーション スロットの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 WAL がディスク上でこれほどのスペースを占有すると、レプリケーションスロットは失敗としてマークされ、セグメントは削除または再利用のために解放されます。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に定義されたレプリケーション スロットの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 WAL がディスク上でこれほどのスペースを占有すると、レプリケーションスロットは失敗としてマークされ、セグメントは削除または再利用のために解放されます。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_slot_wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
レプリケーション スロットで予約できる WAL の最大サイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
-1 |
| 使用できる値 |
-1 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_size
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持される WAL ファイルのサイズを設定します。 |
| データの種類 |
整数 |
| 既定値 |
400 |
| 使用できる値 |
400 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
wal_keep_size |
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_segments
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持されている WAL ファイルの数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
25 |
| 使用できる値 |
25 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
|
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots (最大レプリケーションスロット)
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
サーバーがサポートできるレプリケーション スロットの最大数を指定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
2-262143 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_replication_slots |
Azure 固有の注
max_replication_slots パラメーターの既定値は 10 です。 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの max_replication_slots が必要です。
高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_replication_slots を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_replication_slotが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
max_wal_senders
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
同時に実行される WAL 送信側プロセスの最大数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
10 |
| 使用できる値 |
5-100 |
| パラメーターのタイプ |
静的 |
| Documentation |
max_wal_senders |
Azure 固有の注
Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに設定される max_wal_senders サーバー パラメーターの既定値を、 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication以下に減らしてはなりません。
多数のテーブルの論理レプリケーションに対応するために、 max_wal_senders をはるかに高い値に増やす必要があることを検討するときは、次の重要な点に留意してください。
- 多数のテーブルを論理的にレプリケートする場合、必ずしも多数の WAL 送信者が必要であるとは限りません。
- テーブルまたはテーブルのグループごとに個別の WAL 送信者が必要な唯一の理由は、これらのテーブルまたはグループごとに個別のサブスクリプションが必要な場合です。
- 物理および論理レプリケーションに使用されている WAL 送信者の数に関係なく、バックエンドが先行書き込みログに何かを書き込むたびに、それらはすべて一度にアクティブになります。 その場合、論理レプリケーションを実行するように割り当てられている WAL 送信者はすべて、次の状態に復帰します。
- WAL 内のすべての新しいレコードをデコードします。
- 関心のないログ レコードを除外する
- それぞれのデータに関連するデータをレプリケートします。
- アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースを競うだけで、パフォーマンスが非常に悪い結果になる可能性があります。 論理デコードは CPU の負荷が高いため、これは論理レプリケーションを使用する送信者に特に当てはまります。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL 送信者は CPU をそれほど集中的に消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
- そのため、一般に、仮想コアよりも多くの WAL 送信者を持たない方が良いです。
- レプリケーション接続の将来の増加や一時的な急増に対応するために、いくつかの追加の WAL 送信者の余地を追加することをお勧めします。 次の 2 つの例は、より適切に説明するのに役立ちます。
- 8 個の仮想コアを持ち、HA が無効になっており、2 つの読み取りレプリカと3 つの論理レプリケーション スロットがあるサーバーの場合、使用可能な仮想コア (1) を考慮して、将来の拡張のための追加分を含めた物理スロットの合計として、HA の物理スロット (0) + 読み取りレプリカの物理スロット (2) + 論理スロット (3) の合計を
max_wal_senders として を構成できます。
- 16 個の仮想コアを持ち、HA が有効で、4 つの読み取りレプリカと 5 つの論理レプリケーションスロットがあるサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) を足した合計に、今後の拡張用のスロットを加え、使用可能な仮想コアを考慮して
max_wal_senders を構成できます。このとき、使用可能な仮想コア (2) = となります。
- 高可用性を有効にする場合は、高可用性を適切に機能させるために少なくとも 4 つの
max_wal_senders が必要です。 高可用性が有効になっているサーバーに加えて、5 つの読み取りレプリカと 12 個の論理レプリケーション スロットがある場合は、 max_wal_senders を 21 に構成できます。 これは、各読み取りレプリカと各論理レプリケーション スロットに 1 つの max_wal_sendersが必要であるためです。 そのため、合計で 1 (スロット) * 5 (リードレプリカ) + 12 (論理レプリケーションスロット) + 4 (高可用性が適切に機能するために) = 21 が必要です。
- このパラメーターで許容される最大値がニーズに対して低すぎると考えられる場合は、 お問い合わせの上、シナリオについて詳しく説明し、シナリオを適切に実行するために必要な最小値として何を考慮するかについて説明してください。
コミットタイムスタンプ追跡
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
トランザクションのコミット時間を収集します。 |
| データの種類 |
ブーリアン |
| 既定値 |
off |
| 使用できる値 |
on,off |
| パラメーターのタイプ |
静的 |
| Documentation |
トラックコミットタイムスタンプ |
wal_keep_segments
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
スタンバイ サーバーに保持されている WAL ファイルの数を設定します。 |
| データの種類 |
整数 |
| 既定値 |
25 |
| 使用できる値 |
25 |
| パラメーターのタイプ |
読み取り専用 |
| Documentation |
|
wal_sender_timeout
| 特性 |
価値 |
| カテゴリ |
レプリケーション/送信元サーバー |
| Description |
WAL レプリケーションを待機する最大時間を設定します。 |
| データの種類 |
整数 |
| 既定値 |
60000 |
| 使用できる値 |
0-2147483647 |
| パラメーターのタイプ |
dynamic |
| Documentation |
wal_sender_timeout |