複寫/傳送伺服器
本文內容
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_slot_wal_keep_size
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_size
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案大小。
資料類型
整數
預設值
400
允許的值
400
參數類型
唯讀
文件集
wal_keep_size
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_slot_wal_keep_size
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_size
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案大小。
資料類型
整數
預設值
400
允許的值
400
參數類型
唯讀
文件集
wal_keep_size
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_slot_wal_keep_size
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_size
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案大小。
資料類型
整數
預設值
400
允許的值
400
參數類型
唯讀
文件集
wal_keep_size
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_slot_wal_keep_size
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_size
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案大小。
資料類型
整數
預設值
400
允許的值
400
參數類型
唯讀
文件集
wal_keep_size
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_slot_wal_keep_size
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_size
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案大小。
資料類型
整數
預設值
400
允許的值
400
參數類型
唯讀
文件集
wal_keep_size
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_segments
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案數目。
資料類型
整數
預設值
25
允許的值
25
參數類型
唯讀
文件集
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout
max_replication_slots
屬性
值
類別
複寫/傳送伺服器
描述
指定伺服器可支援的複寫位置數目上限。
資料類型
整數
預設值
10
允許的值
2-262143
參數類型
static
文件集
max_replication_slots
max_wal_senders
屬性
值
類別
複寫/傳送伺服器
描述
設定同時執行 WAL 傳送者流程的數目上限。
資料類型
整數
預設值
10
允許的值
5-100
參數類型
static
文件集
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 傳送者都會喚醒:
譯碼 WAL 中的所有新記錄,
篩選出他們不感興趣的記錄檔記錄,
複寫與每個數據相關的數據。
WAL 發件者與連線類似,也就是說,如果它們閑置,就不管有多少人。 然而,如果他們很活躍,他們只會競爭相同的資源,而效能最終可能會非常糟糕。 對於具有邏輯復寫的傳送者來說,這特別如此,因為邏輯譯碼相當耗費 CPU 成本。 每個背景工作角色必須譯碼整個WAL,即使它只會復寫影響單一數據表的作業,而且代表預先寫入記錄中所有數據的一小部分。 對於實體復寫來說,這並不重要,因為 WAL 傳送者不會耗用如此密集的 CPU,而且它們通常會先受到網路頻寬的限制。
因此,一般而言,最好沒有比虛擬核心更多的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 。
如果您仍然認為此參數允許的最大值對於您的需求而言太低,請 與我們連絡 ,詳細描述您的案例,並說明您認為這是案例執行正確所需的最小值。
track_commit_timestamp
wal_keep_segments
屬性
值
類別
複寫/傳送伺服器
描述
設定要針對待命伺服器保留的 WAL 檔案數目。
資料類型
整數
預設值
25
允許的值
25
參數類型
唯讀
文件集
wal_sender_timeout
屬性
值
類別
複寫/傳送伺服器
描述
設定等候 WAL 複寫的時間上限。
資料類型
整數
預設值
60000
允許的值
60000
參數類型
唯讀
文件集
wal_sender_timeout