Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano wysoką dostępność w usłudze Azure Database for PostgreSQL, która obejmuje strefy dostępności i odzyskiwanie między regionami oraz 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 obsługuje wysoką dostępność przez aprowizowanie fizycznie rozdzielonych replik podstawowych i rezerwowych w tej samej strefie dostępności (strefowo) lub między strefami dostępności (strefach nadmiarowych). Ten model wysokiej dostępności został zaprojektowany w celu zapewnienia, że zatwierdzone dane nigdy nie zostaną utracone podczas 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.
Usługa Azure Database for PostgreSQL obsługuje zarówno modele strefowo nadmiarowe, 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. Zapasowość strefowa zapewnia najwyższy poziom dostępności, ale należy skonfigurować zapasowość 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 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, znane również jako 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.
Nadmiarowość strefowa nie jest obsługiwana dla:
Warstwa obliczeniowa o zmiennej wydajności
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. jeśli wystąpią jakiekolwiek zakłócenia na serwerze podstawowym, następuje automatyczne przełączenie serwera na replikę zapasową.
Opcja wdrożenia strefowego jest dostępna we wszystkich regionach świadczenia usługi Azure, w których można wdrożyć serwer elastyczny.
Uwaga / Notatka
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.
Konfigurowanie odporności strefowej w portalu
Można skonfigurować wysoką dostępność na dwa sposoby: jako HA o odporności na awarie strefowe, która umieszcza serwer zapasowy w innej strefie dostępności, aby zapewnić maksymalną odporność, lub jako HA w tej samej strefie, co serwer podstawowy, aby zminimalizować opóźnienia.
Aby uprościć konfigurację i zapewnić odporność strefową, portal zapewnia opcję odporności strefowej z dwoma przyciskami radiowymi: Włączone i Wyłączone. Wybranie pozycji Włączone próbuje utworzyć serwer rezerwowy w innej strefie dostępności (tryb strefowo nadmiarowej wysokiej dostępności). Jeśli region nie obsługuje wysokiej dostępności z nadmiarowością strefową, możesz zaznaczyć pole wyboru zapasowe (wyróżnione na poniższej ilustracji), aby włączyć wysoką dostępność w tej samej strefie.
Gdy wybierzesz pole wyboru opcji awaryjnej, system tworzy serwer zapasowy w tej samej strefie. Jeśli pojemność strefowa stanie się dostępna w przyszłości, platforma Azure powiadomi Cię, aby umożliwić migrację do konfiguracji wysokiej dostępności z nadmiarowością strefową przy użyciu funkcjonalności PITR lub replik do odczytu. Jeśli nie zaznaczysz pola wyboru, a pojemność strefowa jest niedostępna, włączenie wysokiej dostępności nie powiedzie się. Ten projekt wymusza zonową nadmiarową HA jako wartość domyślną, zapewniając jednocześnie kontrolowane przejście awaryjne dla tej samej strefy HA, dzięki czemu obciążenia w końcu osiągną pełną odporność strefową bez ręcznej interwencji.
Funkcje wysokiej dostępności
Replika zapasowa jest wdrażana w tej samej konfiguracji maszyny wirtualnej, obejmującej rdzenie wirtualne, magazyn i ustawienia sieciowe, tak jak serwer podstawowy.
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 podstawowy serwer bazy danych okresowo wykonuje automatyczne kopie zapasowe. W tym samym czasie replika rezerwowa stale archiwizuje dzienniki transakcji w magazynie zapasowym. 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.
Możesz ponownie uruchomić serwer, aby pobrać wszelkie zmiany parametrów serwera statycznego.
Okresowe działania konserwacyjne, takie jak uaktualnienia wersji pomocniczej, są wykonywane najpierw w stanie wstrzymania. Aby zmniejszyć przestoje, zapasowy jest promowany do podstawowego, dzięki czemu obciążenia mogą być kontynuowane podczas wykonywania zadań konserwacyjnych w pozostałym węźle.
Uwaga / Notatka
Aby zapewnić prawidłowe funkcje wysokiej dostępności, skonfiguruj wartości parametrów max_replication_slots i max_wal_senders serwera. Wysoka dostępność wymaga czterech z nich do obsługi trybu failover i bezproblemowych uaktualnień. W przypadku konfiguracji wysokiej dostępności z pięcioma replikami do odczytu i 12 gniazdami replikacji logicznej ustaw zarówno wartości parametrów max_replication_slots, jak i max_wal_senders na 21. Ta konfiguracja jest niezbędna, ponieważ każda replika do odczytu i każde miejsce replikacji logicznej wymaga jednego elementu, a dodatkowe cztery są potrzebne do zapewnienia wysokiej dostępności. Aby uzyskać więcej informacji na temat max_replication_slots parametrów i max_wal_senders , zapoznaj się z dokumentacją.
Monitorowanie kondycji wysokiej dostępności
Monitorowanie stanu zdrowia wysokiej dostępności (HA) w usłudze Azure Database for PostgreSQL zapewnia ciągły przegląd kondycji i gotowości instancji z włączoną funkcją HA. Ta funkcja monitorowania stosuje platformę Azure Resource Health Check (RHC) w celu 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, tryb failover i zdrowie replikacji danych, monitorowanie kondycji HA umożliwia aktywne rozwiązywanie problemów i pomaga zapewnić dostępność i wydajność bazy danych.
Monitorowanie stanu zdrowia systemów wysokiej dostępności (HA):
- 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 dla terminowych powiadomień o wszelkich zmianach stanu wysokiej dostępności, dzięki czemu możesz przygotować się do natychmiastowego przeciwdziałania potencjalnym zakłóceniom.
- 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, zobacz Monitorowanie stanu kondycji wysokiej dostępności (HA) dla usługi Azure Database for PostgreSQL.
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.
Nie można użyć repliki rezerwowej na potrzeby zapytań odczytu.
W zależności od zarówno obciążenia, jak i działania na serwerze podstawowym, proces przełączenia awaryjnego może trwać dłużej niż 120 sekund, ponieważ replika zapasowa musi zakończyć odzyskiwanie, zanim będzie mogła zostać zdysponowana jako główna.
Serwer rezerwowy zwykle odzyskuje pliki WAL o rozmiarze 40 MB/s. W przypadku większych wersji 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.
Nie można skonfigurować dodatkowego zapasu.
Nie można zaplanować zadań zarządzania zainicjowanych przez klienta podczas okna konserwacji zarządzanej.
Planowane zdarzenia, takie jak skalowanie obliczeń i skalowanie magazynu, są wykonywane najpierw w rezerwie, a następnie na serwerze podstawowym. Obecnie serwer nie jest w trybie failover dla tych planowanych operacji.
Jeśli skonfigurujesz dekodowanie logiczne lub replikację logiczną na elastycznym serwerze z wysoką dostępnością:
- W PostgreSQL 16 i wcześniejszych wersjach, miejsca replikacji logicznej nie są domyślnie zachowywane na serwerze rezerwowym po przełączeniu awaryjnym.
- Aby zapewnić, że replikacja logiczna będzie nadal działać po awarii, należy włączyć rozszerzenie
pg_failover_slotsi skonfigurować ustawienia pomocnicze, takie jakhot_standby_feedback = on. - Począwszy od bazy danych PostgreSQL 17, synchronizacja miejsc jest obsługiwana natywnie. Jeśli włączysz prawidłowe konfiguracje bazy danych PostgreSQL (
sync_replication_slots,hot_standby_feedback), miejsca replikacji logicznej są zachowywane automatycznie po przejściu w tryb failover i nie jest wymagane żadne rozszerzenie. - Aby uzyskać informacje o krokach konfiguracji i wymaganiach wstępnych, sprawdź dokumentację rozszerzenia PG_Failover_Slots.
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 ramach sieci wirtualnej (obejmującej strefy dostępności w regionie) lub dostęp publiczny z prywatnymi punktami końcowymi.
Strefy dostępności można skonfigurować tylko w jednym regionie. Nie można skonfigurować stref dostępności w różnych regionach.
SLA
Model strefowy oferuje gwarantowany czas działania na poziomie SLA wynoszącym około 99,95%.
Model redundancji strefowej oferuje czas działania SLA wynoszący około 99,99%.
Tworzenie usługi Azure Database for PostgreSQL z włączoną strefą dostępności
Aby dowiedzieć się, jak utworzyć bazę danych Azure Database for PostgreSQL w celu zapewnienia wysokiej dostępności ze strefami dostępności, zobacz Szybki start: tworzenie bazy danych Azure Database for PostgreSQL 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
Transakcja aplikacji wyzwala zapis i zatwierdzenie, które najpierw loguje się do pliku WAL na serwerze podstawowym. Serwer podstawowy przesyła strumieniowo te dzienniki do serwera rezerwowego przy użyciu protokołu przesyłania strumieniowego Postgres. Gdy magazyn serwera rezerwowego utrwali dzienniki, serwer podstawowy potwierdza ukończenie zapisu. Aplikacja zatwierdza swoją transakcję dopiero po tym potwierdzeniu. 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 rezerwowy pozostaje w trybie odzyskiwania do momentu uzyskania wyższego statusu.
Sprawdzanie kondycji
Monitorowanie kondycji serwera elastycznego okresowo sprawdza kondycję zarówno serwerów podstawowych, jak i rezerwowych. Po wielokrotnym wysłaniu poleceń ping, jeśli monitorowanie kondycji wykryje, że serwer podstawowy nie jest osiągalny, usługa inicjuje automatyczne przełączenie awaryjne na serwer rezerwowy. Algorytm monitorowania kondycji używa wielu punktów 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 przerwaniu replikacji, serwer rezerwowy uruchamia proces odzyskiwania danych przed przełączeniem na podstawowy, otwiera się na operacje odczytu i zapisu. 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
System stale monitoruje kondycję serwerów podstawowych i rezerwowych. Podejmuje odpowiednie działania, aby rozwiązać problemy, w tym wyzwalanie trybu failover na serwerze rezerwowym. W poniższej tabeli wymieniono możliwe stany wysokiej dostępności:
| Status | 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 / Notatka
Wysoką dostępność można włączyć podczas tworzenia serwera lub w późniejszym czasie. Jeśli włączysz lub wyłączysz wysoką dostępność podczas etapu po utworzeniu, zrób to, gdy aktywność serwera podstawowego jest niska.
Operacje w stanie stabilnym
Aplikacje klienckie PostgreSQL łączą się z serwerem podstawowym przy użyciu nazwy serwera BAZY danych. Serwer podstawowy bezpośrednio obsługuje odczyty aplikacji. Jednocześnie aplikacja otrzymuje potwierdzenie zatwierdzeń i zapisów tylko po tym, jak dane dziennika są utrwalane 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 i 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ą system replikuje dane dziennika w czasie rzeczywistym do serwera rezerwowego. Wszelkie błędy użytkownika na serwerze podstawowym — takie jak przypadkowe usunięcie tabeli lub nieprawidłowe aktualizacje danych — są replikowane do repliki rezerwowej. W związku z tym nie można użyć trybu rezerwowego, aby odzyskać dane po takich błędach logicznych. Aby odzyskać dane po takich błędach, trzeba wykonać przywrócenie z określonego punktu w czasie z kopii zapasowej. Korzystając z możliwości przywrócenia stanu serwera elastycznego do określonego punktu w czasie, można przywrócić system do momentu sprzed wystąpienia 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:
Użyj przywróconego serwera w środowisku produkcyjnym i opcjonalnie włącz wysoką dostępność z repliką rezerwową w tej samej strefie lub w 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. Podczas konfigurowania wysokiej dostępności te operacje są najpierw stosowane do repliki rezerwowej, podczas gdy aplikacje nadal uzyskują dostęp do serwera podstawowego. Po aktualizacji repliki rezerwowej proces opróżnia podstawowe połączenia serwera i wyzwala tryb failover, który aktywuje replikę rezerwową jako serwer podstawowy o tej samej nazwie serwera bazy danych. Aplikacje klienckie ponownie łączą się z tą samą nazwą serwera bazy danych na nowym serwerze podstawowym i mogą wznowić operacje. Proces ustanawia nowy serwer rezerwowy 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, proces najpierw stosuje zmiany w rezerwie, a następnie podstawowe. Obecnie usługa nie przełącza się na tryb awaryjny w stanie gotowości. W związku z tym, podczas gdy operacja skalowania jest uruchamiana 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 serwer podstawowy może znajdować się w innej strefie dostępności niż aplikacja po nieplanowanym przejściu w tryb failover. Chcesz przywrócić serwer podstawowy do poprzedniej strefy, aby współlokalizować go z aplikacją.
Po wykonaniu tej funkcji proces najpierw przygotowuje serwer rezerwowy, aby upewnić się, że dogoni ostatnie transakcje, dzięki czemu aplikacja będzie nadal wykonywać operacje odczytu i zapisu. Proces wspiera stan gotowości i rozłącza połączenia z systemem głównym. Twoja aplikacja może nadal zapisywać dane na serwerze głównym, podczas gdy proces w tle ustanawia nowy serwer rezerwowy. W poniższej tabeli opisano kroki związane z zaplanowanym przejściem w tryb failover:
| Step | Opis | Oczekiwano przestoju aplikacji? |
|---|---|---|
| 1 | Poczekaj, aż serwer rezerwowy nadrobi zaległości w stosunku do 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 ponownie łączy się i wznawia odczyt/zapis z nowym serwerem podstawowym. | 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ę od kroku 3 i może wznowić działanie po kroku 5. Pozostałe kroki są wykonywane w tle bez wpływu na operacje zapisu i zatwierdzeń aplikacji.
Wskazówka
Dzięki serwerowi elastycznemu możesz opcjonalnie zaplanować działania konserwacyjne inicjowane przez platformę Azure, wybierając 60-minutowe okno w dniu preferencji, gdy działania w bazach danych powinny być niskie. W tym oknie są wykonywane zadania konserwacji platformy Azure, takie jak stosowanie poprawek lub uaktualnienia wersji pomocniczej. Jeśli nie wybierzesz okna niestandardowego, system przydziela jednogodzinne okno między 11:00 a 7:00 czasu lokalnego dla serwera. Te działania konserwacyjne inicjowane przez platformę Azure również są 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.
Nieplanowane przełączanie awaryjne
Nieplanowane przestoje mogą wystąpić w wyniku nieprzewidzianych zakłóceń, takich jak podstawowe 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, proces aktywuje replikę rezerwowa, a klienci mogą wznowić operacje. Jeśli nie skonfigurujesz wysokiej dostępności i próba ponownego uruchomienia zakończy się niepowodzeniem, proces automatycznie aprowizuje nowy serwer bazy danych. Chociaż nie można uniknąć nieplanowanego przestoju, serwer elastyczny pomaga ograniczyć przestoje, 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.
Testowanie trybu awaryjnego (wymuszone przełączenie)
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 czasu ostatniego zatwierdzonego danych zostanie on podwyższony do poziomu 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.
W poniższej tabeli opisano kroki podczas wymuszonego przejścia w tryb failover:
| Step | Opis | Oczekiwano przestoju aplikacji? |
|---|---|---|
| 1 | Serwer podstawowy przestaje działać krótko 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 proces aktualizuje rekord DNS przy użyciu tej samej nazwy hosta, ale używa 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. |
Przestój aplikacji rozpoczyna się po kroku 1 i trwa do momentu zakończenia kroku 6. Inne kroki są uruchamiane 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ż aplikacja powoduje przestój do czasu zakończenia przełączania na zapasowy serwer, zmierz przestój z perspektywy aplikacji/klienta zamiast całego procesu przełączania.
Zagadnienia dotyczące przeprowadzania wymuszonych przełączeń w tryb failover
Całkowity czas operacji end-to-end może być dłuższy niż rzeczywisty przestój spowodowany przez aplikację.
Ważne
Zawsze obserwuj przestój z perspektywy aplikacji!
Nie wykonuj natychmiastowych operacji powrotu do trybu failover. Poczekaj co najmniej 15–20 minut między przełączeniami awaryjnymi, aby nowy serwer rezerwowy mógł się w pełni ustabilizować.
Wykonaj wymuszone przełączenie awaryjne w okresie niskiej aktywności, aby zmniejszyć przestój.
Najlepsze praktyki dotyczące statystyk PostgreSQL po przełączeniu awaryjnym
Po przejściu w tryb failover bazy danych PostgreSQL utrzymanie optymalnej wydajności bazy danych obejmuje zrozumienie różnych ról pg_statistic i tabel pg_stat_* . Tabela pg_statistic przechowuje 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.
pg_stat_* Natomiast tabele, które rejestrują statystyki aktywności, takie jak liczba skanowań, krotki odczytane i aktualizacje, są resetowane po przejściu w tryb failover. Przykładem takiej tabeli jest pg_stat_user_tables, która śledzi aktywność tabel zdefiniowanych przez użytkownika. To resetowanie dokładnie odzwierciedla stan operacyjny nowego głównego elementu, 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, uruchom polecenie ANALYZE po przejściu w tryb failover bazy danych PostgreSQL. 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
Strefowy: Aby odzyskać dane po awarii na poziomie strefy, możesz wykonać przywracanie do 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 automatycznie przechodzi 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 lokalnie nadmiarowy magazyn 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. Ta konfiguracja oferuje umowę SLA dotycząca dostępności na poziomie 99,9%. 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ższym obrazku przedstawiono etapy przejścia między maszyną wirtualną a awarią pamięci masowej.
Odzyskiwanie po awarii między regionami i ciągłość działania
Jeśli wystąpi awaria w całym regionie, 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 dla 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
Georedundantne kopie zapasowe i przywracanie
Kopie zapasowe z geograficzną redundancją i przywracanie dają możliwość przywrócenia serwera w innym regionie w przypadku wystąpienia awarii. Zapewnia również co najmniej 99,99999999999999 procent (16 dziewiątek) trwałości obiektów kopii zapasowych w ciągu roku.
Geograficznie nadmiarowe kopie zapasowe można skonfigurować tylko podczas tworzenia serwera. Podczas konfigurowania serwera z geograficznie nadmiarową kopią zapasową dane kopii zapasowej i dzienniki transakcji są kopiowane do sparowanego regionu asynchronicznie za pomocą replikacji danych.
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 wdrażać, aby chronić bazy danych przed awariami regionalnymi. Repliki do odczytu są aktualizowane asynchronicznie przy użyciu technologii replikacji fizycznej PostgreSQL i mogą mieć opóźnienia względem podstawowej. Warstwy obliczeniowe ogólnego przeznaczenia i zoptymalizowane pod kątem pamięci obsługują repliki do odczytu.
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 skonfigurujesz serwer przy użyciu geograficznie nadmiarowej kopii zapasowej, 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. Jeśli wystąpi awaria regionu, możesz przeprowadzić operację odzyskiwania danych po awarii, promując replikę do odczytu danych, aby stała się autonomicznym serwerem do odczytu i zapisu. Oczekuje się, że cel punktu odzyskiwania będzie wynosił do 5 minut (możliwa utrata danych), z wyjątkiem sytuacji poważnej awarii regionalnej, kiedy cel punktu odzyskiwania może być zbliżony do opóźnienia replikacji w chwili 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.