レプリケーション/送信元サーバー

max_replication_slots

max_slot_wal_keep_size

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_segments

wal_sender_timeout

max_replication_slots

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 センダーはすべてアクティブになり、以下を行います。
  1. WAL 内のすべての新しいレコードをデコードします。
  2. 関係のないログ レコードを除外します。
  3. それぞれに関連するデータをレプリケートします。
• アイドル状態であれば、その数がいくつあっても関係ないという点で、WAL センダーは接続と似ています。 ただし、アクティブな場合は、同じリソースをめぐって競合するだけになり、パフォーマンスが非常に悪くなる可能性があります。 これは、論理レプリケーションを使用するセンダーに特に当てはまります。論理デコードは CPU にかなりの負荷がかかるためです。 1 つのテーブルに影響する操作をレプリケートするだけであり、先行書き込みログ内の全データのごく一部にすぎない場合でも、各ワーカーは WAL 全体をデコードする必要があります。 物理レプリケーションの場合、WAL センダーはそれほど集中的に CPU を消費せず、最初にネットワーク帯域幅によって制限される傾向があるため、それほど重要ではありません。
• そのため、一般には、WAL センダーを仮想コアの数よりも多くしないことをお勧めします。
• レプリケーション接続の将来的な増加や一時的な急増に対応するために、WAL センダーをいくつか追加できる余地を追加することをお勧めします。 次の 2 つの例は、よりわかりやすく説明したものです。
  • 8 個の仮想コア、無効な HA、2 個の読み取りレプリカ、3 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (0) + 読み取りレプリカ用の物理スロット (2) + 論理スロット (3) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (1) の合計として max_wal_senders を = 6 に構成することをお勧めします。
  • 16 個の仮想コア、有効な HA、4 個の読み取りレプリカ、5 個の論理レプリケーション スロットを持つサーバーの場合、HA 用の物理スロット (2) + 読み取りレプリカ用の物理スロット (4) + 論理スロット (5) + 使用できる仮想コアを考慮した将来的な成長のための追加分 (2) の合計として max_wal_senders を = 13 に構成することをお勧めします。
• それでも、このパラメーターに許容される最大値がニーズに対して低すぎると思われる場合は、お問い合わせください。その際には、お客様のシナリオを詳しく記載し、シナリオを適切に実行するために必要な最小値をどのように想定しているかを説明してください。

track_commit_timestamp

wal_keep_segments

wal_sender_timeout