Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY:
Azure Database for PostgreSQL — serwer elastyczny
W tym artykule opisano wysoką dostępność w usłudze Azure Database for PostgreSQL - Flexible Server, która obejmuje strefy dostępności oraz odzyskiwanie między regionami i ciągłość działalności biznesowej. Aby uzyskać bardziej szczegółowe omówienie niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.
Usługa Azure Database for PostgreSQL — Serwer Elastyczny oferuje obsługę wysokiej dostępności poprzez aprowizowanie fizycznie rozdzielonych replik podstawowych i rezerwowych zarówno w tej samej strefie dostępności (strefowo), jak i w nadmiarowych strefach dostępności. Ten model wysokiej dostępności został zaprojektowany w celu zapewnienia, że zatwierdzone dane nigdy nie zostaną utracone w przypadku awarii. W konfiguracji wysokiej dostępności dane są synchronicznie zatwierdzane zarówno na serwerach podstawowych, jak i rezerwowych. Model został zaprojektowany tak, aby baza danych nie stała się pojedynczym punktem awarii w architekturze oprogramowania. Aby uzyskać więcej informacji na temat wysokiej dostępności i obsługi stref dostępności, zobacz Obsługa stref dostępności.
Obsługa strefy dostępności
Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.
Azure Database for PostgreSQL — Flexible Server obsługuje zarówno modele strefowo-redundante, jak i strefowe na potrzeby konfiguracji wysokiej dostępności. Obie konfiguracje wysokiej dostępności umożliwiają automatyczne przełączanie w tryb failover z zerową utratą danych zarówno podczas planowanych, jak i nieplanowanych zdarzeń.
Nadmiarowość strefowa. Strefowo nadmiarowa wysoka dostępność wdraża replikę rezerwową w innej strefie z funkcją automatycznego trybu failover. Redundancja strefy zapewnia najwyższy poziom dostępności, ale wymaga skonfigurowania redundancji aplikacji pomiędzy strefami. Z tego powodu wybierz strefową nadmiarowość, jeśli chcesz zapewnić ochronę przed awariami na poziomie strefy dostępności oraz gdy opóźnienie w strefach dostępności jest akceptowalne. Chociaż z powodu replikacji synchronicznej może wystąpić pewien wpływ opóźnienia na operacje zapisu i zatwierdzania, nie ma to wpływu na zapytania odczytowe. Ten wpływ jest bardzo specyficzny dla obciążeń, wybranego typu jednostki SKU i regionu.
Możesz wybrać region i strefy dostępności zarówno dla serwerów podstawowych, jak i rezerwowych. Serwer repliki rezerwowej jest aprowizowany w wybranej strefie dostępności w tym samym regionie z podobną konfiguracją obliczeniową, magazynową i siecią co serwer podstawowy. Pliki danych i pliki dziennika transakcji (dzienniki zapisu z wyprzedzeniem, np. WAL) są przechowywane w magazynie lokalnie nadmiarowym (LRS) w każdej strefie dostępności, automatycznie przechowując trzy kopie danych. Konfiguracja strefowo nadmiarowa zapewnia fizyczną izolację całego stosu między serwerami podstawowymi i rezerwowymi.
Opcja z redundancją strefową jest dostępna tylko w regionach, które obsługują strefy dostępności.
Strefowo nadmiarowy nie jest obsługiwany dla:
- Warstwa obliczeniowa z możliwością rozszerzenia.
- Regiony z dostępnością w jednej strefie.
Strefowe. Wybierz wdrożenie strefowe, jeśli chcesz uzyskać najwyższy poziom dostępności w ramach pojedynczej strefy dostępności, ale z najniższym opóźnieniem sieci. Możesz wybrać region i strefę dostępności, aby wdrożyć zarówno podstawowy serwer bazy danych. Serwer repliki rezerwowej jest automatycznie aprowizowany i zarządzany w tej samej strefie dostępności — z podobną konfiguracją obliczeniową, magazynem i siecią — jako serwer podstawowy. Konfiguracja strefowa chroni bazy danych przed awariami na poziomie węzła, a także pomaga zmniejszyć przestoje aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Dane z serwera podstawowego są replikowane do repliki rezerwowej w trybie synchronicznym. W przypadku zakłóceń na serwerze podstawowym serwer jest automatycznie przełączony w tryb failover do repliki rezerwowej.
Opcja wdrożenia strefowego jest dostępna we wszystkich regionach świadczenia usługi Azure, w których można wdrożyć serwer elastyczny.
Uwaga
Zarówno modele architektoniczne wdrażania strefowego, jak i strefowo nadmiarowego zachowują się tak samo. Różne dyskusje w poniższych sekcjach mają zastosowanie do obu przypadków, chyba że zaznaczono inaczej.
Funkcje wysokiej dostępności
Replika rezerwowa jest wdrażana w tej samej konfiguracji maszyny wirtualnej — w tym rdzeni wirtualnych, magazynu, ustawień sieciowych — jako serwera podstawowego.
Możesz dodać obsługę strefy dostępności dla istniejącego serwera bazy danych.
Replikę rezerwną można usunąć, wyłączając wysoką dostępność.
Możesz wybrać strefy dostępności dla serwerów podstawowego i zapasowego w celu zapewnienia nadmiarowej dostępności strefowej.
Takie operacje jak zatrzymywanie, uruchamianie i ponowne uruchamianie są wykonywane jednocześnie na podstawowych i rezerwowych serwerach bazy danych.
W modelach strefowo nadmiarowych i strefowych automatyczne kopie zapasowe są wykonywane okresowo z podstawowego serwera bazy danych. Jednocześnie dzienniki transakcji są stale archiwizowane w magazynie kopii zapasowych z repliki rezerwowej. Jeśli region obsługuje strefy dostępności, dane kopii zapasowej są przechowywane w magazynie strefowo nadmiarowym (ZRS). W regionach, które nie obsługują stref dostępności, dane kopii zapasowych są przechowywane w magazynie lokalnie nadmiarowym (LRS).
Klienci zawsze łączą się z końcową nazwą hosta podstawowego serwera bazy danych.
Wszelkie zmiany parametrów serwera są również stosowane do repliki rezerwowej.
Istnieje możliwość ponownego uruchomienia serwera w celu pobrania wszelkich zmian parametrów statycznych serwera.
Okresowe działania konserwacyjne, takie jak drobne aktualizacje wersji, są wykonywane najpierw na zapasowym serwerze, a w celu zmniejszenia przestoju, zapasowy serwer jest promowany na główny, dzięki czemu obciążenia mogą być kontynuowane, podczas gdy zadania konserwacji są stosowane na pozostałym serwerze.
Uwaga
Aby upewnić się, że High-Availability (HA) działa prawidłowo, należy skonfigurować wartości parametrów max_replication_slots i max_wal_senders serwera. High-Availability wymaga 4 z nich do obsługi trybu failover i bezproblemowych uaktualnień. W przypadku konfiguracji wysokiej dostępności z 5 replikami do odczytu i 12 gniazdami replikacji logicznej należy ustawić wartości obu parametrów max_replication_slots i max_wal_senders na 21. Dzieje się tak, ponieważ każda replika odczytu i każde miejsce replikacji logicznej wymaga po jednym z nich, plus cztery dodatkowe, aby High-Availability działało prawidłowo. Aby dowiedzieć się więcej na temat parametrów max_replication_slots i max_wal_senders, zapoznaj się z dokumentacją.
Monitorowanie kondycji wysokiej dostępności
Monitorowanie kondycji wysokiej dostępności (HA) w usłudze Azure Database for PostgreSQL - elastyczny serwer dostarcza ciągły przegląd kondycji i gotowości instancji z włączoną wysoką dostępnością. Ta funkcja monitorowania korzysta z platformy Azure Resource Health Check (RHC) do wykrywania i powiadamiania o wszelkich problemach, które mogą mieć wpływ na gotowość bazy danych do trybu failover lub ogólną dostępność. Oceniając kluczowe metryki, takie jak stan połączenia, stan przełączenia awaryjnego i kondycja replikacji danych, monitorowanie stanu zdrowia wysokiej dostępności umożliwia proaktywne rozwiązywanie problemów i pomaga zachować dostępność oraz wydajność bazy danych.
Klienci mogą używać monitorowania statusu zdrowotnego systemu wysokiej dostępności w celu:
- Uzyskaj wgląd w kondycję replik podstawowych i rezerwowych w czasie rzeczywistym, ze wskaźnikami stanu, które ujawniają potencjalne problemy, takie jak obniżona wydajność lub blokowanie sieci.
- Skonfiguruj alerty, aby otrzymywać terminowe powiadomienia o wszelkich zmianach stanu wysokiej dostępności, co pozwoli na podjęcie natychmiastowych działań w razie wystąpienia potencjalnych zakłóceń.
- Zoptymalizuj gotowość do trybu failover, identyfikując i rozwiązując problemy, zanim wpłyną one na operacje bazy danych.
Aby uzyskać szczegółowy przewodnik dotyczący konfigurowania i interpretowania stanu kondycji wysokiej dostępności, zapoznaj się z głównym artykułem Monitorowanie stanu kondycji wysokiej dostępności (HA) dla usługi Azure Database for PostgreSQL — serwer elastyczny.
Ograniczenia wysokiej dostępności
Ze względu na synchroniczną replikację do serwera rezerwowego, zwłaszcza w przypadku konfiguracji strefowo nadmiarowej, aplikacje mogą mieć podwyższony poziom opóźnienia zapisu i zatwierdzania.
Repliki rezerwowej nie można używać do wykonywania zapytań odczytu.
W zależności od obciążenia i działania na serwerze podstawowym proces przełączania awaryjnego może potrwać dłużej niż 120 sekund z powodu odzyskiwania danych na replikę zapasową, zanim może zostać promowany.
Serwer rezerwowy zwykle odzyskuje pliki WAL o rozmiarze 40 MB/s. W przypadku większych jednostek SKU ta szybkość może wzrosnąć do nawet 200 MB/s. Jeśli obciążenie przekroczy ten limit, możesz doświadczyć wydłużonego czasu potrzebnego na zakończenie odzyskiwania, zarówno podczas przełączania awaryjnego, jak i po ustanowieniu nowego stanu gotowości.
Ponowne uruchomienie podstawowego serwera bazy danych powoduje również ponowne uruchomienie repliki rezerwowej.
Konfigurowanie dodatkowej jednostki zapasowej nie jest obsługiwane.
Nie można zaplanować konfigurowania zadań zarządzania zainicjowanych przez klienta w oknie konserwacji zarządzanej.
Planowane działania, takie jak skalowanie obliczeń i skalowanie magazynowania, są wykonywane najpierw na serwerze zapasowym, a następnie na serwerze podstawowym. Obecnie serwer nie jest w trybie failover dla tych planowanych operacji.
Jeśli dekodowanie logiczne lub replikacja logiczna jest skonfigurowana przy użyciu serwera elastycznego skonfigurowanego pod kątem dostępności, w przypadku przejścia w tryb failover na serwer rezerwowy miejsca replikacji logicznej nie są kopiowane do serwera rezerwowego. Aby zachować miejsca replikacji logicznej i zapewnić spójność danych po przejściu w tryb failover, zaleca się użycie rozszerzenia PG Failover Slots. Aby uzyskać więcej informacji na temat włączania tego rozszerzenia, zapoznaj się z dokumentacją.
Konfigurowanie stref dostępności między prywatną siecią wirtualną i dostępem publicznym z prywatnymi punktami końcowymi nie jest obsługiwane. Należy skonfigurować strefy dostępności w sieci wirtualnej (obejmujące wiele stref dostępności w regionie) lub dostęp publiczny z prywatnymi punktami końcowymi.
Strefy dostępności są konfigurowane tylko w jednym regionie. Stref dostępności nie można skonfigurować w różnych regionach.
SLA (Umowa o Poziomie Usług)
Model strefowy oferuje SLA dostępności 99,95%.
Model strefowej nadmiarowości oferuje umowę SLA na dostępność 99,99%.
Tworzenie usługi Azure Database for PostgreSQL — serwer elastyczny z włączoną strefą dostępności
Aby dowiedzieć się, jak utworzyć usługę Azure Database for PostgreSQL — serwer elastyczny w celu zapewnienia wysokiej dostępności ze strefami dostępności, zobacz Szybki start: tworzenie usługi Azure Database for PostgreSQL — serwer elastyczny w witrynie Azure Portal.
Ponowne wdrażanie strefy dostępności i migracja
Aby dowiedzieć się, jak włączyć lub wyłączyć konfigurację wysokiej dostępności na serwerze elastycznym w modelach wdrażania strefowo nadmiarowego i strefowego, zobacz Zarządzanie wysoką dostępnością na serwerze elastycznym.
Składniki wysokiej dostępności i przepływ pracy
Uzupełnianie transakcji
Operacje zapisu i zatwierdzenia wyzwalane przez transakcje aplikacji są najpierw rejestrowane w pliku WAL na serwerze podstawowym. Są one następnie przesyłane strumieniowo do serwera rezerwowego przy użyciu protokołu przesyłania strumieniowego Postgres. Gdy dzienniki zostaną zapisane w magazynie serwera rezerwowego, serwer podstawowy otrzymuje potwierdzenie zakończenia zapisu. Dopiero wtedy aplikacja potwierdza zatwierdzenie swojej transakcji. Ta dodatkowa runda zwiększa opóźnienie aplikacji. Procent wpływu zależy od aplikacji. Ten proces potwierdzenia nie czeka na zastosowanie dzienników do serwera rezerwowego. Serwer zapasowy jest trwale w trybie odzyskiwania, dopóki nie zostanie awansowany.
Sprawdzanie kondycji
Elastyczne monitorowanie kondycji serwera okresowo sprawdza kondycję podstawową i rezerwową. Po wykonaniu wielu prób pingowania, jeśli monitorowanie kondycji wykryje, że serwer podstawowy nie jest osiągalny, usługa następnie inicjuje automatyczne przełączenie na serwer rezerwowy. Algorytm monitorowania kondycji jest oparty na wielu punktach danych, aby uniknąć fałszywie dodatnich sytuacji.
Tryby awaryjne
Serwer elastyczny obsługuje dwa tryby przełączania awaryjnego: planowane przełączanie awaryjne i nieplanowane przełączanie awaryjne. W obu trybach po zerwaniu replikacji serwer zapasowy uruchamia odzyskiwanie, zanim zostanie awansowany na serwer główny i otwiera się na odczyt i zapis. Dzięki automatycznym wpisom DNS zaktualizowanym przy użyciu nowego podstawowego punktu końcowego serwera aplikacje mogą łączyć się z serwerem przy użyciu tego samego punktu końcowego. Nowy serwer rezerwowy jest ustanawiany w tle, aby aplikacja mogła zachować łączność.
Stan wysokiej dostępności
Kondycja serwerów podstawowych i rezerwowych jest stale monitorowana, a odpowiednie działania są podejmowane w celu rozwiązania problemów, w tym wyzwolenia trybu failover na serwerze rezerwowym. W poniższej tabeli wymieniono możliwe stany wysokiej dostępności:
| Stan | Opis |
|---|---|
| Inicjowanie | W procesie tworzenia nowego serwera rezerwowego. |
| Replikowanie danych | Po utworzeniu instancji rezerwowej następuje nadganianie do głównego systemu. |
| Zdrowy | Replikacja znajduje się w stanie ustalonym i jest w dobrym stanie. |
| Przełączanie w tryb failover | Serwer baz danych przełącza się na serwer zapasowy. |
| Usuwanie trybu czuwania | W procesie usuwania serwera rezerwowego. |
| Nie włączono | Wysoka dostępność nie jest włączona. |
Uwaga
Wysoką dostępność można włączyć podczas tworzenia serwera lub w późniejszym czasie. Jeśli włączasz lub wyłączasz wysoką dostępność podczas etapu po utworzeniu, zaleca się działanie, gdy podstawowa aktywność serwera jest niska.
Operacje w stanie stabilnym
Aplikacje klienckie PostgreSQL są połączone z serwerem podstawowym przy użyciu nazwy serwera BAZY danych. Odczyty aplikacji są obsługiwane bezpośrednio z serwera podstawowego. Jednocześnie zatwierdzenia i zapisy są potwierdzane w aplikacji dopiero po utrwałości danych dziennika zarówno na serwerze podstawowym, jak i w repliki rezerwowej. Ze względu na tę dodatkową rundę aplikacje mogą oczekiwać podwyższonego opóźnienia dla zapisów i zatwierdzeń. Kondycję wysokiej dostępności można monitorować w portalu.
- Klienci łączą się z serwerem elastycznym i wykonują operacje zapisu.
- Zmiany są replikowane do lokacji rezerwowej.
- Element podstawowy otrzymuje potwierdzenie.
- Zapisy/zatwierdzenia są potwierdzane.
Przywracanie do stanu z określonego momentu serwerów wysokiej dostępności
W przypadku serwerów elastycznych skonfigurowanych z wysoką dostępnością dane dziennika są replikowane w czasie rzeczywistym do serwera rezerwowego. Wszelkie błędy użytkownika na serwerze podstawowym — takie jak przypadkowe usunięcie tabeli lub niepoprawne aktualizacje danych, są replikowane do repliki rezerwowej. W związku z tym nie można użyć trybu wstrzymania w celu odzyskania sprawności po takich błędach logicznych. Aby odzyskać dane po takich błędach, należy wykonać przywracanie punktowe z kopii zapasowej. Korzystając z funkcji przywracania stanu serwera elastycznego do określonego punktu w czasie, można przywrócić stan z chwili przed wystąpieniem błędu. Nowy serwer bazy danych jest przywracany jako serwer elastyczny z jedną strefą z nową nazwą serwera udostępnianego przez użytkownika dla baz danych skonfigurowanych z wysoką dostępnością. Możesz użyć przywróconego serwera w kilku przypadkach użycia:
Przywrócony serwer można użyć do produkcji i opcjonalnie włączyć wysoką dostępność z repliką rezerwową w tej samej strefie lub innej strefie w tym samym regionie.
Jeśli chcesz przywrócić obiekt, wyeksportuj go z przywróconego serwera bazy danych i zaimportuj go do produkcyjnego serwera bazy danych.
Jeśli chcesz sklonować serwer bazy danych na potrzeby testowania i rozwoju lub przywrócić do innych celów, możesz wykonać przywracanie do wybranego punktu w czasie.
Aby dowiedzieć się, jak przeprowadzić przywracanie do punktu w czasie serwera elastycznego, zobacz Przywracanie do punktu w czasie serwera elastycznego.
Obsługa trybu failover
Planowane przejście w tryb failover
Zdarzenia planowanych przestojów obejmują zaplanowane okresowe aktualizacje oprogramowania platformy Azure i uaktualnienia wersji pomocniczej. Możesz również użyć planowanego trybu failover, aby przywrócić serwer podstawowy do preferowanej strefy dostępności. Po skonfigurowaniu wysokiej dostępności te operacje są najpierw stosowane do repliki rezerwowej, podczas gdy aplikacje nadal uzyskują dostęp do serwera podstawowego. Po zaktualizowaniu repliki rezerwowej połączenia serwera podstawowego są opróżniane, a tryb failover zostanie wyzwolony, co aktywuje replikę rezerwową jako podstawową o tej samej nazwie serwera bazy danych. Aplikacje klienckie muszą ponownie łączyć się z tą samą nazwą serwera bazy danych na nowym serwerze podstawowym i mogą wznowić operacje. Nowy serwer rezerwowy jest ustanawiany w tej samej strefie co stary serwer podstawowy.
W przypadku innych operacji inicjowanych przez użytkownika, takich jak skalowanie zasobów obliczeniowych lub skalowanie magazynu, zmiany są najpierw stosowane na zapasowym, a następnie na głównym. Obecnie usługa nie jest przełączona na tryb rezerwowy, dlatego podczas wykonywania operacji skalowania na serwerze podstawowym aplikacje napotykają krótki przestój.
Za pomocą tej funkcji można również przełączyć się na tryb awaryjny na serwer rezerwowy, ograniczając przestoje. Na przykład główny system może znajdować się w innej strefie dostępności niż aplikacja, po nieplanowanym przełączeniu awaryjnym. Chcesz przywrócić serwer podstawowy do poprzedniej strefy, aby współlokalizować go z aplikacją.
Podczas wykonywania tej funkcji serwer rezerwowy jest najpierw przygotowany, aby upewnić się, że zsynchronizował się z najnowszymi transakcjami, co pozwala aplikacji na kontynuowanie wykonywania operacji odczytu/zapisu. Następnie zapasowy jest promowany, a połączenia z podstawowym są przerywane. Aplikacja może nadal zapisywać dane na serwerze podstawowym, gdy w tle jest ustanawiany nowy serwer rezerwowy. Poniżej przedstawiono kroki związane z zaplanowanym przejściem w tryb failover:
| Krok | Opis | Oczekiwano przestoju aplikacji? |
|---|---|---|
| 1 | Poczekaj, aż serwer rezerwowy nadrobi różnice względem serwera podstawowego. | Nie. |
| 2 | Wewnętrzny system monitorowania inicjuje przepływ pracy w trybie awaryjnym. | Nie. |
| 3 | Zapisy aplikacji są blokowane, gdy serwer rezerwowy znajduje się w pobliżu podstawowego numeru sekwencji dziennika (LSN). | Tak |
| 4 | Serwer rezerwowy jest promowany jako niezależny serwer. | Tak |
| 5 | Rekord DNS jest aktualizowany przy użyciu nowego adresu IP serwera rezerwowego. | Tak |
| 6 | Aplikacja do ponownego nawiązywania połączenia i wznawiania jego odczytu/zapisu przy użyciu nowego podstawowego elementu. | Nie. |
| 7 | Zostanie ustanowiony nowy serwer rezerwowy w innej strefie. | Nie. |
| 8 | Serwer rezerwowy zaczyna odzyskiwać dzienniki (z usługi Azure Blob), których nie odzyskał podczas jego konfiguracji. | Nie. |
| 9 | Jest ustanawiany stały stan między serwerem podstawowym a serwerem rezerwowym. | Nie. |
| 10 | Planowany proces failover został ukończony. | Nie. |
Przestój aplikacji rozpoczyna się w kroku 3 i może wznowić operację po kroku 5. Pozostałe kroki są wykonywane w tle bez wpływu na operacje zapisu i zatwierdzeń aplikacji.
Napiwek
Dzięki serwerowi elastycznemu możesz opcjonalnie zaplanować działania konserwacyjne inicjowane przez platformę Azure, wybierając 60-minutowe okno w dniu preferencji, w którym działania w bazach danych powinny być niskie. Zadania konserwacji platformy Azure, takie jak stosowanie poprawek lub uaktualnienia wersji pomocniczej, miały miejsce w tym oknie. Jeśli nie wybierzesz niestandardowego okna czasowego, dla serwera zostanie przydzielone 1-godzinne okno pomiędzy 23:00 a 7:00 czasu lokalnego. Te działania konserwacji inicjowane przez platformę Azure są również wykonywane w repliki rezerwowej dla serwerów elastycznych skonfigurowanych ze strefami dostępności.
Aby uzyskać listę możliwych planowanych przestojów, zobacz Planowane przestoje.
Nieplanowana awaria failover
Nieplanowane przestoje mogą wystąpić w wyniku nieprzewidzianych zakłóceń, takich jak błędy sprzętowe, problemy z siecią i błędy oprogramowania. Jeśli serwer bazy danych skonfigurowany z wysoką dostępnością niespodziewanie ulegnie awarii, replika rezerwowa zostanie aktywowana, a klienci mogą wznowić operacje. Jeśli nie skonfigurowano wysokiej dostępności, to jeśli próba ponownego uruchomienia zakończy się niepowodzeniem, nowy serwer bazy danych zostanie automatycznie aprowizowany. Chociaż nie można uniknąć nieplanowanego przestoju, serwer elastyczny pomaga zmniejszyć przestój, automatycznie wykonując operacje odzyskiwania bez konieczności interwencji człowieka.
Aby uzyskać informacje na temat niezaplanowanych przełączeń awaryjnych i przestojów, w tym możliwych scenariuszy, zobacz Ograniczanie nieplanowanych przestojów.
Testy przełączenia awaryjnego (wymuszone przełączenie awaryjne)
W przypadku wymuszonego przejścia w tryb failover można symulować nieplanowany scenariusz awarii podczas uruchamiania obciążenia produkcyjnego i obserwować przestoje aplikacji. Możesz również użyć wymuszonego przełączenia awaryjnego, gdy serwer podstawowy przestanie odpowiadać.
Wymuszone przejście w tryb failover powoduje wyłączenie serwera podstawowego i inicjuje przepływ pracy trybu failover, w którym jest wykonywana operacja podwyższania poziomu wstrzymania. Po zakończeniu procesu odzyskiwania do momentu ostatnich zatwierdzonych danych, serwer zapasowy zostanie awansowany do roli serwera podstawowego. Rekordy DNS są aktualizowane, a aplikacja może nawiązać połączenie z promowanym serwerem podstawowym. Aplikacja może nadal zapisywać dane na serwerze podstawowym, gdy nowy serwer rezerwowy jest ustanowiony w tle, co nie ma wpływu na czas pracy.
Poniżej przedstawiono kroki podczas wymuszonego przejścia w tryb failover:
| Krok | Opis | Oczekiwano przestoju aplikacji? |
|---|---|---|
| 1 | Serwer podstawowy zostaje zatrzymany wkrótce po otrzymaniu żądania przełączenia awaryjnego. | Tak |
| 2 | Aplikacja napotyka przestój, ponieważ serwer podstawowy nie działa. | Tak |
| 3 | Wewnętrzny system monitorowania wykrywa awarię i inicjuje przejście w tryb failover na serwer rezerwowy. | Tak |
| 4 | Serwer rezerwowy przechodzi w tryb odzyskiwania przed pełnym przekształceniem jako niezależny serwer. | Tak |
| 5 | Proces trybu failover czeka na zakończenie odzyskiwania rezerwowego. | Tak |
| 6 | Po uruchomieniu serwera rekord DNS jest aktualizowany przy użyciu tej samej nazwy hosta, ale przy użyciu adresu IP rezerwowego. | Tak |
| 7 | Aplikacja może ponownie nawiązać połączenie z nowym serwerem podstawowym i wznowić operację. | Nie. |
| 8 | Jest ustanawiany serwer rezerwowy w preferowanej strefie. | Nie. |
| 9 | Serwer rezerwowy zaczyna odzyskiwać dzienniki (z usługi Azure Blob), których nie odzyskał podczas jego konfiguracji. | Nie. |
| 10 | Jest ustanawiany stały stan między serwerem podstawowym a serwerem rezerwowym. | Nie. |
| 11 | Proces wymuszonego przejścia w tryb failover został ukończony. | Nie. |
Oczekuje się, że przestój aplikacji rozpocznie się po kroku 1 i będzie się powtarzać do momentu ukończenia kroku 6. Pozostałe kroki są wykonywane w tle bez wpływu na operacje zapisu i zatwierdzeń aplikacji.
Ważne
Cały proces failover obejmuje (a) przełączanie na serwer rezerwowy po awarii serwera głównego i (b) ustanowienie nowego serwera rezerwowego w stanie stabilnym. Ponieważ Twoja aplikacja doświadcza przestoju aż do zakończenia przełączenia na tryb zapasowy, zmierz przestój z perspektywy swojej aplikacji/klienta zamiast ogólnego końcowego procesu przełączania.
Zagadnienia dotyczące przeprowadzania wymuszonego failoveru
Całkowity czas operacji końcowej może być postrzegany jako dłuższy niż rzeczywisty czas przestoju, którego doświadcza aplikacja.
Ważne
Zawsze obserwuj przestój z perspektywy aplikacji!
Nie wykonuj natychmiastowych operacji powrotu do trybu failover. Odczekaj co najmniej 15–20 minut między przełączeniami awaryjnymi, umożliwiając całkowite uruchomienie nowego serwera rezerwowego.
Zaleca się przeprowadzenie wymuszonego przejścia w tryb failover w okresie niskiej aktywności w celu zmniejszenia przestoju.
Najlepsze praktyki dotyczące statystyk PostgreSQL po przełączeniu awaryjnym
Po przejściu w tryb failover bazy danych PostgreSQL podstawowy mechanizm utrzymania optymalnej wydajności bazy danych obejmuje zrozumienie odrębnych ról pg_statistic i tabel pg_stat_* . Tabela pg_statistic zawiera statystyki optymalizatora, które mają kluczowe znaczenie dla planisty zapytań. Te statystyki obejmują dystrybucje danych w tabelach i pozostają nienaruszone po przejściu w tryb failover, zapewniając, że planista zapytań może nadal efektywnie optymalizować wykonywanie zapytań na podstawie dokładnych, historycznych informacji o dystrybucji danych.
Natomiast tabele pg_stat_*, które rejestrują statystyki aktywności, takie jak liczba skanowań, krotki odczytane i aktualizacje, są resetowane po przełączeniu awaryjnym. Przykładem takiej tabeli jest pg_stat_user_tables, która śledzi aktywność tabel zdefiniowanych przez użytkownika. To resetowanie jest przeznaczone do dokładnego odzwierciedlenia stanu operacyjnego nowego głównego węzła, ale także oznacza utratę historycznych metryk aktywności, które mogą informować o procesie autovacuum i innych efektywnościach operacyjnych.
Biorąc pod uwagę to rozróżnienie, najlepszym rozwiązaniem po przejściu w tryb failover bazy danych PostgreSQL jest uruchomienie polecenia ANALYZE. Ta akcja aktualizuje tabelę pg_stat_*, taką jak pg_stat_user_tables, o najnowsze statystyki aktywności, wspomagając proces automatycznego oczyszczania i zapewniając, że wydajność bazy danych pozostaje optymalna w nowej roli. Ten proaktywny krok łączy lukę między zachowaniem podstawowych statystyk optymalizatora i odświeżaniem metryk aktywności w celu dostosowania ich do bieżącego stanu bazy danych.
Doświadczenie obniżenia strefy
Strefowe: Aby odzyskać sprawność po awarii na poziomie strefy, możesz wykonać przywracanie punktu w czasie przy użyciu kopii zapasowej. Możesz wybrać niestandardowy punkt przywracania z najnowszym czasem, aby przywrócić najnowsze dane. Nowy serwer elastyczny jest wdrażany w innej strefie, której nie dotyczy problem. Czas potrzebny na przywrócenie zależy od poprzedniej kopii zapasowej i ilości dzienników transakcji do odzyskania.
Aby uzyskać więcej informacji o przywracaniu punktowym, zobacz Kopie zapasowe i przywracanie w usłudze Azure Database for PostgreSQL-Flexible Server.
Strefowo nadmiarowy: serwer elastyczny jest automatycznie przełączony w tryb failover na serwer rezerwowy w ciągu 60–120 sekund z zerową utratą danych.
Konfiguracje bez stref dostępności
Mimo że nie jest to zalecane, można skonfigurować serwer elastyczny bez włączonej wysokiej dostępności. W przypadku serwerów elastycznych skonfigurowanych bez wysokiej dostępności usługa zapewnia magazyn lokalnie nadmiarowy z trzema kopiami danych, strefowo nadmiarową kopią zapasową (w regionach, w których jest obsługiwana) i wbudowaną odporność serwera, aby automatycznie ponownie uruchomić serwer, który uległ awarii i przenieść serwer do innego węzła fizycznego. Umowa SLA na czas działania na poziomie 99,9% jest oferowana w tej konfiguracji. Jeśli serwer ulegnie awarii podczas planowanych lub nieplanowanych zdarzeń trybu failover, usługa utrzymuje dostępność serwerów przy użyciu następującej procedury zautomatyzowanej:
- Aprowizowana jest nowa maszyna wirtualna obliczeniowa z systemem Linux.
- Magazyn z plikami danych zostaje przypisany do nowej maszyny wirtualnej.
- Silnik bazy danych PostgreSQL został uruchomiony na nowej maszynie wirtualnej.
Na poniższej ilustracji przedstawiono przejście od maszyny wirtualnej do awarii pamięci masowej.
Odzyskiwanie po awarii między regionami i ciągłość działania
W przypadku awarii obejmującej cały region platforma Azure może zapewnić ochronę przed awariami regionalnymi lub dużymi lokalizacjami geograficznymi z odzyskiwaniem po awarii, korzystając z innego regionu. Aby uzyskać więcej informacji na temat architektury odzyskiwania po awarii platformy Azure, zobacz Architekturę odzyskiwania po awarii w ramach platformy Azure.
Serwer elastyczny udostępnia funkcje, które chronią dane i zmniejszają przestoje baz danych o znaczeniu krytycznym podczas planowanych i nieplanowanych zdarzeń przestojów. Oparta na infrastrukturze platformy Azure, która oferuje niezawodną odporność i dostępność, serwer elastyczny oferuje funkcje ciągłości działania, które zapewniają ochronę przed błędami, spełniają wymagania dotyczące czasu odzyskiwania i zmniejszają narażenie na utratę danych. Podczas tworzenia architektury aplikacji należy wziąć pod uwagę tolerancję przestojów — cel czasu odzyskiwania (RTO) i narażenie na utratę danych — cel punktu odzyskiwania (RPO). Na przykład baza danych o krytycznym znaczeniu dla działania firmy wymaga bardziej rygorystycznego czasu pracy niż testowa baza danych.
Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów
Geograficznie zduplikowana kopia zapasowa i przywracanie
Georedundantne tworzenie kopii zapasowych i przywracanie zapewnia możliwość przywrócenia serwera w innym regionie w przypadku katastrofy. Zapewnia również co najmniej 99,99999999999999 procent (16 dziewiątek) trwałości obiektów kopii zapasowych w ciągu roku.
Geograficznie nadmiarowa kopia zapasowa może być skonfigurowana tylko w momencie tworzenia serwera. Po skonfigurowaniu serwera z georedundantną kopią zapasową, dane kopii zapasowej i dzienniki transakcji są kopiowane do sparowanego regionu asynchronicznie poprzez replikację pamięci.
Aby uzyskać więcej informacji na temat geograficznie nadmiarowej kopii zapasowej i przywracania, zobacz geograficznie nadmiarowe kopie zapasowe i przywracanie.
Repliki do odczytu
Repliki odczytu między regionami można wdrożyć w celu ochrony baz danych przed awariami na poziomie regionu. Repliki do odczytu są aktualizowane asynchronicznie przy użyciu technologii replikacji fizycznej bazy danych PostgreSQL i mogą opóźniać technologię replikacji podstawowej. Repliki do odczytu są obsługiwane w warstwie obliczeniowej o ogólnym przeznaczeniu oraz zoptymalizowanej pod kątem pamięci.
Aby uzyskać więcej informacji na temat funkcji i zagadnień dotyczących replik do odczytu, zobacz Read replicas (Repliki do odczytu).
Wykrywanie, powiadamianie i zarządzanie awariami
Jeśli serwer jest skonfigurowany z geograficznie nadmiarową kopią zapasową, możesz wykonać przywracanie geograficzne w sparowanym regionie. Nowy serwer jest aprowizowany i przywracany do ostatnich dostępnych danych skopiowanych do tego regionu.
Można również użyć replik do odczytu w różnych regionach. W przypadku awarii regionu można wykonać operację odzyskiwania po awarii, promując replikę do odczytu jako autonomiczny serwer do odczytu i zapisu. Oczekuje się, że RPO wyniesie do 5 minut (możliwa utrata danych), z wyjątkiem przypadków poważnej awarii regionalnej, kiedy RPO może być bliskie opóźnieniu replikacji w momencie awarii.
Aby uzyskać więcej informacji na temat nieplanowanego ograniczania przestojów i odzyskiwania po regionalnej awarii, zobacz Nieplanowane środki zaradcze dotyczące przestojów.