max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di slot di replica definiti contemporaneamente. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. Gli slot di replica verranno contrassegnati come non riusciti e segmenti rilasciati per l'eliminazione o il riutilizzo, se questo spazio su disco è occupato da WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di slot di replica definiti contemporaneamente. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. Gli slot di replica verranno contrassegnati come non riusciti e segmenti rilasciati per l'eliminazione o il riutilizzo, se questo spazio su disco è occupato da WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le massime dimensioni WAL che possono essere riservate da slot di replica. |
| Tipo di dati |
integer |
| Valore predefinito |
-1 |
| Valori consentiti |
-1 |
| Tipo di parametro |
Sola lettura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta le dimensioni dei file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
400 |
| Valori consentiti |
400 |
| Tipo di parametro |
Sola lettura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero di file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
25 |
| Valori consentiti |
25 |
| Tipo di parametro |
Sola lettura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Specifica il numero massimo di slot di replica che il server può supportare. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
2-262143 |
| Tipo di parametro |
Statica |
| Documentation |
max_replication_slots |
Note specifiche su Azure
Il valore predefinito per max_replication_slots il parametro è 10. Se si abilita la disponibilità elevata, sono necessari almeno 4 max_replication_slots per garantire il corretto funzionamento della disponibilità elevata.
Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_replication_slots su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_replication_slot. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
max_wal_senders
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero massimo di processi mittente WAL contemporaneamente in esecuzione. |
| Tipo di dati |
integer |
| Valore predefinito |
10 |
| Valori consentiti |
5-100 |
| Tipo di parametro |
Statica |
| Documentation |
max_wal_senders |
Note specifiche su Azure
Il valore predefinito per il max_wal_senders parametro del server impostato quando si effettua il provisioning dell'istanza del server flessibile di Database di Azure per PostgreSQL non deve mai essere ridotto al di sotto 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replicationdi .
Quando si considera la necessità di aumentare max_wal_senders a un valore molto più elevato per poter gestire la replica logica di un numero considerevole di tabelle, tenere presente quanto segue:
- La replica logica di un numero elevato di tabelle non richiede necessariamente un numero elevato di mittenti WAL.
- L'unico motivo per cui hai bisogno di un processo di invio WAL separato per ciascuna tabella o gruppo di tabelle è se sono necessarie sottoscrizioni separate per ciascuna di queste tabelle o gruppi di tabelle.
- Indipendentemente dal numero di mittenti WAL utilizzati per la replica fisica e logica, diventano tutti attivi contemporaneamente, ogni volta che qualsiasi back-end scrive qualcosa nel log write-ahead. In questo caso, i mittenti WAL assegnati alla replica logica vengono tutti riattivati per:
- Decodificare tutti i nuovi record nel WAL.
- Filtrare i record di log a cui non sono interessati,
- Replicare i dati rilevanti per ognuno di essi.
- I mittenti WAL sono simili alle connessioni nella misura in cui, se sono inattivi, non importa quanti siano. Tuttavia, se sono attivi, saranno solo in competizione per le stesse risorse e le prestazioni potrebbero finire terribilmente male. Ciò vale soprattutto per i mittenti con replica logica, perché la decodifica logica è piuttosto costosa per la CPU. Ogni lavoratore deve decodificare l'intero WAL, anche se replica solo le operazioni che interessano una singola tabella, che rappresenta solo una piccola percentuale di tutti i dati nel log di scrittura anticipata. Per la replica fisica non è così importante, perché i mittenti WAL non usano la CPU in modo intensivo e tendono a essere vincolati prima dalla larghezza di banda di rete.
- Pertanto, in generale, è preferibile non avere molti più mittenti WAL rispetto a vCore.
- È consigliabile aggiungere spazio per alcuni mittenti WAL aggiuntivi per supportare la crescita futura o i picchi temporanei nelle connessioni di replica. I due esempi seguenti possono essere utili per illustrarlo meglio.
- Per un server con 8 vCores, HA disabilitato, 2 repliche in lettura e 3 slot di replica logica, puoi configurare
max_wal_senders come somma degli slot fisici per HA (0) + slot fisici per le repliche in lettura (2) + slot logici (3) + altri per una crescita futura, considerando i vCores disponibili (1) = 6.
- Per un server con 16 vCore, Alta Disponibilità (HA) abilitata, 4 repliche di lettura e 5 slot di replica logica, è possibile configurare
max_wal_senders come somma degli slot fisici per Alta Disponibilità (2) + slot fisici per le repliche di lettura (4) + slot di replicazione logica (5) + alcuni extra per la crescita futura, considerando i vCore disponibili (2) = 13.
- Se si abilita la disponibilità elevata, sono necessari almeno 4
max_wal_senders per garantire il corretto funzionamento della disponibilità elevata. Per un server con la disponibilità elevata abilitata, più 5 repliche in lettura e 12 slot di replica logica, è consigliabile configurare max_wal_senders su 21. Questo perché ogni replica in lettura e ogni slot di replica logica richiede un oggetto max_wal_senders. Sarà quindi necessario un totale di 1 (slot) * 5 (repliche in lettura) + 12 (slot di replica logica) + 4 (per il corretto funzionamento della funzionalità elevata) = 21.
- Se si considera comunque che il valore massimo consentito per questo parametro è troppo basso per le proprie esigenze, contattare Microsoft, descrivere in dettaglio lo scenario e spiegare cosa considerare che sarebbe il valore minimo accettabile necessario per il corretto funzionamento dello scenario.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Raccoglie il tempo di commit della transazione. |
| Tipo di dati |
boolean |
| Valore predefinito |
off |
| Valori consentiti |
on,off |
| Tipo di parametro |
Statica |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il numero di file WAL mantenuti per i server di standby. |
| Tipo di dati |
integer |
| Valore predefinito |
25 |
| Valori consentiti |
25 |
| Tipo di parametro |
Sola lettura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Replicazione / Server di invio |
| Description |
Imposta il tempo massimo di attesa per la replica WAL. |
| Tipo di dati |
integer |
| Valore predefinito |
60000 |
| Valori consentiti |
0-2147483647 |
| Tipo di parametro |
dynamic |
| Documentation |
wal_sender_timeout |