複寫/傳送伺服器

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時定義的複寫插槽數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。 複製插槽將被標記為失敗，如果磁碟上的 WAL 佔用了這麼多空間，則會釋放區段以進行刪除或回收。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時定義的複寫插槽數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。 複製插槽將被標記為失敗，如果磁碟上的 WAL 佔用了這麼多空間，則會釋放區段以進行刪除或回收。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_slot_wal_keep_size（最大插槽WAL保留大小）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定可由複寫插槽保留的 WAL 最大大小。
數據類型	整數
預設值	-1
允許的值	-1
參數類型	唯讀
文件資料	max_slot_wal_keep_size

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_size

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定待命伺服器所需保留 WAL 檔案的大小。
數據類型	整數
預設值	400
允許的值	400
參數類型	唯讀
文件資料	wal_keep_size

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_segments

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定要針對待命伺服器保留的 WAL 檔案數目。
數據類型	整數
預設值	25
允許的值	25
參數類型	唯讀
文件資料

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout

max_replication_slots（最大複製插槽）

Attribute	價值觀
類別	複寫/傳送伺服器
Description	指定伺服器可支援的複寫位置數目上限。
數據類型	整數
預設值	10
允許的值	2-262143
參數類型	靜態
文件資料	max_replication_slots

Azure 特定注意事項

參數的 max_replication_slots 預設值為 10。 如果您啟用高可用性，則至少需要 4 個 max_replication_slots 才能使高可用性正常運作。

對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_replication_slots 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_replication_slot。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。

max_wal_senders

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定同時執行 WAL 傳送者處理序的數目上限。
數據類型	整數
預設值	10
允許的值	5-100
參數類型	靜態
文件資料	max_wal_senders

Azure 特定注意事項

當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，所設定的 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 資源的消耗相當高。 每個工作者都必須解析整個 WAL，即使它只複製影響單一資料表的操作，而這僅僅代表預寫日誌中所有資料的一小部分。 對於實體複製來說，這並不那麼重要，因為 WAL 發送方不會如此密集地消耗 CPU，而且它們往往首先受到網路頻寬的限制。
• 因此，一般來說，最好不要有比 vCore 多的 WAL 發送者。
• 為未來增長或複寫連線的暫時性激增預留空間，增加幾個額外的 WAL 發送是個好做法。 以下兩個例子可能有助於更好地說明這一點。
  • 對於具有 8 個虛擬核心、已停用 HA、2 個僅供讀取複本和 3 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體插槽總和 （0） + 僅供讀取複本的實體插槽 （2） + 邏輯插槽 （3） + 一些額外的未來成長，考量可用的虛擬核心 （1） = 6。
  • 對於具有 16 個虛擬核心、已啟用 HA、4 個僅供讀取複本和 5 個邏輯複寫位置的伺服器，您可能會想要設定 max_wal_senders 為 HA 的實體位置總和 （2） + 僅供讀取複本的實體位置 （4） + 邏輯位置 （5） + 一些額外的未來成長，考量可用的虛擬核心 （2） = 13。
  • 如果您啟用高可用性，則至少需要 4 個 max_wal_senders 才能使高可用性正常運作。 對於已啟用高可用性的伺服器，加上 5 個讀取複本和 12 個邏輯複寫插槽，您可能需要將 max_wal_senders 設定為 21。 這是因為每個讀取副本和每個邏輯複寫插槽都需要一個 max_wal_senders。 因此，總共需要 1（插槽）* 5（讀取副本）+ 12（邏輯複寫插槽）+ 4（確保高可用性的正常運作）= 21。
• 如果您仍然認為此參數允許的最大值對於您的需求來說太低，請 聯絡我們，詳細描述您的案例，並說明您認為案例正確執行所需的最小可接受值是多少。

追蹤提交時間戳

Attribute	價值觀
類別	複寫/傳送伺服器
Description	收集交易認可時間。
數據類型	boolean
預設值	off
允許的值	on,off
參數類型	靜態
文件資料	track_commit_timestamp

wal_keep_segments

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定要針對待命伺服器保留的 WAL 檔案數目。
數據類型	整數
預設值	25
允許的值	25
參數類型	唯讀
文件資料

wal_sender_timeout

Attribute	價值觀
類別	複寫/傳送伺服器
Description	設定等候 WAL 複寫的時間上限。
數據類型	整數
預設值	60000
允許的值	0-2147483647
參數類型	dynamic
文件資料	wal_sender_timeout