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 i ustawień konfiguracji. Usługa zapewnia wysoką dostępność i możliwości odzyskiwania po awarii na podstawie 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 zapewnić odporność usługi Azure Database for PostgreSQL na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności, awarie regionów i konserwacja 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 niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure Database for PostgreSQL.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć usługę 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 usługi 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 usługą Azure Database for PostgreSQL należy wdrożyć serwer reprezentujący zasoby obliczeniowe i magazynowe wymagane do obsługi serwera bazy danych. Wdrażasz co najmniej jedną bazę danych na serwerze.

Serwery można wdrażać w wielu warstwach obliczeniowych: Tryb Wybuchowy, ogólnego przeznaczenia i Pamięciooptatyzowany, z których każda 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 Co to jest usługa Azure Database for PostgreSQL?.

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 pliki danych są przechowywane w usłudze Azure Storage, która utrzymuje trzy lokalnie nadmiarowe synchroniczne kopie plików bazy danych w celu zapewnienia trwałości danych.

• Wysoka dostępność: Opcjonalnie możesz włączyć konfigurację wysokiej dostępności na serwerze. Po włączeniu konfiguracji wysokiej dostępności usługa aprowizuje i utrzymuje ciepły serwer rezerwowy. Zmiany danych na serwerze podstawowym są synchronicznie replikowane do serwera rezerwowego w celu zapewnienia zerowej utraty danych podczas awarii serwera podstawowego.

  Architektura oddziela warstwę obliczeniową od warstwy magazynu, umożliwiając usłudze odpowiednie obsługę różnych typów awarii. Aby zapewnić większą odporność, można rozłożyć serwery w różnych strefach dostępności.

  

  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 przełączenia 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.

  Takie operacje jak zatrzymywanie, uruchamianie i ponowne uruchamianie są wykonywane jednocześnie na podstawowych i rezerwowych serwerach bazy danych. 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.

  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:

• Gdy aplikacja napotka błędy przejściowe, spróbuj ponownie wykonać operację przy użyciu wycofywania wykładniczego. Zwiększ opóźnienie między ponownymi próbami i ogranicz liczbę prób. Jeśli operacja nadal kończy się niepowodzeniem po maksymalnym ponawianiu prób, należy traktować ją jako błąd.
• Jeśli to możliwe, użyj bibliotek klienta (nazywanych również sterownikami), które automatycznie obsługują ponawianie prób.
• Błędy przejściowe występujące podczas operacji zapisu wymagają bardziej starannego rozważenia. Rozważ zmianę idempotentności operacji zapisu, aby można było je bezpiecznie wykonać wielokrotnie.

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.

Możesz wybrać typ obsługi strefy dostępności przez konfigurację wysokiej dostępności. Włączenie wysokiej dostępności umożliwia wdrożenie serwera rezerwowego wraz z serwerem podstawowym. Ten model wysokiej dostępności pomaga zagwarantować, że zatwierdzone dane nigdy nie zostaną utracone podczas awarii. Niezależnie od modelu wdrażania o wysokiej dostępności używanego przez serwer dane są synchronicznie zatwierdzane 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.

Pliki danych i dzienniki zapisu z wyprzedzeniem (WAL) są przechowywane na dyskach zarządzanych klasy Premium w ramach każdej strefy dostępności z lokalnie nadmiarowym przechowywaniem (LRS), które automatycznie przechowuje trzy kopie danych w każdej strefie.

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 podobnej konfiguracji obliczeniowej, magazynu i sieci do podstawowej. 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.

  

  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ć czas przestoju aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Jednak nie chroni przed awarią w tej strefie.

  

  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 pojedyncza strefa, dlatego 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 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ść).

  Dlatego że 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: Obsługa konfiguracji strefy dostępności usługi Azure Database for PostgreSQL różni się między regionami świadczenia usługi Azure. Aby zapoznać się z pełną listą regionów oraz typami obsługi stref dostępności i wszelkimi konkretnymi zagadnieniami dotyczącymi tego regionu, zobacz Regiony świadczenia usługi Azure.

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

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

• Warstwa usługi: Redundancja strefowa wymaga warstw General Purpose lub Memory Optimized.

  Wdrożenia strefowe (w tej samej strefie) są obsługiwane we wszystkich warstwach cenowych.

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 serwer rezerwowy jest tworzony i 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, należy skonfigurować ustawienia wysokiej dostępności.

• Utwórz serwer z nadmiarowością strefową: Aby dowiedzieć się, jak utworzyć serwer z zapewnioną wysoką dostępnością i nadmiarowością strefową, zobacz Rozpoczęcie pracy: tworzenie usługi Azure Database for PostgreSQL w portalu Azure.

• Zmień konfigurację strefy dostępności dla istniejących serwerów: Konfigurację strefy dostępności dla istniejących serwerów można zmienić, 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 po ich utworzeniu. Należy ponownie utworzyć serwer.

  Wskazówka

  Warto poczekać, aż aktywność serwera będzie niska, zanim zmienisz konfigurację 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 oczekiwać, gdy serwery są skonfigurowane z obsługą wysokiej dostępności oraz stref dostępności, a wszystkie strefy dostępności działają.

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

• Replikacja danych między strefami: Zmiany danych są replikowane synchronicznie między serwerami podstawowymi i rezerwowym. Transakcje nie są uznawane za ukończone, dopóki serwery podstawowe i rezerwowe nie uznają zapisu.

  Aplikacja, zainicjowana przez transakcję, dokonuje zapisu i zatwierdza pierwszy log do 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. 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 i dla większości aplikacji jest niewielki.

  • 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. W związku z tym 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ć po skonfigurowaniu serwerów z obsługą wysokiej dostępności i wsparciem dla stref dostępności, w przypadku wystąpienia 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.

  W przypadku awarii strefy 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 stanów wysokiej dostępności, zobacz Typy stanu wysokiej dostępności. 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: Ciągłe monitorowanie stanu zdrowia i gotowości instancji z włączoną funkcją wysokiej dostępności (HA) w usłudze Azure Database for PostgreSQL oferuje regularny przegląd ich kondycji. 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 pomaga zachować czas pracy i wydajność 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.

• 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.

  • Strefowy: Serwery w dotkniętej strefie są niedostępne do momentu przywrócenia 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, który został wstępnie utworzony 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. Usługa nie przenosi automatycznie roli podstawowej z powrotem do oryginalnej strefy, aby uniknąć niepotrzebnych zakłóceń. 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.

• Strefowy: Chociaż nie możesz przeprowadzić symulacji awarii całej strefy, możesz przeprowadzić symulację niedostępności serwera w sposób podobny do tego, co się dzieje podczas 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ą. Istnieją różne typy trybu failover, które można wyzwalać w zależności od sposobu używania 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.

Uwaga / Notatka

W tej sekcji podsumowano niektóre ważne informacje o tym, jak repliki do odczytu mogą obsługiwać odporność na awarie na poziomie całego regionu. Można również użyć replik do odczytu, aby zwiększyć wydajność i obsługiwać użytkowników geograficznie rozproszonych na dużą skalę. Aby uzyskać więcej informacji, zobacz Repliki do odczytu.

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 ograniczasz się 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 bardzo 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 uzyskać dodatkowe informacje dotyczące procesu promowania, zobacz Promocja replik do odczytu w usłudze Azure Database for PostgreSQL — zagadnienia.

Koszt

Kopie zapasowe do odczytu generują koszty przetwarzania i magazynowania, a także opłaty za transfer danych między regionami w celu replikacji. 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ż punktu końcowego tylko do odczytu wirtualnego, kieruje ruch do tej repliki, którą skonfigurujesz.

• 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ć znacznie 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: Wszystkie aktywne połączenia z regionem podstawowym są porzucane. Aplikacje muszą ponowić próbę nawiązania połączeń z promowaną repliką po zakończeniu procesu promocji.

• 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ć znacznie 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

  Po podwyższeniu poziomu repliki do odczytu jako serwera podstawowego nie ma włączonej konfiguracji wysokiej dostępności. 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 promocji repliki do odczytu, aby upewnić się, że procesy są prawidłowe i że możliwości spełniają wymagania dotyczące czasu odzyskania (RTO) i punktu odzyskiwania (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. Należy pamiętać, że planowana promocja przebiega inaczej niż promocja podczas przestoju w regionie.

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

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

Tworzenie kopii zapasowej i przywracanie

Usługa Azure Database for PostgreSQL automatycznie wykonuje kopie zapasowe, które zapewniają możliwości odzyskiwania do punktu w czasie i pomagają chronić cię przed przypadkowym uszkodzeniem i usunięciem danych. Kopie zapasowe są w pełni zarządzane przez firmę Microsoft, nie przerywają dostępności serwera i obejmują zarówno pełne kopie zapasowe, jak i kopie zapasowe dziennika transakcji.

• Magazyn kopii zapasowych: Jeśli serwer jest skonfigurowany z wysoką dostępnością strefową, kopie zapasowe są przechowywane w magazynie strefowo nadmiarowym (ZRS). W przypadku serwerów skonfigurowanych bez wysokiej dostępności lub z wysoką dostępnością w pojedynczej strefie, kopie zapasowe są przechowywane w magazynie lokalnie nadmiarowym (LRS).

  W regionach platformy Azure z parami, można podczas tworzenia serwera skonfigurować geograficznie nadmiarowy magazyn kopii zapasowych (GRS), aby replikować kopie zapasowe do sparowanego regionu Azure, zapewniając dodatkową ochronę przed awariami regionów. Kopie zapasowe są replikowane asynchronicznie.

  Domyślny okres przechowywania kopii zapasowych wynosi 7 dni, z opcją przedłużenia 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, z której można następnie użyć as-is lub skopiować 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

Usługa Azure Database for PostgreSQL automatycznie obsługuje krytyczne zadania obsługi, w tym stosowanie poprawek bazowego 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:

• Włącz wysoką dostępność: Podczas konserwacji może być konieczne ponowne uruchomienie serwera w ramach procesu aktualizacji. Jeśli włączono wysoką dostępność, operacje konserwacji zwykle używają aktualizacji rolowanych w celu zminimalizowania przestojów. Okresowe działania konserwacyjne, takie jak uaktualnienia pomniejszych wersji, są wykonywane najpierw w repliki zapasowej. 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. Sekwencjonowanie ma zastosowanie zarówno wtedy, gdy serwer wykorzystuje nadmiarowość strefową, jak i wtedy, gdy zapewnia wysoką dostępność strefową.

  W przypadku serwerów bez włączonej wysokiej dostępności należy oczekiwać krótkiego przestoju podczas operacji konserwacji. W przypadku włączenia wysokiej dostępności operacje konserwacji są zwykle wykonywane z minimalnym przestojem lub bez przestojów.

• Konfigurowanie niestandardowych okien obsługi: Harmonogram konserwacji można skonfigurować tak, aby był zarządzany przez system lub zdefiniować niestandardowe okno obsługi, aby zminimalizować wpływ na operacje biznesowe. Zaplanuj konserwację w okresach niskiej aktywności, aby zminimalizować wpływ na działalność biznesową. Aby uzyskać więcej informacji, zobacz Planowanie konserwacji.

• Implementowanie logiki ponawiania prób: Upewnij się, że aplikacje mogą obsługiwać krótkie przerwy w łączności, które mogą wystąpić podczas restartów związanych z konserwacją. Aby zapewnić odporność aplikacji na te typy problemów, zobacz Wskazówki dotyczące odporności na błędy przejściowe .

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.

Usługa Azure Database for PostgreSQL zapewnia różne umowy SLA dotyczące dostępności na podstawie konfiguracji serwera:

• Serwery skonfigurowane ze strefowo nadmiarową wysoką dostępnością.
• Serwery skonfigurowane z wysoką dostępnością w jednej strefie (zonalną).
• Serwery skonfigurowane bez wysokiej dostępności.

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
• Akcelerator rozwiązań odporności usługi Azure Database for PostgreSQL — skrypty programu Terraform w celu zaimplementowania wielu zasad odporności i możliwości odzyskiwania opisanych w tym artykule.