Niezawodność w usłudze Azure Database for PostgreSQL

Azure Database for PostgreSQL to w pełni zarządzana usługa bazy danych, która zapewnia szczegółową kontrolę i elastyczność funkcji zarządzania bazami danych oraz ustawień konfiguracji. Usługa zapewnia funkcje wysokiej dostępności i odzyskiwania po awarii na podstawie Twoich wymagań.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak zwiększyć odporność usługi Azure Database for PostgreSQL na różne potencjalne awarie i problemy, w tym błędy przejściowe, awarie stref dostępności, awarie regionów i prace konserwacyjne usługi. W tym artykule opisano również, jak można używać kopii zapasowych do odzyskiwania po innych typach problemów, oraz wyróżnia kluczowe informacje o umowie dotyczącej poziomu usług (SLA) Azure Database for PostgreSQL.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć Azure Database for PostgreSQL w celu obsługi wymagań dotyczących niezawodności rozwiązania oraz jak niezawodność wpływa na inne aspekty architektury, zobacz Najlepsze rozwiązania dotyczące architektury dla Azure Database for PostgreSQL w przewodniku Azure Well-Architected Framework.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Podczas pracy z Azure Database for PostgreSQL należy wdrożyć serwer, który reprezentuje zasoby obliczeniowe i magazynowe wymagane do obsługi baz danych wdrażanych na serwerze.

Serwery można wdrażać w wielu klasach obliczeniowych: Burstable, Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci. Każda warstwa jest zoptymalizowana pod kątem różnych rodzajów obciążeń. W niektórych regionach świadczenia usługi Azure można wdrażać serwery za pomocą usługi Azure Confidential Computing.

Aby uzyskać więcej informacji na temat ogólnej architektury usług i modeli wdrażania, zobacz Azure Database for PostgreSQL omówienie.

Architektura fizyczna

• Separacja zasobów obliczeniowych i magazynowania: Usługa Azure Database for PostgreSQL używa architektury separacji zasobów obliczeniowych i magazynu do obsługi wysokiej dostępności. Aparat bazy danych działa na maszynie wirtualnej z systemem Linux, podczas gdy Azure Storage przechowuje pliki danych i przechowuje trzy lokalnie nadmiarowe synchroniczne kopie plików bazy danych w celu zapewnienia trwałości danych.

• Wysoka dostępność: Konfigurację wysokiej dostępności można włączyć na serwerze. Po włączeniu konfiguracji wysokiej dostępności usługa aprowizuje i utrzymuje ciepły serwer rezerwowy. Serwer podstawowy synchronicznie replikuje zmiany danych na serwerze rezerwowym w celu zapewnienia zerowej utraty danych podczas awarii serwera podstawowego.

  Architektura oddziela warstwę obliczeniową od warstwy magazynu, aby usługa mogła odpowiednio obsługiwać różne typy awarii. Aby zapewnić większą odporność, można rozłożyć serwery w różnych strefach dostępności.

  

  Diagram przedstawiający architekturę wysokiej dostępności dla Azure Database for PostgreSQL. Dwa serwery są obok siebie. Po lewej stronie znajduje się pole z etykietą serwer podstawowy, a wewnątrz tego pola jest maszyna wirtualna i dysk. Po prawej stronie znajduje się odpowiadające pole z etykietą „standby server”, które również zawiera maszynę wirtualną i dysk. Pozioma strzałka prowadzi od serwera podstawowego po lewej stronie do serwera zapasowego po prawej stronie, a strzałka jest opisana jako „replikacja strumieniowa”, co wskazuje na jednokierunkową relację, w której zmiany danych są przesyłane z serwera podstawowego do serwera zapasowego.

  Serwer rezerwowy jest wdrażany w tej samej konfiguracji maszyny wirtualnej co serwer podstawowy, w tym rdzenie wirtualne, magazyn i ustawienia sieciowe.

  Możesz przełączać się między serwerami, wykonując przełączenie awaryjne (failover). Istnieją dwa typy trybu failover: wymuszone przejścia w tryb failover, które są używane w przypadku awarii serwera podstawowego i planowane przejścia w tryb failover, które są używane podczas niektórych operacji konserwacji i w innych scenariuszach, w których należy zminimalizować przestoje aplikacji podczas pracy w trybie failover.

  Podczas wykonywania operacji, takich jak zatrzymywanie, uruchamianie i ponowne uruchamianie, są one wykonywane zarówno na serwerach podstawowej, jak i rezerwowej bazy danych w tym samym czasie. Planowane zdarzenia, takie jak skalowanie zasobów obliczeniowych 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.

  Aby uzyskać więcej informacji, zobacz Wysoka dostępność w usłudze Azure Database for PostgreSQL.

• Kopie zapasowe: Usługa Azure Database for PostgreSQL automatycznie tworzy kopie zapasowe serwera. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Aplikacje muszą obsługiwać przejściowe błędy łączności, które mogą wystąpić podczas konserwacji, operacji skalowania lub przerw w działaniu sieci. Postępuj zgodnie z następującymi zaleceniami:

Aby uzyskać więcej informacji, zobacz Obsługa przejściowych błędów łączności w usłudze Azure Database for PostgreSQL.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Wybierz typ obsługi strefy dostępności za pomocą konfiguracji wysokiej dostępności. Po włączeniu wysokiej dostępności usługa wdraża serwer rezerwowy wraz z serwerem podstawowym. Ten model wysokiej dostępności pomaga zagwarantować, że zatwierdzone dane nigdy nie zostaną utracone podczas awarii. Niezależnie od używanego modelu wdrażania o wysokiej dostępności serwer synchronicznie zatwierdza dane zarówno na serwerach podstawowych, jak i rezerwowych. W przypadku wystąpienia zakłóceń na serwerze podstawowym serwer automatycznie przechodzi w tryb failover na serwer rezerwowy.

Każda strefa dostępności przechowuje pliki danych i dzienniki zapisu z wyprzedzeniem (WAL) na dyskach zarządzanych Premium z lokalnie nadmiarową pamięcią masową (LRS), która automatycznie przechowuje trzy kopie danych w obrębie każdej strefy.

Usługa Azure Database for PostgreSQL obsługuje dwa typy konfiguracji strefy dostępności w przypadku korzystania z wysokiej dostępności:

• Wysoka dostępność strefowo nadmiarowa: Nadmiarowość strefy zapewnia najwyższy poziom odporności strefy przez wdrożenie serwera podstawowego w jednej strefie dostępności i serwera rezerwowego w innej strefie dostępności. Serwer rezerwowy używa konfiguracji obliczeniowej, magazynu i sieci podobnej do konfiguracji serwera podstawowego. Konfiguracja strefowo nadmiarowa zapewnia fizyczną izolację całego stosu między serwerami podstawowymi i rezerwowymi.

  Możesz wybrać strefy dostępności dla serwerów podstawowych i rezerwowych lub zezwolić firmie Microsoft na ich wybranie.

  Zalecamy wdrożenia strefowo nadmiarowe dla serwerów produkcyjnych.

  

  Diagram przedstawiający strefowo nadmiarową konfigurację Azure Database for PostgreSQL rozmieszczoną w różnych strefach dostępności. Trzy strefy są wymienione na górze: strefa dostępności 1, strefa dostępności 2 i strefa dostępności 3. W strefie dostępności 1 znajduje się ramka oznaczona jako „serwer podstawowy”, a wewnątrz tej ramki znajdują się maszyna wirtualna i dysk, co pokazuje, że serwer podstawowy składa się z zasobów obliczeniowych i pamięci masowej. W strefie dostępności 2 znajduje się odpowiadające mu pole oznaczone etykietą „serwer zapasowy”, które również zawiera maszynę wirtualną i dysk. Między tymi dwoma blokami serwera znajduje się strzałka skierowana w prawo z etykietą „replikacja strumieniowa”, pokazująca, że zmiany danych przepływają z serwera podstawowego po lewej stronie do serwera zapasowego po prawej stronie. Układ wskazuje na odporność między strefami: zasoby podstawowe i zapasowe są rozmieszczone w dwóch różnych strefach dostępności, podczas gdy strefa dostępności 3 pozostaje niewykorzystana.

  Operacje zapisu mogą mieć niewielki wzrost opóźnienia zatwierdzania, ponieważ usługa synchronicznie replikuje dane do serwera rezerwowego. Wpływ zależy od obciążenia, wybranej jednostki SKU i regionu.

• Wysoka dostępność strefowa (ta sama strefa): Serwery podstawowe i rezerwowe używają tej samej strefy dostępności. W przypadku wystąpienia zakłóceń na serwerze podstawowym, ale strefa jest nadal w dobrej kondycji, serwer automatycznie przechodzi w tryb failover na serwer rezerwowy. Wdrożenie strefowe zapewnia wysoką dostępność w jednej strefie dostępności. Chroni przed awariami na poziomie węzła, a także pomaga zmniejszyć przestoje aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Jednak nie chroni przed awarią w tej strefie.

  

  Diagram przedstawiający strefową konfigurację Azure Database for PostgreSQL w pojedynczej strefie dostępności. Wyświetlane są trzy strefy: strefa dostępności 1, strefa dostępności 2 i strefa dostępności 3. W strefie dostępności 1 znajdują się obok siebie dwa pudełka. Pole po lewej stronie jest oznaczone etykietą serwer podstawowy, a wewnątrz tego pola jest maszyna wirtualna i dysk. Pole po prawej stronie ma etykietę Serwer rezerwowy, a wewnątrz tego pola jest maszyna wirtualna i dysk. Między tymi dwoma blokami serwera znajduje się strzałka skierowana w prawo z etykietą „replikacja strumieniowa”, pokazująca, że zmiany danych przepływają z serwera podstawowego po lewej stronie do serwera zapasowego po prawej stronie. Oba serwery znajdują się w tej samej strefie dostępności. Strefa dostępności 2 i strefa dostępności 3 nie są używane.

  Wysoka dostępność strefowa (w tej samej strefie) jest dostępna tylko w następujących sytuacjach:

  • Region nie obsługuje stref dostępności. Region skutecznie działa jako jedna strefa, więc jedyną konfiguracją wysokiej dostępności, którą można wybrać, jest ta sama strefa.
  • Jeśli region nie ma wystarczającej pojemności dla wdrożenia strefowo nadmiarowego, usługa może początkowo umieścić oba serwery w tej samej strefie dostępności, a następnie automatycznie migrować je do oddzielnych stref, gdy pojemność stanie się dostępna. Ta opcja jest dostępna w przypadku wdrażania serwera przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Konfigurowanie opcji Krytyczne dla działania firmy (wysoka dostępność).

  Umieszczenie serwerów w tej samej strefie może zmniejszyć opóźnienie zapisu do aplikacji wdrażanych w tej samej strefie.

  Gdy serwery znajdują się w tej samej strefie, można zmniejszyć opóźnienie zapisu w aplikacjach wdrażanych w tej samej strefie.

Jeśli skonfigurujesz serwer bez wysokiej dostępności, zostanie on uruchomiony na jednym serwerze. Jeśli ten serwer lub jego strefa ulegnie awarii, serwer jest niedostępny. Aby uzyskać więcej informacji, zobacz Konfiguracje bez stref dostępności.

Wymagania

• Obsługa regionów: Azure Database for PostgreSQL obsługuje konfiguracje stref dostępności w różnych regionach Azure. Pełną listę regionów, rodzaje obsługi stref dostępności oraz wszelkie szczególne kwestie dotyczące poszczególnych regionów można znaleźć w artykule Regiony platformy Azure.

• Warstwa obliczeniowa: W poniższej tabeli wymieniono obsługę warstwy obliczeniowej dla każdego typu obsługi strefy dostępności:

  Poziom obliczeniowy	Nadmiarowość strefowa	Strefa strefowa (ta sama strefa)
  Z możliwością zwiększania wydajności	Niewspierane	Niewspierane
  Ogólnego przeznaczenia	Wsparte	Wsparte
  Zoptymalizowana pamięć	Wsparte	Wsparte

• Warstwa usługi: Oba typy wysokiej dostępności wymagają warstwy Ogólnego przeznaczenia lub Zoptymalizowanej pod kątem pamięci.

Zagadnienia do rozważenia

Pojemność regionu: Jeśli region nie ma wystarczającej pojemności dla wdrożenia strefowo nadmiarowego, usługa może początkowo umieścić oba serwery w tej samej strefie dostępności i automatycznie migrować je do oddzielnych stref, gdy pojemność stanie się dostępna. Ta opcja jest dostępna w przypadku wdrażania serwera przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Konfigurowanie opcji Krytyczne dla działania firmy (wysoka dostępność).

Koszt

Po włączeniu wysokiej dostępności tworzony jest serwer rezerwowy i jest rozliczany według tej samej stawki co serwer podstawowy. Konfiguracja strefy dostępności nie ma wpływu na koszt. Nie są naliczane opłaty za replikację danych w ramach stref dostępności lub między nimi. W zależności od woluminu magazynu kopii zapasowych mogą być również naliczane opłaty za magazyn kopii zapasowych. Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Database for PostgreSQL.

Konfiguruj obsługę stref dostępności

Aby skonfigurować obsługę strefy dostępności dla serwera, skonfiguruj ustawienia wysokiej dostępności.

• Utwórz serwer strefowo nadmiarowy: Aby dowiedzieć się, jak utworzyć serwer z włączoną wysoką dostępnością i nadmiarowością stref, zobacz Szybki start: tworzenie serwera Azure Database for PostgreSQL.

• Zmień konfigurację strefy dostępności dla istniejących serwerów: Zmień konfigurację strefy dostępności dla istniejących serwerów, zmieniając ustawienia wysokiej dostępności. Aby uzyskać szczegółowe instrukcje, zobacz Włączanie wysokiej dostępności dla istniejących serwerów.

  Nie można zmienić strefy używanej dla serwera podstawowego lub rezerwowego. Należy ponownie utworzyć serwer.

  Wskazówka

  Zalecamy poczekanie na niską aktywność serwera przed zmianą konfiguracji wysokiej dostępności.

• Wyłącz wysoką dostępność: Wyłączenie wysokiej dostępności spowoduje usunięcie serwera rezerwowego, więc serwer nie jest odporny na awarie w strefie dostępności. Aby uzyskać więcej informacji, zobacz Wyłączanie wysokiej dostępności.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można się spodziewać podczas konfigurowania serwerów z zapewnieniem wysokiej dostępności i obsługą stref dostępności, gdy wszystkie strefy dostępności są dostępne.

• Operacja między strefami: Aplikacje klienckie PostgreSQL łączą się z serwerem podstawowym przy użyciu nazwy serwera bazy danych. Azure Database for PostgreSQL używa konfiguracji aktywne-pasywne, w której serwer podstawowy w podstawowej strefie dostępności obsługuje wszystkie połączenia i zapytania bazy danych. Serwer rezerwowy nie obsługuje ruchu klienta podczas normalnych operacji.

• Replikacja danych między strefami: Serwer podstawowy synchronicznie replikuje zmiany na serwerze rezerwowym. Transakcje nie są uznawane za ukończone, dopóki serwery podstawowe i rezerwowe nie uznają zapisu.

  Gdy aplikacja zapisuje i zatwierdza dane, usługa PostgreSQL najpierw rejestruje zmianę w pliku WAL na serwerze podstawowym. Serwer podstawowy przesyła strumieniowo te dzienniki do serwera rezerwowego przy użyciu protokołu przesyłania strumieniowego PostgreSQL. Gdy serwer rezerwowy trwale przechowuje plik WAL, serwer podstawowy potwierdza zapis. Aplikacja zatwierdza swoją transakcję dopiero po tym potwierdzeniu. Ten proces potwierdzenia nie czeka na zastosowanie dzienników do serwera rezerwowego.

  Skutki replikacji różnią się w zależności od konfiguracji strefy dostępności używanej przez serwer:

  • Strefowo nadmiarowy: Ponieważ serwery znajdują się w oddzielnych strefach, takie podejście zapewnia zerową utratę danych podczas awarii strefy. Taka sytuacja jest również czasami nazywana osiągnięciem celu punktu odzyskiwania (RPO) zerowego w przypadku awarii strefy.

    Jednak replikacja między strefami może spowodować niewielkie opóźnienie. Wpływ opóźnienia zależy od aplikacji. W przypadku większości aplikacji dodatkowe opóźnienie jest niewielkie.

  • Strefowe: ponieważ oba serwery znajdują się w tej samej strefie, żaden ruch nie jest replikowany między strefami.

  Uwaga / Notatka

  System replikuje dane dziennika w czasie rzeczywistym do serwera rezerwowego. Wszelkie błędy użytkownika na serwerze podstawowym, takie jak przypadkowy spadek tabeli lub nieprawidłowe aktualizacje danych, są replikowane do serwera rezerwowego. Nie można użyć trybu rezerwowego do odzyskania po tego rodzaju błędach i należy wykonać przywracanie do punktu w czasie z kopii zapasowej. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania serwerów z obsługą wysokiej dostępności i stref dostępności, gdy dojdzie do awarii strefy dostępności.

• Wykrywanie i reagowanie: Platforma Azure 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.

  Jeśli strefa dostępności ulegnie awarii, zachowanie różni się w zależności od konfiguracji strefy dostępności używanej przez serwer:

  • Strefowo nadmiarowy: Usługa Azure Database for PostgreSQL automatycznie wykrywa błędy strefy dostępności. Aby wyświetlić możliwe typy statusów wysokiej dostępności, zobacz Monitorowanie statusu kondycji wysokiej dostępności (HA). Gdy strefa ulegnie awarii, platforma Azure inicjuje wymuszone przejście w tryb failover na serwer rezerwowy bez konieczności podejmowania akcji.

  • Strefowego: Jeśli strefa dostępności, która hostuje serwer strefowy, stanie się niedostępna, zarówno serwery podstawowe, jak i rezerwowe są niedostępne. W tym scenariuszu usługa nie zapewnia automatycznego przełączania awaryjnego. Odpowiadasz za wykrywanie awarii strefy i wykonywanie akcji odzyskiwania, takich jak przywracanie kopii zapasowych strefowo nadmiarowych do oddzielnego serwera w innej strefie dostępności lub regionie.

• Powiadomienie: Monitorowanie stanu wysokiej dostępności w usłudze Azure Database for PostgreSQL zapewnia ciągły wgląd w stan i gotowość instancji z włączoną wysoką dostępnością. Funkcja monitorowania jest oparta na usłudze Azure Resource Health i może wykrywać i ostrzegać o wszelkich problemach, które mogą mieć wpływ na gotowość bazy danych do trybu failover lub ogólną dostępność. Oceń kluczowe metryki, takie jak stan połączenia, stan trybu failover i kondycja replikacji danych, aby umożliwić proaktywne rozwiązywanie problemów i pomóc zachować czas pracy i wydajność bazy danych.

  Szczegółowe informacje na temat konfigurowania i interpretowania statusów kondycji HA można znaleźć w artykule Monitorowanie statusów kondycji wysokiej dostępności (HA).

• Aktywne żądania: Gdy strefa dostępności stanie się niedostępna, wszelkie żądania w toku do serwerów w strefie, której dotyczy problem, mogą zostać zakończone. Aplikacje muszą ponowić próbę wykonania tych żądań. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

• Oczekiwana utrata danych: Ilość utraty danych zależy od konfiguracji strefy dostępności używanej przez serwer.

  • Strefowo nadmiarowy: Oczekuje się zerowej utraty danych podczas awarii strefy dzięki synchronicznej replikacji między serwerami podstawowym i rezerwowym w różnych strefach.

  • Strefowego: Dane na serwerach w strefie, której dotyczy problem, są niedostępne do momentu odzyskania strefy.

• Oczekiwany przestój: Czas przestoju zależy od konfiguracji strefy dostępności używanej przez serwer.

  • Redundancja strefowa: Tryb failover zazwyczaj kończy się w ciągu 60–120 sekund. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

  • Strefa: Serwery w strefie objętej awarią są niedostępne do czasu przywrócenia działania strefy dostępności.

• Redystrybucja: Przekierowanie ruchu zależy od konfiguracji strefy dostępności wykorzystywanej przez serwer.

  • Strefowo nadmiarowy: Po przejściu w tryb failover były serwer rezerwowy staje się nowym serwerem podstawowym i rozpoczyna akceptowanie nowych połączeń. Platforma Azure automatycznie ustanawia nowy serwer zapasowy w oryginalnej strefie podstawowej po zakończeniu odzyskiwania. Aby uzyskać szczegółowe informacje, zobacz Wymuszone przejście w tryb failover.

  • Strefowy: Gdy strefa jest niedostępna, serwer również jest niedostępny. Jeśli masz oddzielny serwer utworzony z wyprzedzeniem w innej strefie dostępności lub regionie, odpowiadasz za przekierowywanie ruchu do tego serwera.

Odzyskiwanie strefy

Zachowanie mechanizmu odzyskiwania strefy zależy od konfiguracji strefy dostępności używanej przez twój serwer.

• Strefowo nadmiarowy: Po odzyskaniu strefy dostępności usługa Azure Database for PostgreSQL automatycznie ponownie kompiluje serwer zapasowy w odzyskanej strefie i synchronizuje go z aktualnym serwerem podstawowym. Odzyskana strefa służy następnie jako lokalizacja rezerwowa. Aby uniknąć niepotrzebnych zakłóceń, usługa nie przenosi automatycznie roli podstawowej z powrotem do oryginalnej strefy. Możesz ręcznie zainicjować planowane przejście w tryb failover , jeśli chcesz zwrócić element podstawowy do oryginalnej strefy.

• Strefa: Gdy strefa jest w dobrej kondycji, serwery w strefie są ponownie dostępne. Jesteś odpowiedzialny za wszelkie procedury odzyskiwania poszczególnych stref oraz synchronizację danych, jakie wymagają twoje obciążenia.

Testowanie pod kątem niepowodzeń strefy

Opcje testowania błędów strefy zależą od konfiguracji strefy dostępności używanej przez wystąpienie.

• Strefowa nadmiarowość: Odporność aplikacji na przełączanie awaryjne można przetestować, rozpoczynając wymuszone przełączanie awaryjne. Wymuszone przełączenie awaryjne umożliwia symulowanie nieplanowanej sytuacji awaryjnej podczas pracy z obciążeniem i obserwowanie czasu przestoju aplikacji. Zalecamy uruchamianie symulacji w środowisku nieprodukcyjnym lub w cichym czasie. Aby uzyskać więcej informacji, zobacz Inicjowanie wymuszonego przejścia w tryb failover.

• Strefowego: Chociaż nie można symulować awarii pełnej strefy, możesz symulować niedostępność serwera w sposób podobny do awarii strefy. Aby uzyskać więcej informacji, zobacz Zatrzymywanie obliczeń serwera.

Odporność na awarie całego regionu

Usługa Azure Database for PostgreSQL obsługuje repliki do odczytu między regionami, których można użyć do obsługi zsynchronizowanej kopii bazy danych w innym regionie w celu szybszego odzyskiwania.

Możesz również użyć geograficznie nadmiarowych kopii zapasowych w obsługiwanych regionach, aby zapewnić odzyskiwanie między regionami. Jednak kopie zapasowe zwykle obejmują więcej przestojów i utraty danych niż replikacja. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie.

Repliki do odczytu między regionami

Repliki do odczytu można wdrożyć, aby chronić bazy danych przed awariami na poziomie regionu. Każda replika do odczytu jest oddzielnym serwerem usługi Azure Database for PostgreSQL. W przypadku umieszczenia repliki do odczytu w drugim regionie świadczenia usługi Azure serwer bazy danych może zapewnić odporność na problem obejmujący cały region. Można wdrożyć maksymalnie pięć replik do odczytu, które opcjonalnie mogą znajdować się w różnych regionach świadczenia usługi Azure. Technologia replikacji fizycznej bazy danych PostgreSQL aktualizuje repliki do odczytu asynchronicznie i mogą opóźnić replikację podstawową. Repliki do odczytu obejmujące wiele regionów mogą opcjonalnie obsługiwać obciążenia tylko do odczytu, aby zmniejszyć opóźnienia dla globalnie rozproszonych aplikacji lub odciążyć ruch odczytu z serwera podstawowego. Aby uzyskać więcej informacji na temat funkcji i zagadnień dotyczących replik do odczytu, zobacz Read replicas (Repliki do odczytu).

Wirtualne punkty końcowe zapewniają punkty końcowe do odczytu i zapisu oraz tylko do odczytu i automatycznie przekierowują ruch w przypadku awansu repliki, co pomaga zminimalizować przestoje podczas zdarzeń przełączenia awaryjnego. Zdecydowanie zalecamy używanie wirtualnych punktów końcowych z replikami odczytu między regionami w celu zwiększenia odporności aplikacji. Aby uzyskać więcej informacji, zobacz Virtual endpoints for read replicas in Azure Database for PostgreSQL (Wirtualne punkty końcowe dla replik do odczytu w usłudze Azure Database for PostgreSQL).

Jeśli region podstawowy ulegnie awarii, możesz wyzwolić podwyższenie poziomu , aby replika pomocnicza stała się podstawową. Różne typy przełączania awaryjnego mogą być właściwe w zależności od tego, jak używasz replik do odczytu. W przypadku używania replik do odczytu, aby zapewnić odporność na awarie regionów, zazwyczaj stosuje się podejście podniesienia do głównego serwera, które aktualizuje wirtualny punkt końcowy. Podczas awarii regionu należy przeprowadzić wymuszoną promocję, co może spowodować utratę danych niereplikowanych. W planowanych scenariuszach, w których region podstawowy jest w dobrej kondycji, można wybrać zaplanowaną promocję, aby uniknąć utraty danych. Aby uzyskać więcej informacji, zobacz Promowanie replik odczytu w usłudze Azure Database for PostgreSQL.

Wymagania

• Obsługa regionów: Repliki do odczytu między regionami można tworzyć w dowolnym regionie obsługującym usługę Azure Database for PostgreSQL. Nie jesteś ograniczony do sparowanych regionów platformy Azure.

• Warstwy obliczeniowe: Warstwy obliczeniowe do ogólnego przeznaczenia oraz zoptymalizowane pod kątem pamięci obsługują repliki odczytu. Warstwa z możliwością rozszerzenia nie obsługuje replik do odczytu.

Zagadnienia do rozważenia

• Różnice konfiguracji: Repliki do odczytu mogą nie dziedziczyć wszystkich ustawień konfiguracji z serwera podstawowego. Zaplanuj skonfigurowanie niezbędnych ustawień po przejściu w tryb failover. Serwer podstawowy i repliki powinny być symetryczne, co oznacza, że muszą mieć te same warstwy, rozmiary magazynu i wartości niektórych ustawień. Podczas awarii regionów wymagania dotyczące serwera symetrycznego można pominąć w przypadku wymuszonych promocji, ale dobrym rozwiązaniem jest posiadanie symetrycznej konfiguracji, jeśli jest to możliwe, aby uniknąć nieoczekiwanych problemów. Aby uzyskać więcej informacji, zobacz Zarządzanie konfiguracją.

• Monitorowanie opóźnienia replikacji: Proces replikacji asynchronicznej wymaga opóźnienia replikacji, które może się różnić w zależności od wielu czynników. Gdy opóźnienie replikacji jest wysokie, serwer może napotkać problemy. Ważne jest, aby monitorować opóźnienie replikacji, aby można było rozwiązać problemy przed ich eskalacją. Aby uzyskać więcej informacji, zobacz Monitorowanie replikacji.

• Wysoka dostępność: Repliki do odczytu nie mogą mieć włączonej wysokiej dostępności, a po podwyższeniu poziomu nie mają również wysokiej dostępności. Odpowiadasz za konfigurowanie wysokiej dostępności po rozmieszczeniu repliki.

Aby zapoznać się z innymi czynnikami dotyczącymi procesu podwyższania poziomu, zobacz Zagadnienia.

Koszt

Repliki do odczytu generują koszty mocy obliczeniowej i magazynowania oraz opłaty za transfer danych między regionami związane z replikacją. Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Database for PostgreSQL i Cennik przepustowości.

Konfigurowanie obsługi wielu regionów

• Utwórz replikę do odczytu: Aby dowiedzieć się, jak utworzyć replikę do odczytu, zobacz Tworzenie repliki do odczytu. Repliki można skonfigurować po utworzeniu serwera podstawowego, o ile serwer podstawowy jest uruchomiony i dostępny.

  Aby utworzyć wirtualny punkt końcowy, zobacz Tworzenie wirtualnych punktów końcowych.

• Usuń replikę do odczytu: Aby dowiedzieć się, jak usunąć replikę do odczytu, zobacz Usuwanie repliki do odczytu.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać po skonfigurowaniu replik do odczytu na serwerze w innym regionie oraz wirtualnego punktu końcowego, przy założeniu, że wszystkie regiony są operacyjne.

• Routing ruchu między regionami: W normalnych operacjach wirtualny punkt końcowy kieruje ruch dla punktu końcowego odczytu i zapisu do serwera podstawowego w regionie podstawowym. Jeśli używasz również endpointu tylko do odczytu w ramach wirtualnego endpointu, kieruje on ruch do repliki skonfigurowanej przez Ciebie.

• Replikacja danych między regionami: Repliki odczytu między regionami używają replikacji asynchronicznej, aby zminimalizować wpływ na wydajność serwera podstawowego. Opóźnienie replikacji zależy od wielu czynników, w tym obciążenia zapisu i opóźnienia między serwerem podstawowym a replikami. Opóźnienie replikacji zwykle trwa co najmniej kilka minut, ale może być dłuższe. Aby uzyskać więcej informacji, zobacz Monitorowanie replikacji.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego się spodziewać, gdy serwer zostanie skonfigurowany z repliką do odczytu w innym regionie oraz z wirtualnym punktem końcowym, a w regionie głównym wystąpi awaria:

• Wykrywanie i reagowanie: Jesteś odpowiedzialny za wykrycie awarii w regionie podstawowym i ręczne promowanie repliki do odczytu na nowy serwer podstawowy. Podczas awarii regionu należy przeprowadzić wymuszoną promocję, co powoduje utratę niereplikowanych danych.

  Ważna

  Odpowiadasz za wyzwalanie promocji. Platforma Azure nie promuje replik do odczytu automatycznie, nawet jeśli wystąpi awaria regionu.

  Aby uzyskać szczegółowe instrukcje inicjowania podwyższania poziomu, zobacz Przełączanie repliki do odczytu na podstawową.

• Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: Proces podwyższania poziomu pominie wszystkie aktywne połączenia z regionem podstawowym. Po zakończeniu procesu podwyższania poziomu aplikacje muszą ponowić próbę nawiązania połączeń z promowaną repliką.

• Oczekiwana utrata danych: W przypadku awarii regionu konieczne jest przeprowadzenie wymuszonej promocji, co powoduje trwałą utratę wszelkich niereplikowanych danych.

  Ilość utraty danych zależy od opóźnienia replikacji w momencie awarii. Opóźnienie replikacji zwykle trwa co najmniej kilka minut, ale może być dłuższe. Aby uzyskać więcej informacji, zobacz Monitorowanie replikacji.

• Oczekiwany przestój: Wymuszona rozproszona aktualizacja zwykle kończy się w ciągu 1–3 minut od momentu uruchomienia. Aplikacje mogą również wymagać ponownego nawiązania połączenia z prawidłowym punktem końcowym. Wirtualne punkty końcowe są aktualizowane w ramach procesu wymuszonej promocji. Aplikacje powinny honorować czas wygaśnięcia (TTL) rekordów DNS punktu końcowego, aby upewnić się, że szybko ponownie nawiążą połączenie z poprawną repliką po zakończeniu promowania.

• Przekierowywanie ruchu: Wirtualny punkt końcowy serwera automatycznie przekierowuje ruch aplikacji do nowej repliki podstawowej.

  Uwaga / Notatka

  Gdy replika do odczytu zostanie awansowana do roli serwera podstawowego, konfiguracja wysokiej dostępności nie jest na nim włączona. Należy ręcznie włączyć konfigurację wysokiej dostępności lub dodać ją do własnych procesów automatyzacji.

Odzyskiwanie regionów

Gdy używasz wirtualnych punktów końcowych, po odzyskaniu regionu podstawowego stary serwer podstawowy jest automatycznie konfigurowany jako replika do odczytu. Możesz wykonać kolejną promocję, aby przywrócić operacje podstawowe do preferowanego regionu podstawowego.

Testowanie pod kątem błędów regionów

Regularnie testuj procedury promowania repliki odczytowej, aby upewnić się, że stosowane procedury są poprawne oraz że możliwości systemu spełniają wymagania dotyczące docelowego czasu odtworzenia (RTO) i docelowego punktu odtworzenia (RPO).

Replikę do odczytu można awansować do roli serwera podstawowego w dowolnym momencie, nawet gdy wszystkie regiony są zdrowe. Do testowania:

• Możesz przeprowadzić wymuszone testowanie podwyższania poziomu. Zalecamy wykonanie tych testów w środowisku nieprodukcyjnym, ponieważ może to spowodować utratę danych. Wymuszone testowanie promocji pomaga symulować zachowania, które można zaobserwować podczas awarii regionu.
• W przypadku planowanej konserwacji lub scenariuszy testowania, w których chcesz uniknąć utraty danych, należy zamiast tego użyć planowanej promocji. Jednak planowana promocja jest zgodna z innym procesem niż podwyższenie poziomu podczas awarii regionu, więc może nie odzwierciedlać zachowania podczas rzeczywistej awarii regionu.

Aby uzyskać instrukcje krok po kroku, zobacz Przełączenie repliki odczytu na podstawową.

W ramach strategii odtwarzania po awarii regularnie przeprowadzaj pełne testy odtwarzania. Te ćwiczenia powinny obejmować weryfikację danych, testowanie funkcji aplikacji i udokumentowane procedury wycofywania.

Tworzenie kopii zapasowej i przywracanie

Azure Database for PostgreSQL automatycznie wykonuje kopię zapasową danych. Te kopie zapasowe umożliwiają odzyskiwanie danych do określonego punktu w czasie i pomagają chronić dane przed przypadkowym uszkodzeniem i usunięciem. Microsoft w pełni zarządza kopiami zapasowymi. Nie przerywają one dostępności serwera i obejmują zarówno pełne kopie zapasowe, jak i kopie zapasowe dziennika transakcji.

• Magazyn kopii zapasowych: W przypadku wdrożenia serwera w regionie ze strefami dostępności usługa przechowuje kopie zapasowe w magazynie strefowo nadmiarowym (ZRS), niezależnie od konfiguracji wysokiej dostępności serwera. W przypadku serwerów wdrożonych w regionach bez stref dostępności usługa przechowuje kopie zapasowe w magazynie lokalnie nadmiarowym (LRS).

  W sparowanych regionach platformy Azure podczas tworzenia serwera można skonfigurować magazyn kopii zapasowych nadmiarowy geograficznie, aby replikować kopie zapasowe do sparowanego regionu platformy Azure w celu dodatkowej ochrony przed awariami regionów. Usługa replikuje kopie zapasowe asynchronicznie.

  Domyślny okres przechowywania kopii zapasowych wynosi siedem dni, ale można przedłużyć okres przechowywania do 35 dni. Usługi Azure Backup można również używać do długoterminowego przechowywania ręcznych kopii zapasowych przez maksymalnie 10 lat. Wszystkie kopie zapasowe są szyfrowane.

• Przywracanie: Przywracanie na poziomie punktu w czasie umożliwia przywrócenie bazy danych do dowolnego momentu w okresie przechowywania kopii zapasowych. Proces przywracania tworzy nowy serwer bazy danych z nową nazwą serwera podaną przez użytkownika. Możesz użyć nowego serwera as-is lub skopiować z niego dane.

  Podczas przywracania geograficznie nadmiarowej kopii zapasowej należy utworzyć nowy serwer w sparowanym regionie.

  Ta funkcja jest przydatna do odzyskiwania po przypadkowych modyfikacjach danych, błędach aplikacji lub scenariuszach testowania.

W przypadku większości rozwiązań nie należy polegać wyłącznie na kopiach zapasowych. Zamiast tego skorzystaj z innych możliwości opisanych w tym przewodniku, aby spełnić wymagania dotyczące odporności. Jednak kopie zapasowe chronią przed pewnymi zagrożeniami, których nie zapewniają inne podejścia. Aby uzyskać więcej informacji, zobacz Co to jest nadmiarowość, replikacja i kopia zapasowa?.

Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej i przywracanie w usłudze Azure Database for PostgreSQL.

Odporność usługi na prace konserwacyjne

Azure Database for PostgreSQL automatycznie obsługuje krytyczne zadania obsługi, w tym stosowanie poprawek podstawowego sprzętu, systemu operacyjnego i aparatu bazy danych. Usługa obejmuje aktualizacje zabezpieczeń, aktualizacje oprogramowania i uaktualnienia wersji pomocniczej w ramach planowanej konserwacji.

Aby upewnić się, że serwer pozostaje dostępny podczas okien obsługi, postępuj zgodnie z następującymi zaleceniami:

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Azure Database for PostgreSQL zapewnia różne umowy SLA dotyczące dostępności, w zależności od konfiguracji serwera:

• Serwery skonfigurowane z wysoką dostępnością strefową nadmiarowością oferują gwarancję SLA dostępności na poziomie 99.99%.
• Serwery skonfigurowane ze strefową wysoką dostępnością oferują SLA dotyczący czasu działania na poziomie 99,95%.
• Serwery skonfigurowane bez wysokiej dostępności oferują SLA czasu pracy na poziomie 99,9%.

Treści powiązane

• Niezawodność platformy Azure
• Najlepsze rozwiązania dotyczące architektury dla usługi Azure Database for PostgreSQL
• Omówienie ciągłości działania za pomocą usługi Azure Database for PostgreSQL
• Odzyskiwanie po awarii geograficznej w Azure Database for PostgreSQL
• Skrypty programu Terraform do implementowania zasad odporności i możliwości odzyskiwania