Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ciągłość działalności biznesowej w usłudze Azure Database for PostgreSQL odnosi się do mechanizmów, zasad i procedur, które umożliwiają firmie kontynuowanie działania w obliczu zakłóceń, szczególnie w odniesieniu do infrastruktury obliczeniowej. W większości przypadków Azure Database for PostgreSQL obsługuje destrukcyjne zdarzenia, które mogą wystąpić w środowisku chmury i utrzymuje uruchomione aplikacje i procesy biznesowe. Nie można jednak automatycznie obsłużyć niektórych zdarzeń, takich jak:
- Użytkownik przypadkowo usuwa lub aktualizuje wiersz w tabeli.
- Trzęsienie ziemi powoduje awarię zasilania i tymczasowo wyłącza strefę dostępności lub region.
- Poprawki bazy danych wymagane do rozwiązania problemu z usterką lub zabezpieczeniami.
Azure Database for PostgreSQL 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ść, usługa Azure Database for PostgreSQL ma funkcje ciągłości działania, które zapewniają kolejną ochronę błędów, 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.
W poniższej tabeli przedstawiono funkcje, które Azure Database for PostgreSQL oferuje.
| Funkcja | Opis | Zagadnienia do rozważenia |
|---|---|---|
| Automatyczne kopie zapasowe | Instancja elastycznego serwera usługi Azure Database for PostgreSQL automatycznie wykonuje codzienne kopie zapasowe plików bazy danych i stale tworzy kopie zapasowe dzienników transakcji. Kopie zapasowe można przechowywać z 7 dni do 35 dni. Serwer bazy danych można przywrócić do dowolnego punktu w czasie w okresie przechowywania kopii zapasowej. RTO zależy od ilości danych do przywrócenia oraz czasu potrzebnego na odtworzenie dziennika transakcji. Może to potrwać od kilku minut do 12 godzin. Aby uzyskać więcej informacji, zobacz Pojęcia — tworzenie kopii zapasowych i przywracanie. | Dane kopii zapasowej pozostają w regionie. |
| Strefowo nadmiarowa wysoka dostępność | Można wdrożyć instancję usługi Azure Database for PostgreSQL — serwer elastyczny z konfiguracją wysokiej dostępności z nadmiarowością strefową, w której serwer podstawowy i serwer rezerwowy są wdrażane w dwóch różnych strefach dostępności w obrębie regionu. Ta konfiguracja wysokiej dostępności chroni bazy danych przed awariami na poziomie strefy, a także pomaga zmniejszyć przestoje aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Dane z serwera podstawowego są replikowane do repliki rezerwowej w trybie synchronicznym. W przypadku zakłóceń na serwerze podstawowym serwer jest automatycznie przełączony w tryb failover do repliki rezerwowej. RTO w większości przypadków powinno wynosić mniej niż 120 sekund. Oczekuje się, że punkt odzyskiwania (RPO) będzie równy zeru (bez utraty danych). Aby uzyskać więcej informacji, zobacz Pojęcia — wysoka dostępność. | Obsługiwane w warstwach obliczeniowych ogólnego przeznaczenia i zoptymalizowanych pod kątem pamięci. Dostępne tylko w regionach, w których dostępnych jest wiele stref. |
| Wysoka dostępność w tej samej strefie | Można wdrożyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL z konfiguracją wysokiej dostępności (HA) w tej samej strefie, w której serwer podstawowy i serwer rezerwowy są wdrażane w tej samej strefie dostępności w regionie. Ta konfiguracja wysokiej dostępności chroni bazy danych przed awariami na poziomie węzła, a także pomaga zmniejszyć przestoje aplikacji podczas planowanych i nieplanowanych zdarzeń przestojów. Dane z serwera podstawowego są replikowane do repliki rezerwowej w trybie synchronicznym. W przypadku zakłóceń na serwerze podstawowym serwer jest automatycznie przełączony w tryb failover do repliki rezerwowej. RTO w większości przypadków powinno wynosić mniej niż 120 sekund. Oczekuje się, że punkt odzyskiwania (RPO) będzie równy zeru (bez utraty danych). Aby uzyskać więcej informacji, zobacz [Pojęcia: wysoka dostępność]/azure/reliability/reliability-postgresql-flexible-server. | Obsługiwane w warstwach obliczeniowych ogólnego przeznaczenia i zoptymalizowanych pod kątem pamięci. |
| Dyski zarządzane w warstwie Premium | Pliki bazy danych są przechowywane w wysoce trwałym i niezawodnym magazynie zarządzanym w warstwie Premium. Ten magazyn zapewnia nadmiarowość danych z trzema kopiami repliki przechowywanymi w strefie dostępności z funkcjami automatycznego odzyskiwania danych. Aby uzyskać więcej informacji, zobacz dokumentację dysków zarządzanych. | Dane przechowywane w strefie dostępności. |
| Kopia zapasowa strefowo nadmiarowa | Kopie zapasowe elastycznego serwera usługi Azure Database for PostgreSQL są automatycznie i bezpiecznie przechowywane w nadmiarowym przechowywaniu w wielu strefach w regionie, o ile region obsługuje strefy dostępności. Podczas awarii strefy, w której wdrożono serwer, jeśli serwer nie jest skonfigurowany pod kątem nadmiarowości strefowej, nadal można przywrócić bazę danych za pomocą najnowszego punktu przywracania w innej strefie. Aby uzyskać więcej informacji, zobacz Koncepty — tworzenie kopii zapasowych i przywracanie. | Dotyczy tylko regionów, w których dostępnych jest wiele stref. |
| Geograficznie redundantna kopia zapasowa | Kopie zapasowe wystąpień serwera elastycznego usługi Azure Database for PostgreSQL są kopiowane do regionu zdalnego. Ta funkcja pomaga w odzyskiwaniu po awarii, gdy podstawowy region serwera jest niedostępny. | Ta funkcja jest obecnie włączona w wybranych regionach. Dłuższy czas odzyskiwania (RTO) i wyższy punkt odzyskiwania (RPO) są wymagane w zależności od rozmiaru danych do przywrócenia i zakresu odzyskiwania do wykonania. |
| Replika 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 bazy danych PostgreSQL i mogą opóźnić replikację podstawową. Aby uzyskać więcej informacji, zobacz Koncepcje - repliki do odczytu. | Obsługiwane w warstwach obliczeniowych ogólnego przeznaczenia i zoptymalizowanych pod kątem pamięci. |
Poniższa tabela porównuje RTO i RPO w typowym scenariuszu obciążenia:
| Zdolność | Skok wydajności | Jednostka SKU produkcji (ogólnego przeznaczenia/zoptymalizowana pod kątem pamięci) |
|---|---|---|
| Przywracanie do określonego punktu w czasie z kopii zapasowej | Dowolny punkt przywracania w okresie przechowywania Czas przywracania (RTO) — różni się < Cel punktu odzyskiwania 5 minut |
Dowolny punkt przywracania w okresie przechowywania Czas przywracania (RTO) — różni się < Cel punktu odzyskiwania 5 minut |
| Przywracanie geograficzne z kopii zapasowych replikowanych geograficznie | Czas przywracania (RTO) — różni się RPO < 1 godz. |
Czas przywracania (RTO) — różni się RPO < 1 godz. |
| Repliki do odczytu | Nie dotyczy | Wskaźnik czasu odzyskiwania — minuty* RPO — zazwyczaj w zakresie od 30 sekund do 5 minut* |
| Wysoka dostępność | Nie dotyczy | RTO < 120 s Docelowy punkt odzyskiwania = 0 |
Zdarzenia zaplanowanego przestoju
W poniższej tabeli opisano niektóre typowe scenariusze planowanej konserwacji. Te zdarzenia zwykle powodują kilka minut przestoju, ale nie powodują utraty danych.
| scenariusz | Proces |
|---|---|
| Skalowanie obliczeń (zainicjowane przez użytkownika) | Podczas operacji skalowania obliczeniowego proces umożliwia ukończenie aktywnych punktów kontrolnych, opróżnianie połączeń klientów, anulowanie wszelkich niezatwierdzonych transakcji, odłączanie magazynu, a następnie zamykanie. Proces tworzy nowe wystąpienie usługi Azure Database for PostgreSQL — serwer elastyczny o tej samej nazwie serwera bazy danych, ale ze skalowaną konfiguracją mocy obliczeniowej. Proces dołącza magazyn do nowego serwera i uruchamia bazę danych, która w razie potrzeby wykonuje odzyskiwanie przed zaakceptowaniem połączeń klienckich. |
| Skalowanie pamięci masowej (zainicjowane przez użytkownika) | Po rozpoczęciu operacji zwiększania pojemności magazynu proces pozwala na ukończenie aktywnych punktów kontrolnych, wygasza połączenia klientów i wycofuje wszelkie niezatwierdzone transakcje. Następnie proces zamyka serwer. Proces skaluje magazyn do żądanego rozmiaru, a następnie dołącza go do nowego serwera. Proces wykonuje odzyskiwanie w razie potrzeby przed zaakceptowaniem połączeń klienckich. Należy pamiętać, że zmniejszanie rozmiaru przechowywania nie jest obsługiwane. |
| Nowe wdrożenie oprogramowania (zainicjowane przez platformę Azure) | Usługa automatycznie wdraża nowe funkcje lub poprawki błędów w ramach planowanej konserwacji. Możesz zaplanować, kiedy te działania nastąpią. Aby uzyskać więcej informacji, sprawdź swój portal. |
| Uaktualnienia wersji pomocniczych (zainicjowane przez platformę Azure) | Usługa Azure Database for PostgreSQL automatycznie aktualizuje serwery baz danych do wersji mniejszej określonej przez platformę Azure. To stosowanie poprawek odbywa się w ramach planowanej konserwacji usługi. Proces automatycznie uruchamia ponownie serwer bazy danych z nową wersją podrzędną. Aby uzyskać więcej informacji, zobacz dokumentację. Możesz również przejrzeć swój "portal". |
Podczas konfigurowania wystąpienia serwera elastycznego Azure Database for PostgreSQL z włączoną opcją wysokiej dostępności usługa najpierw wykonuje operacje skalowania i konserwacyjne na serwerze rezerwowym. Aby uzyskać więcej informacji, zobacz [Pojęcia: wysoka dostępność]/azure/reliability/reliability-postgresql-flexible-server.
Ograniczanie niezaplanowanych przestojów
Nieplanowane przestoje mogą wystąpić w wyniku nieprzewidzianych zakłóceń, takich jak błędy sprzętowe, problemy z siecią i błędy oprogramowania. Jeśli serwer bazy danych skonfigurowany z wysoką dostępnością niespodziewanie ulegnie awarii, usługa aktywuje replikę rezerwową, a klienci mogą wznowić operacje. Jeśli serwer nie zostanie skonfigurowany z wysoką dostępnością(HA), usługa automatycznie aprowizuje nowy serwer bazy danych, jeśli próba ponownego uruchomienia zakończy się niepowodzeniem. Chociaż nie można uniknąć nieplanowanego przestoju, Azure Database for PostgreSQL pomaga ograniczyć przestoje, automatycznie wykonując operacje odzyskiwania bez konieczności interwencji człowieka.
Mimo że zespół inżynierów stale dąży do zapewnienia wysokiej dostępności, zdarzają się sytuacje, w których usługa Azure Database for PostgreSQL ulega awarii, co powoduje niedostępność baz danych, a tym samym wpływa na działanie aplikacji. Gdy monitorowanie usługi wykryje problemy, które powodują powszechne błędy łączności, błędy lub problemy z wydajnością, usługa automatycznie deklaruje awarię, aby informować Użytkownika.
Ważne
Serwery skonfigurowane z wysoką dostępnością wymagają bezpośredniej ścieżki sieciowej do płaszczyzny sterowania Azure Storage. Kierowanie ruchu magazynowego przez wirtualne urządzenie sieciowe nie jest obsługiwane i może pozostawić serwer w stanie Uruchamianie ponowne. Aby zapewnić bezpośrednią ścieżkę, włącz punkt końcowy usługi sieci wirtualnej dla Azure Storage w podsieci delegowanej lub skonfiguruj trasę zdefiniowaną przez użytkownika, która wysyła ruch magazynu bezpośrednio do Internetu.
Przerwa w działaniu usługi
Jeśli wystąpienie usługi Azure Database for PostgreSQL – serwer elastyczny przestanie działać, więcej szczegółów na temat niedostępności można znaleźć w następujących miejscach:
- Baner portalu Azure: Jeśli problem dotyczy Twojej subskrypcji, Powiadomienia w portalu Azure wyświetlają alert o przerwie w działaniu usługi.
- Pomoc + obsługa techniczna lub Obsługa techniczna + rozwiązywanie problemów: podczas tworzenia zgłoszenia do pomocy technicznej z poziomu Pomoc + obsługa techniczna lub Obsługa techniczna + rozwiązywanie problemów portal zawiera informacje o wszelkich problemach wpływających na Twoje zasoby. Wybierz pozycję Wyświetl szczegóły awarii, aby uzyskać więcej informacji i podsumowanie wpływu. Strona Nowy wniosek o pomoc techniczną zawiera również alert.
- Kondycja usługi: strona Kondycja usługi w portalu Azure zawiera informacje o stanie centrum danych Azure globalnie. Wyszukaj ciąg "service health" na pasku wyszukiwania w portalu Azure, a następnie wyświetl problemy z usługą w kategorii Aktywne zdarzenia. Kondycję poszczególnych zasobów można również wyświetlić na stronie Kondycja zasobu dowolnego zasobu w menu Pomoc . Poniższy zrzut ekranu przedstawiający stronę Kondycja usługi zawiera informacje o aktywnym problemie z usługą w Azji Południowo-Wschodniej.
- Powiadomienie e-mail: Jeśli skonfigurujesz alerty, otrzymasz powiadomienie e-mail, gdy awaria usługi wpłynie na subskrypcję i zasób. Wiadomości e-mail pochodzą z "azure-noreply@microsoft.com". Treść wiadomości e-mail zaczyna się od słów "Alert dziennika aktywności ... został wyzwolony przez problem z usługą w subskrypcji platformy Azure...". Aby uzyskać więcej informacji na temat alertów dotyczących kondycji usługi, zobacz Odbieranie alertów dziennika aktywności dotyczących powiadomień usługi Azure przy użyciu portalu Azure.
Ważne
Jak wskazuje nazwa, tymczasowe przestrzenie tabel w bazie danych PostgreSQL są używane do obiektów tymczasowych, a także innych operacji wewnętrznej bazy danych, takich jak sortowanie. W związku z tym nie twórz obiektów należących do schematu użytkownika w tymczasowej przestrzeni tabel, ponieważ nie ma gwarancji, że obiekty te zostaną zachowane po ponownym uruchomieniu serwera, przełączeniu awaryjnym w środowisku wysokiej dostępności i podobnych zdarzeniach.
Nieplanowany przestój: scenariusze awarii i odzyskiwanie usługi
W poniższej tabeli opisano typowe nieplanowane scenariusze awarii i proces odzyskiwania.
| scenariusz |
Proces odzyskiwania [Serwery skonfigurowane bez redundantności strefowej HA] |
Proces odzyskiwania [Serwery skonfigurowane ze strefową redundancją HA] |
|---|---|---|
| Błąd serwera bazy danych | Jeśli serwer bazy danych ulegnie awarii, Azure próbuje ponownie uruchomić serwer bazy danych. Jeśli ta próba nie powiedzie się, Azure ponownie uruchomi serwer bazy danych w innym węźle fizycznym. Czas odzyskiwania (RTO) zależy od różnych czynników, w tym działania w momencie wystąpienia błędu, takich jak duża transakcja, oraz wolumin odzyskiwania do wykonania podczas procesu uruchamiania serwera bazy danych. Aplikacje korzystające z baz danych PostgreSQL muszą wykrywać i ponawiać próby porzuconych połączeń i nieudanych transakcji. |
Jeśli zostanie wykryta awaria serwera bazy danych, serwer przechodzi w tryb failover na serwer rezerwowy, co zmniejsza przestoje. Aby uzyskać więcej informacji, zobacz [stronę koncepcji wysokiej dostępności]/azure/reliability/reliability-postgresql-flexible-server. RTO ma wynosić 60–120 sekund, przy zerowej utracie danych. |
| Błąd magazynu | Aplikacje nie odczuwają żadnych skutków problemów związanych z pamięcią masową, takich jak awaria dysku lub fizyczne uszkodzenie bloku. Ponieważ dane są przechowywane w trzech kopiach, pozostały zasób pamięci masowej udostępnia kopię danych. Uszkodzony blok danych zostanie automatycznie naprawiony i zostanie automatycznie utworzona nowa kopia danych. | W przypadku rzadkich i nieodwracalnych błędów, takich jak sytuacja, gdy cała warstwa magazynu jest niedostępna, wystąpienie serwera elastycznego Azure Database for PostgreSQL przełącza się awaryjnie na replikę rezerwową, aby skrócić czas przestoju. Aby uzyskać więcej informacji, zobacz [stronę koncepcji wysokiej dostępności]/azure/reliability/reliability-postgresql-flexible-server. |
| Błędy logiczne lub błędy użytkownika | Aby przywrócić dane po błędach użytkownika, takich jak przypadkowo usunięte tabele lub nieprawidłowo zaktualizowane dane, wykonaj odzyskiwanie do określonego punktu w czasie (PITR). Podczas wykonywania operacji przywracania określ niestandardowy punkt przywracania, czyli czas bezpośrednio przed wystąpieniem błędu. Jeśli chcesz przywrócić tylko podzbiór baz danych lub określonych tabel, a nie wszystkich baz danych na serwerze bazy danych, możesz przywrócić serwer bazy danych w nowym wystąpieniu, wyeksportować tabele za pośrednictwem pg_dump, a następnie użyć pg_restore , aby przywrócić te tabele do bazy danych. |
Te błędy użytkownika nie są chronione przez wysoką dostępność, ponieważ wszystkie zmiany są replikowane synchronicznie do repliki rezerwowej. Aby odzyskać dane po takich błędach, należy wykonać przywracanie do punktu w czasie. |
| Niepowodzenie strefy dostępności | Aby odzyskać działanie po awarii na poziomie strefy, wykonaj przywracanie do określonego punktu w czasie z kopii zapasowej i wybierz niestandardowy punkt przywracania z najpóźniejszą dostępną godziną, aby odzyskać najnowsze dane. Wdróż nowe wystąpienie serwera elastycznego Azure Database for PostgreSQL w innej strefie nieobjętej problemem. Czas potrzebny na przywrócenie zależy od poprzedniej kopii zapasowej i ilości dzienników transakcji do odzyskania. | Instancja usługi Azure Database for PostgreSQL — serwer elastyczny automatycznie przełącza się awaryjnie na serwer rezerwowy w ciągu 60–120 sekund bez utraty danych. Aby uzyskać więcej informacji, zobacz [stronę koncepcji wysokiej dostępności]/azure/reliability/reliability-postgresql-flexible-server. |
| Błąd regionu | Jeśli serwer jest skonfigurowany z geograficznie nadmiarową kopią zapasową, możesz wykonać przywracanie geograficzne w sparowanym regionie. Azure udostępnia nowy serwer i odtwarza go na podstawie ostatnio dostępnych danych skopiowanych do tego regionu. Można również użyć replik do odczytu w różnych regionach. W przypadku awarii regionu można przeprowadzić operację odzyskiwania po awarii, awansując replikę tylko do odczytu do roli samodzielnego serwera z możliwością odczytu i zapisu. Przewiduje się, że RPO wyniesie maksymalnie pięć minut (możliwa utrata danych), z wyjątkiem przypadku poważnej awarii regionalnej, kiedy RPO może być zbliżony do opóźnienia replikacji w momencie awarii. |
Ten sam proces. |
Skonfiguruj bazę danych po odzyskaniu po awarii regionalnej
- Jeśli używasz funkcji przywracania geograficznego lub repliki geograficznej do odzyskiwania po awarii, upewnij się, że łączność z nowym serwerem jest prawidłowo skonfigurowana, aby normalna funkcja aplikacji mogła wznowić działanie. Wykonaj Zadania po przywróceniu.
- Jeśli wcześniej skonfigurowano ustawienie diagnostyczne na oryginalnym serwerze, pamiętaj, aby w razie potrzeby wykonać to samo na serwerze docelowym, zgodnie z opisem w temacie Konfigurowanie i uzyskiwanie dostępu do dzienników w Azure Database for PostgreSQL.
- Aby skonfigurować alerty telemetryczne, upewnij się, że istniejące ustawienia reguły alertu zostały zaktualizowane w celu mapowania na nowy serwer. Aby uzyskać więcej informacji na temat reguł alertów, zobacz Konfigurowanie alertów dotyczących metryk dla usługi Azure Database for PostgreSQL przy użyciu witryny Azure Portal.
Ważne
Można przywrócić usunięte serwery. Jeśli usuniesz serwer, postępuj zgodnie ze wskazówkami w temacie Przywracanie usuniętego serwera w celu odzyskania. Użyj blokady zasobów platformy Azure, aby zapobiec przypadkowemu usunięciu serwera.