Podwyższanie poziomu replik do odczytu w usłudze Azure Database for PostgreSQL — serwer elastyczny
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Podwyższanie poziomu odnosi się do procesu, w którym replika jest poleceń, aby zakończyć tryb repliki i przejść do pełnych operacji odczytu i zapisu.
Ważne
Operacja podwyższania poziomu nie jest automatyczna. W przypadku awarii serwera podstawowego system nie przełączy się niezależnie do repliki do odczytu. Akcja użytkownika jest zawsze wymagana dla operacji podwyższania poziomu.
Podwyższanie poziomu replik można wykonać w dwa różne sposoby:
Podwyższanie poziomu do serwera podstawowego
Ta akcja podnosi poziom repliki do roli serwera podstawowego. W tym procesie bieżący serwer podstawowy jest obniżany do roli repliki, zamieniając ich role. W przypadku pomyślnego podwyższenia poziomu należy skonfigurować wirtualny punkt końcowy zarówno dla bieżącego podstawowego punktu końcowego jako punktu końcowego składnika zapisywania, jak i replikę przeznaczoną do podwyższenia poziomu jako punktu końcowego czytnika. Podwyższenie poziomu powiedzie się tylko wtedy, gdy docelowa replika jest uwzględniona w konfiguracji punktu końcowego czytnika.
Diagram ilustruje konfigurację serwerów przed podwyższeniem poziomu i wynikowy stan po pomyślnym zakończeniu operacji podwyższania poziomu.
Podwyższ poziom do niezależnego serwera i usuń z replikacji
Po wybraniu tej opcji replika zostanie podniesiona do niezależnego serwera i zostanie usunięta z procesu replikacji. W rezultacie zarówno podstawowy, jak i promowany serwer działają jako dwa niezależne serwery odczytu i zapisu. Należy zauważyć, że podczas konfigurowania wirtualnych punktów końcowych nie są one konieczne dla tej operacji. Nowo promowany serwer nie jest już częścią istniejących wirtualnych punktów końcowych, nawet jeśli punkt końcowy czytnika był wcześniej wskazywany. W związku z tym ważne jest zaktualizowanie parametry połączenia aplikacji w celu przekierowania do nowo promowanej repliki, jeśli aplikacja powinna się z nią połączyć.
Na diagramie przedstawiono sposób konfigurowania serwerów przed podwyższeniem poziomu i ich konfiguracją po pomyślnym utworzeniu niezależnych serwerów.
Ważne
Akcja Podwyższanie poziomu do niezależnego serwera i usuwanie z replikacji jest wstecznie zgodna z poprzednią funkcją podwyższania poziomu.
Ważne
Symetria serwera: w celu pomyślnego podwyższenia poziomu do operacji serwera podstawowego zarówno serwery podstawowe, jak i repliki muszą mieć identyczne warstwy i rozmiary magazynu. Jeśli na przykład podstawowy ma 2 rdzenie wirtualne, a replika ma 4 rdzenie wirtualne, jedyną realną opcją jest użycie akcji "podwyższanie poziomu do niezależnego serwera i usuwanie z replikacji". Ponadto muszą one współdzielić te same wartości dla parametrów serwera, które przydzielają pamięć udostępnioną.
W przypadku obu metod podwyższania poziomu dostępnych jest więcej opcji:
Planowana: Ta opcja gwarantuje, że dane są synchronizowane przed podwyższeniem. Stosuje wszystkie oczekujące dzienniki, aby zapewnić spójność danych przed zaakceptowaniem połączeń klienckich.
Wymuszone: ta opcja jest przeznaczona do szybkiego odzyskiwania w scenariuszach, takich jak awarie regionalne. Zamiast czekać na zsynchronizowanie wszystkich danych z serwera podstawowego, serwer staje się operacyjny, gdy przetwarza pliki WAL potrzebne do osiągnięcia najbliższego stanu spójności. Jeśli podwyższasz poziom repliki przy użyciu tej opcji, opóźnienie w czasie odłączania repliki z elementu podstawowego wskazuje, ile danych zostanie utraconych.
Ważne
Opcja Wymuszona promocja została specjalnie zaprojektowana w celu rozwiązania problemów z awariami regionalnymi, a w takich przypadkach pomija wszystkie kontrole — w tym wymaganie dotyczące symetrii serwera — i przechodzi do promocji. Dzieje się tak, ponieważ priorytetem jest natychmiastowa dostępność serwera w celu obsługi scenariuszy awarii. Jednak użycie opcji Wymuszone poza scenariuszami w dół regionu nie jest dozwolone, jeśli wymagania dotyczące replik do odczytu określonych w dokumentacji, zwłaszcza wymagania dotyczące symetrii serwera, nie są spełnione, ponieważ może to prowadzić do problemów, takich jak przerwana replikacja.
Dowiedz się, jak podwyższyć poziom repliki do podstawowego i podwyższyć poziom do niezależnego serwera i usunąć z replikacji.
Zarządzanie konfiguracją
Repliki do odczytu są traktowane jako oddzielne serwery pod względem konfiguracji płaszczyzny sterowania. Takie podejście zapewnia elastyczność scenariuszy skalowania odczytu. Jednak w przypadku używania replik do celów odzyskiwania po awarii użytkownicy muszą upewnić się, że konfiguracja jest zgodna z potrzebami.
Operacja podwyższania poziomu nie przenosi określonych konfiguracji i parametrów. Oto niektóre z godnych uwagi:
- PgBouncer: wbudowane ustawienia i stan modułu puli połączeń PgBouncer nie są replikowane podczas procesu podwyższania poziomu. Jeśli funkcja PgBouncer została włączona na serwerze podstawowym, ale nie w repliki, pozostanie wyłączona na repliki po podwyższeniu poziomu. Jeśli chcesz, aby narzędzie PgBouncer na nowo promowanym serwerze było włączone przed akcją podwyższania poziomu lub po niej.
- Geograficznie nadmiarowy magazyn kopii zapasowych: ustawienia geograficznej kopii zapasowej nie są przenoszone. Ponieważ repliki nie mogą mieć włączonej kopii zapasowej geograficznej, promowany element podstawowy (dawniej replika) nie ma go po podwyższeniu poziomu. Funkcję można aktywować tylko w czasie tworzenia serwera standardowego (a nie repliki).
- Parametry serwera: jeśli ich wartości różnią się od repliki podstawowej i do odczytu, nie zmienią się podczas podwyższania poziomu. Należy pamiętać, że parametry wpływające na rozmiar pamięci współużytkowanej muszą mieć te same wartości zarówno w przypadku replik podstawowych, jak i replik. To wymaganie zostało szczegółowo opisane w sekcji Parametry serwera.
- Uwierzytelnianie firmy Microsoft Entra: jeśli podstawowa usługa Microsoft Entra ma skonfigurowane uwierzytelnianie firmy Microsoft, ale replika została skonfigurowana przy użyciu uwierzytelniania PostgreSQL, po podwyższeniu poziomu replika nie przełączy się automatycznie na uwierzytelnianie firmy Microsoft Entra. Zachowuje uwierzytelnianie postgreSQL. Użytkownicy muszą ręcznie skonfigurować uwierzytelnianie microsoft Entra w promowanej repliki przed lub po procesie podwyższania poziomu.
- Wysoka dostępność (HA): Jeśli po podwyższeniu poziomu wymagana jest wysoka dostępność, należy ją skonfigurować na świeżo podwyższonym poziomie serwera podstawowego, po odwróceniu roli.
Kwestie wymagające rozważenia
Stany serwera podczas podwyższania poziomu
W scenariuszach podwyższania poziomu planowanego i wymuszonego wymagane jest, aby serwery (zarówno podstawowe, jak i repliki) znajdowały się w stanie "Dostępne". Jeśli stan serwera jest inny niż "Dostępny" (np. "Aktualizowanie" lub "Ponowne uruchamianie"), podwyższenie poziomu zwykle nie może kontynuować bez problemów. Jednak w przypadku awarii regionalnych występuje wyjątek.
Podczas takich regionalnych awarii można zaimplementować metodę wymuszonego podwyższania poziomu niezależnie od bieżącego stanu serwera podstawowego. Takie podejście umożliwia szybkie działanie w odpowiedzi na potencjalne awarie regionalne, pomijając normalne kontrole dostępności serwera.
Należy pamiętać, że jeśli poprzedni serwer podstawowy ulegnie awarii poza odzyskiwaniem podczas podwyższania poziomu repliki, jedyną opcją jest usunięcie byłego serwera podstawowego i ponowne utworzenie serwera repliki.
Widoczność wielu replik podczas podwyższania poziomu w regionach innych niż
Podczas pracy z wieloma replikami i jeśli region podstawowy nie ma sparowanego regionu, należy wziąć pod uwagę szczególną uwagę. W przypadku awarii regionalnej wpływającej na podstawową każdą inną replikę nie będzie automatycznie rozpoznawana przez nowo promowaną replikę. Mimo że aplikacje mogą być nadal kierowane do promowanej repliki do ciągłej operacji, nierozpoznane repliki pozostają rozłączone podczas awarii. Te dodatkowe repliki zostaną ponownie skojarzone i wznowione tylko po przywróceniu oryginalnego regionu podstawowego.
Przywracanie do punktu w czasie podczas podwyższania poziomu
W scenariuszach podwyższania poziomu planowana i wymuszona wymagana jest dostępność najnowszych automatycznych kopii zapasowych w celu zapewnienia pomyślnego wykonania operacji przywracania do punktu w czasie. Wiemy o problemie polegającym na tym, że operacja pitr może napotkać następujący błąd po zakończeniu operacji przejścia w tryb failover i powrotu po awarii. Ten problem ma zostać rozwiązany w nadchodzącej wersji. Aby zapewnić pomyślne operacje pitR do najnowszego czasu, możesz poczekać na ukończenie automatycznej kopii zapasowej po operacji podwyższania poziomu.
Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.
Często zadawane pytania
Czy mogę podwyższyć poziom repliki, jeśli mój serwer podstawowy ma włączoną wysoką dostępność?
Tak, niezależnie od tego, czy serwer podstawowy jest włączony, czy nie, można podwyższyć poziom jego repliki do odczytu. Możliwość podwyższenia poziomu repliki do odczytu do serwera podstawowego jest niezależna od konfiguracji wysokiej dostępności podstawowego.
Jeśli mam podstawową i replikę do odczytu z włączoną wysoką dostępnością, a następnie podwyższę poziom repliki, przełącz się z powrotem do oryginalnego podstawowego serwera, czy serwer nadal będzie w wysokiej dostępności?
Nie, wyłączamy wysoką dostępność podczas początkowej promocji, ponieważ nie obsługujemy replik odczytu z włączoną wysoką dostępnością. Podwyższenie poziomu repliki do odczytu do podstawowego oznacza, że oryginalna podstawowa zmiana jego roli na replikę. Jeśli przełączasz się z powrotem, musisz włączyć wysoką dostępność na oryginalnym serwerze podstawowym.