max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl gleichzeitig definierter Replikationsplätze fest. |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. Replikations-Slots werden als fehlgeschlagen gekennzeichnet und Segmente zur Löschung oder Wiederverwendung freigegeben, wenn so viel Speicherplatz von WAL auf dem Datenträger belegt ist. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl gleichzeitig definierter Replikationsplätze fest. |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. Replikations-Slots werden als fehlgeschlagen gekennzeichnet und Segmente zur Löschung oder Wiederverwendung freigegeben, wenn so viel Speicherplatz von WAL auf dem Datenträger belegt ist. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_slot_wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale WAL-Größe fest, die von Replikationsplätzen reserviert werden kann. |
| Datentyp |
integer |
| Standardwert |
-1 |
| Zulässige Werte |
-1 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
max_slot_wal_keep_size |
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_size
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Größe von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
400 |
| Zulässige Werte |
400 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
wal_keep_size |
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_segments
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Anzahl von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
25 |
| Zulässige Werte |
25 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
|
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |
max_replication_slots
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Gibt die maximale Anzahl der Replikationsplätze an, die der Server unterstützen kann |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
2-262143 |
| Parametertyp |
Statisch |
| Dokumentation |
max_replication_slots |
Azure-spezifische Hinweise
Der Standardwert für max_replication_slots den Parameter ist 10. Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4 max_replication_slots , damit hohe Verfügbarkeit ordnungsgemäß funktioniert.
Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_replication_slots auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_replication_slot benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
max_wal_senders
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse fest |
| Datentyp |
integer |
| Standardwert |
10 |
| Zulässige Werte |
5-100 |
| Parametertyp |
Statisch |
| Dokumentation |
max_wal_senders |
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter max_wal_senders, der festgelegt wird, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server bereitstellen, darf niemals den Wert 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication unterschreiten.
Wenn Sie in Betracht ziehen, max_wal_senders auf einen viel höheren Wert zu erhöhen, um die logische Replikation einer erheblichen Anzahl von Tabellen bewältigen zu können, beachten Sie die folgenden wichtigen Punkte:
- Das logische Replizieren einer großen Anzahl von Tabellen erfordert nicht unbedingt eine große Anzahl von WAL-Absendern.
- Der einzige Grund, warum Sie separate WAL-Absender pro Tabelle oder Gruppe von Tabellen benötigen, ist, wenn Sie separate Abonnements für jede dieser Tabellen oder Gruppen benötigen.
- Unabhängig davon, wie viele WAL-Absender für die physische und logische Replikation verwendet werden, werden sie sofort aktiv, wenn das Backend etwas in das Write-Ahead-Log schreibt. In diesem Fall werden die WAL-Absender, die der logischen Replikation zugewiesen sind, alle wie folgt reaktiviert:
- Decodiere alle neuen Datensätze im WAL
- Filtern von Protokolldatensätzen, an denen sie nicht interessiert sind,
- Replizieren der jeweils relevanten Daten
- WAL-Absender ähneln Verbindungen in dem Sinne, dass, wenn sie im Leerlauf sind, es keine Rolle spielt, wie viele es gibt. Wenn sie jedoch aktiv sind, werden sie nur für die gleichen Ressourcen konkurrieren, und die Leistung könnte am Ende schrecklich schlecht sein. Dies gilt insbesondere für Absender mit logischer Replikation, da die logische Decodierung ziemlich CPU-teuer ist. Jeder Worker muss den gesamten WAL decodieren, auch wenn er nur die Vorgänge repliziert, die sich auf eine einzelne Tabelle auswirken, und die einen winzigen Prozentsatz aller Daten im Write-Ahead-Protokoll darstellt. Bei der physischen Replikation ist es nicht so wichtig, da die WAL-Absender die CPU nicht so intensiv verbrauchen, und sie neigen dazu, zuerst an die Netzwerkbandbreite gebunden zu sein.
- Daher ist es im Allgemeinen besser, nicht viele mehr WAL-Absender zu haben als vCores.
- Es empfiehlt sich, Platz für einige zusätzliche WAL-Absender hinzuzufügen, um zukünftiges Wachstum oder temporäre Spitzen in Replikationsverbindungen zu berücksichtigen. Die folgenden beiden Beispiele können dazu beitragen, es besser zu veranschaulichen.
- Für einen Server mit 8 V-Kernen, deaktivierter Hochverfügbarkeit, 2 Lesereplikaten und 3 logischen Replikationsplätze sollten Sie
max_wal_senders als Summe der physischen Steckplätze für Hochverfügbarkeit (0) + physische Steckplätze für Lesereplikate (2) + logische Steckplätze (3) + einige zusätzliche für zukünftiges Wachstum unter Berücksichtigung der verfügbaren V-Kerne (1) konfigurieren = 6.
- Für einen Server mit 16 vCores, aktiviertem HA, 4 Lesereplikaten und 5 logischen Replikationsplätzen sollten Sie
max_wal_senders als Summe der physischen Steckplätze für HA (2) + physische Steckplätze für Lesereplikate (4) + logische Steckplätze (5) + einige zusätzliche für zukünftiges Wachstum konfigurieren, unter Berücksichtigung der verfügbaren vCores (2) = 13.
- Wenn Sie hohe Verfügbarkeit aktivieren, benötigen Sie mindestens 4
max_wal_senders , damit hohe Verfügbarkeit ordnungsgemäß funktioniert. Für einen Server mit aktivierter hoher Verfügbarkeit, 5 Lesereplikaten und 12 logischen Replikationsslots sollten Sie möglicherweise max_wal_senders auf 21 konfigurieren. Dies liegt daran, dass jedes Lesereplikat und jeder logische Replikationsslot einen max_wal_senders benötigt. Daher erfordert es insgesamt 1 (Steckplatz) * 5 (Lesereplikate) + 12 (logische Replikationsplätze) + 4 (damit hohe Verfügbarkeit ordnungsgemäß funktionieren kann) = 21.
- Wenn Sie dennoch berücksichtigen, dass der für diesen Parameter zulässige Maximalwert für Ihre Anforderungen zu niedrig ist, wenden Sie sich an uns, beschreiben Sie Ihr Szenario ausführlich, und erläutern Sie, was Sie als den minimal akzeptablen Wert betrachten, den Sie für Ihr Szenario benötigen, um ordnungsgemäß ausgeführt zu werden.
track_commit_timestamp
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Erfasst Transaktions-Commit-Zeit. |
| Datentyp |
boolean |
| Standardwert |
off |
| Zulässige Werte |
on,off |
| Parametertyp |
Statisch |
| Dokumentation |
track_commit_timestamp |
wal_keep_segments
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die Anzahl von WAL-Dateien fest, die für Standbyserver gespeichert werden |
| Datentyp |
integer |
| Standardwert |
25 |
| Zulässige Werte |
25 |
| Parametertyp |
schreibgeschützt |
| Dokumentation |
|
wal_sender_timeout
| Merkmal |
Wert |
| Kategorie |
Replikation/Sendungsserver |
| Description |
Legt die maximale Wartezeit für die WAL-Replikation fest. |
| Datentyp |
integer |
| Standardwert |
60000 |
| Zulässige Werte |
0-2147483647 |
| Parametertyp |
dynamic |
| Dokumentation |
wal_sender_timeout |