max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie zdefiniowanych miejsc replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. Miejsca replikacji zostaną oznaczone jako nieudane, a segmenty wydane do usunięcia lub recyklingu, jeśli ta ilość miejsca jest zajęta przez plik WAL na dysku. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie zdefiniowanych miejsc replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. Miejsca replikacji zostaną oznaczone jako nieudane, a segmenty wydane do usunięcia lub recyklingu, jeśli ta ilość miejsca jest zajęta przez plik WAL na dysku. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_slot_wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny rozmiar pliku WAL, który może być zarezerwowany przez miejsca replikacji. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
-1 |
| Dozwolone wartości |
-1 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_size
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia rozmiar plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
400 |
| Dozwolone wartości |
400 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
wal_keep_size |
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia liczbę plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
25 |
| Dozwolone wartości |
25 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
|
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |
max_replication_slots
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Określa maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
2-262143 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_replication_slots |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_replication_slots to 10. Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4 max_replication_slots , aby wysoka dostępność działała prawidłowo.
W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_replication_slots można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_replication_slot. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
max_wal_senders
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalną liczbę jednocześnie uruchomionych procesów nadawcy WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
10 |
| Dozwolone wartości |
5-100 |
| Typ parametru |
statyczny |
| Dokumentacja |
max_wal_senders |
Uwagi specyficzne dla platformy Azure
Wartość domyślna parametru max_wal_senders serwera ustawiona podczas aprowizacji wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL nigdy nie może być zmniejszona poniżej 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Biorąc pod uwagę konieczność zwiększenia max_wal_senders do znacznie wyższej wartości, aby móc poradzić sobie z replikacją logiczną znacznej liczby tabel, należy pamiętać o następujących ważnych kwestiach:
- Logiczną replikację dużej liczby tabel można osiągnąć bez konieczności użycia wielu procesów wysyłających WAL.
- Jedynym powodem, dla którego potrzebujesz oddzielnego nadawcy WAL dla tabeli lub grupy tabel, jest potrzeba oddzielnych subskrypcji dla każdej z tych tabel lub grup.
- Niezależnie od liczby nadawców WAL, które są używane do replikacji fizycznej i logicznej, wszystkie stają się aktywne jednocześnie, za każdym razem, gdy jakiekolwiek zaplecze zapisuje coś w dzienniku zapisu wymaganego z wyprzedzeniem. W takim przypadku nadawcy WAL przypisani do replikacji logicznej wszyscy budzą się, aby:
- Zdekoduj wszystkie nowe rekordy w pliku WAL,
- Odfiltruj rekordy dzienników, których nie interesują,
- Replikuj dane, które są odpowiednie dla każdego z nich.
- Nadawcy WAL są podobni do połączeń w tym sensie, że jeśli są bezczynni, nie ma znaczenia, ile ich jest. Jeśli jednak są aktywne, będą one jedynie konkurować o te same zasoby, a wydajność może skończyć się bardzo źle. Jest to szczególnie istotne w przypadku nadawców z replikacją logiczną, ponieważ dekodowanie logiczne jest raczej kosztowne dla procesora CPU. Każdy proces roboczy musi zdekodować cały plik WAL, nawet jeśli replikuje tylko operacje wpływające na jedną tabelę i reprezentuje niewielki procent wszystkich danych w dzienniku zapisu z wyprzedzeniem. W przypadku replikacji fizycznej nie jest to tak istotne, ponieważ nadawcy WAL nie zużywają intensywnie CPU, a ich wydajność jest najpierw ograniczana przez przepustowość sieci.
- W związku z tym ogólnie lepiej nie mieć znacznie więcej nadawców WAL niż rdzeni wirtualnych (vCores).
- Dobrym pomysłem jest zarezerwowanie miejsca na kilku dodatkowych nadawców WAL, aby umożliwić przyszłą rozbudowę lub tymczasowe skoki w połączeniach replikacji. Poniższe dwa przykłady mogą pomóc zilustrować go lepiej.
- W przypadku serwera z 8 rdzeniami wirtualnymi, wyłączoną wysoką dostępnością, 2 replikami do odczytu i 3 gniazdami replikacji logicznej, można skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (0) + miejsc fizycznych dla replik do odczytu (2) + gniazd logicznych (3) + dodatkowe gniazda dla przyszłego wzrostu, uwzględniając dostępne rdzenie wirtualne (1) = 6.
- W przypadku serwera z 16 wirtualnymi rdzeniami (vCores), z włączoną wysoką dostępnością, 4 replikami do odczytu i 5 gniazdami replikacji logicznej, możesz skonfigurować
max_wal_senders jako sumę miejsc fizycznych dla wysokiej dostępności (2) + miejsc fizycznych dla replik do odczytu (4) + gniazd logicznych (5) + dodatkowe sloty na przyszły wzrost, biorąc pod uwagę dostępne wirtualne rdzenie (2) = 13.
- Jeśli włączysz wysoką dostępność, potrzebujesz co najmniej 4
max_wal_senders , aby wysoka dostępność działała prawidłowo. W przypadku serwera z włączoną wysoką dostępnością, 5 replikami do odczytu i 12 gniazdami replikacji logicznej, wartość max_wal_senders można skonfigurować na 21. Dzieje się tak, ponieważ każda replika do odczytu i każde logiczne miejsce replikacji wymaga jednego max_wal_senders. W związku z tym wymaga łącznie 1 (gniazda) * 5 (replik do odczytu) + 12 (gniazda replikacji logicznej) + 4 (aby wysoka dostępność działała prawidłowo) = 21.
- Jeśli nadal uważasz, że maksymalna dozwolona wartość dla tego parametru jest zbyt niska dla Twoich potrzeb, skontaktuj się z nami, opisz szczegółowo twój scenariusz i wyjaśnij, co należy wziąć pod uwagę, że byłaby to minimalna akceptowalna wartość, której potrzebujesz, aby scenariusz działał prawidłowo.
track_commit_timestamp
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Zbiera czas zatwierdzenia transakcji. |
| Typ danych |
typ logiczny (boolowski) |
| Wartość domyślna |
off |
| Dozwolone wartości |
on,off |
| Typ parametru |
statyczny |
| Dokumentacja |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia liczbę plików WAL przechowywanych dla serwerów rezerwowych. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
25 |
| Dozwolone wartości |
25 |
| Typ parametru |
tylko do odczytu |
| Dokumentacja |
|
wal_sender_timeout
| Attribute |
Wartość |
| Kategoria |
Replikacja/wysyłanie serwerów |
| Description |
Ustawia maksymalny czas oczekiwania na replikację WAL. |
| Typ danych |
liczba całkowita |
| Wartość domyślna |
60000 |
| Dozwolone wartości |
0-2147483647 |
| Typ parametru |
dynamic |
| Dokumentacja |
wal_sender_timeout |