-
Notifications
You must be signed in to change notification settings - Fork 36
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #631 from MicrosoftDocs/main
10/22/2024 PM Publish
- Loading branch information
Showing
46 changed files
with
838 additions
and
641 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
32 changes: 16 additions & 16 deletions
32
articles/postgresql/flexible-server/includes/extensions-table.md
Large diffs are not rendered by default.
Oops, something went wrong.
28 changes: 28 additions & 0 deletions
28
...resql/flexible-server/includes/server-parameters-azure-notes-max-wal-senders.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
--- | ||
title: max_wal_senders server parameter | ||
description: max_wal_senders server parameter for Azure Database for PostgreSQL - Flexible Server. | ||
ms.service: azure-database-postgresql | ||
ms.subservice: flexible-server | ||
ms.topic: include | ||
ms.date: 10/14/2024 | ||
author: nachoalonsoportillo | ||
ms.author: ialonso | ||
zone_pivot_groups: postgresql-server-version | ||
--- | ||
#### Azure-specific notes | ||
The default value for the `max_wal_senders` server parameter set when you provision the instance of Azure Database for PostgreSQL flexible server must never be decreased below `2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication`. | ||
|
||
When considering the need to increase `max_wal_senders` to a much higher value to be able to cope with the logical replication of a substantial number of tables, have the following important points in mind: | ||
|
||
- Logically replicating a large number of tables doesn't necessarily need a large number of WAL senders. | ||
- The only reason why you need separate WAL sender per-table or group of tables is if you need separate subscriptions for each of those tables or groups of. | ||
- Whatever number of WAL senders are being utilized for physical and logical replication, they all become active at once, whenever any backend writes something to the write-ahead log. When that happens, the WAL senders that are assigned to do logical replication all wake up to: | ||
1. Decode all new records in the WAL, | ||
1. Filter out log records they're not interested in, | ||
1. Replicate the data that's relevant to each of them. | ||
- WAL senders are similar to connections in the sense that, if they are idle, it doesn't matter how many there are. However, if they are active, they'll just compete for the same resources and the performance could end up being terribly bad. This is especially true for senders with logical replication, because the logical decoding is rather CPU expensive. Each worker has to decode the entire WAL, even if it only replicates the operations affecting a single table, and that represents a tiny percentage of all the data in the write-ahead log. For physical replication it's not that important, because the WAL senders don't consume CPU so intensively, and they tend to be bounded by network bandwidth first. | ||
- Therefore, in general, it's better to not have many more WAL senders than vCores. | ||
- It's a good practice to add room for a few extra WAL senders to accommodate future growth or temporary spikes in replication connections. The following two examples might help illustrate it better. | ||
- For a server with 8 vCores, HA disabled, 2 read replicas, and 3 logical replication slots, you may want to configure `max_wal_senders` as the sum of physical slots for HA (0) + physical slots for read replicas (2) + logical slots(3) + some extra for future growth, considering available vCores (1) = **6**. | ||
- For a server with 16 vCores, HA enabled, 4 read replicas, and 5 logical replication slots, you may want to configure `max_wal_senders` as the sum of physical slots for HA (2) + physical slots for read replicas (4) + logical slots(5) + some extra for future growth, considering available vCores (2) = **13**. | ||
- If you still consider that the maximum value allowed for this parameter is too low for your needs, please [contact us](../overview.md#contacts), describe your scenario in detail and explain what do you consider that would be the minimum acceptable value you would need for your scenario to perform properly. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.