Omówienie ciągłości działalności biznesowej za pomocą usługi Azure Database for PostgreSQL — pojedynczy serwer

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer

Ważne

Usługa Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do usługi Azure Database for PostgreSQL — serwer elastyczny. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for PostgreSQL — serwer elastyczny, zobacz Co się dzieje z usługą Azure Database for PostgreSQL — pojedynczy serwer?.

W tym omówieniu opisano możliwości zapewniane przez usługę Azure Database for PostgreSQL ciągłość działania i odzyskiwanie po awarii. Dowiedz się więcej o opcjach odzyskiwania po zdarzeniach powodujących zakłócenia, które mogą spowodować utratę danych lub spowodowanie niedostępności bazy danych i aplikacji. Dowiedz się, co zrobić, gdy błąd użytkownika lub aplikacji ma wpływ na integralność danych, region świadczenia usługi Azure ma awarię lub aplikacja wymaga konserwacji.

Funkcje, których można użyć do zapewnienia ciągłości działania

Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny dopuszczalny czas, zanim aplikacja w pełni odzyska sprawność po wystąpieniu zdarzenia powodującego zakłócenia — jest to cel czasu odzyskiwania (RTO). Należy również zrozumieć maksymalną ilość najnowszych aktualizacji danych (interwał czasu), które aplikacja może tolerować utratę podczas odzyskiwania po wystąpieniu zdarzenia powodującego zakłócenia — jest to cel punktu odzyskiwania (RPO).

Usługa Azure Database for PostgreSQL oferuje funkcje ciągłości biznesowej, które obejmują geograficznie nadmiarowe kopie zapasowe z możliwością inicjowania przywracania geograficznego oraz wdrażanie replik odczytu w innym regionie. Każda z tych funkcji charakteryzuje się różnymi cechami czasu odzyskiwania i potencjalnej utraty danych. Dzięki funkcji przywracania geograficznego nowy serwer jest tworzony przy użyciu danych kopii zapasowej replikowanych z innego regionu. Całkowity czas przywracania i odzyskiwania zależy od rozmiaru bazy danych i ilości dzienników do odzyskania. Całkowity czas ustanawiania serwera może się trwać od kilku minut do kilku godzin. W przypadku replik do odczytu dzienniki transakcji z bazy podstawowej są asynchronicznie przesyłane strumieniowo do repliki. W przypadku awarii podstawowej bazy danych z powodu błędu na poziomie strefy lub na poziomie regionu przełączenie w tryb failover do repliki zapewnia krótszy cel czasu odzyskiwania i zmniejszenie utraty danych.

Uwaga

Opóźnienie między serwerem podstawowym a repliką zależy od opóźnienia między lokacjami, ilością danych, które mają być przesyłane, a co najważniejsze obciążeniem zapisu serwera podstawowego. Duże obciążenia zapisu mogą generować znaczne opóźnienie.

Ze względu na asynchroniczny charakter replikacji używanej dla replik do odczytu, nie należy ich traktować jako rozwiązania wysokiej dostępności, ponieważ wyższe opóźnienia mogą oznaczać wyższy cel czasu odzyskiwania i cel punktu odzyskiwania. Tylko w przypadku obciążeń, w których opóźnienie pozostaje mniejsze przez szczytowe i inne niż szczytowe czasy obciążenia, repliki do odczytu mogą działać jako alternatywa wysokiej dostępności. W przeciwnym razie repliki do odczytu są przeznaczone do prawdziwej skali odczytu dla gotowych obciążeń ciężkich i scenariuszy odzyskiwania po awarii (Odzyskiwanie po awarii).

W poniższej tabeli porównaliśmy cel czasu odzyskiwania i cel punktu odzyskiwania w typowym scenariuszu obciążenia :

Możliwości Podstawowa Ogólnego przeznaczenia Optymalizacja pod kątem pamięci
Przywracanie do punktu w czasie z kopii zapasowej Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania — różni się
< Cel punktu odzyskiwania 15 minut		 Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania — różni się
< Cel punktu odzyskiwania 15 minut		 Dowolny punkt przywracania w okresie przechowywania
Cel czasu odzyskiwania — różni się
< Cel punktu odzyskiwania 15 minut
Przywracanie geograficzne z kopii zapasowych replikowanych geograficznie Nieobsługiwane Cel czasu odzyskiwania — różni się
< Cel punktu odzyskiwania 1 godz.		 Cel czasu odzyskiwania — różni się
< Cel punktu odzyskiwania 1 godz.
Repliki do odczytu Cel czasu odzyskiwania — minuty*
< Cel punktu odzyskiwania 5 minut*		 Cel czasu odzyskiwania — minuty*
< Cel punktu odzyskiwania 5 minut*		 Cel czasu odzyskiwania — minuty*
< Cel punktu odzyskiwania 5 minut*

* Cel czasu odzyskiwania i cel punktu odzyskiwania może być znacznie wyższy w niektórych przypadkach w zależności od różnych czynników, w tym opóźnienia między lokacjami, ilości danych, które mają być przesyłane, i co ważne podstawowe obciążenie zapisu bazy danych.

Odzyskiwanie serwera po błędzie użytkownika lub aplikacji

Za pomocą kopii zapasowych usługi można odzyskać serwer z różnych zdarzeń powodujących zakłócenia. Użytkownik może przypadkowo usunąć niektóre dane, przypadkowo usunąć ważną tabelę, a nawet usunąć całą bazę danych. Aplikacja może przypadkowo zastąpić dobre dane nieprawidłowymi danymi z powodu wady aplikacji itd.

Możesz wykonać przywracanie do punktu w czasie, aby utworzyć kopię serwera do znanego dobrego punktu w czasie. Ten punkt w czasie musi przypadać w okresie przechowywania kopii zapasowej skonfigurowanym dla serwera. Po przywróceniu danych na nowym serwerze można zastąpić oryginalny serwer nowo przywróconym serwerem lub skopiować wymagane dane z przywróconego serwera do oryginalnego serwera.

Zalecamy użycie blokady zasobów platformy Azure, aby zapobiec przypadkowemu usunięciu serwera. Jeśli serwer został przypadkowo usunięty, możesz go przywrócić, jeśli usunięcie miało miejsce w ciągu ostatnich 5 dni. Aby uzyskać więcej informacji, zobacz Przywracanie usuniętego serwera usługi Azure Database for PostgreSQL.

Odzyskiwanie sprawności po awarii centrum danych platformy Azure

Sporadycznie centrum danych platformy Azure może mieć awarię. Gdy wystąpi awaria, powoduje to zakłócenia w działalności, które mogą trwać tylko kilka minut, ale mogą trwać kilka godzin.

Jedną z opcji jest oczekiwanie na powrót serwera do trybu online, gdy awaria centrum danych się skończyła. Działa to w przypadku aplikacji, które mogą mieć serwer w trybie offline przez jakiś czas, na przykład środowisko programistyczne. Jeśli centrum danych ma awarię, nie wiesz, jak długo może trwać awaria, więc ta opcja działa tylko wtedy, gdy serwer nie jest potrzebny przez jakiś czas.

Przywracanie geograficzne

Funkcja przywracania geograficznego przywraca serwer przy użyciu geograficznie nadmiarowych kopii zapasowych. Kopie zapasowe są hostowane w sparowanym regionie serwera. Możesz przywrócić z tych kopii zapasowych do dowolnego innego regionu. Przywracanie geograficzne tworzy nowy serwer z danymi z kopii zapasowych. Dowiedz się więcej na temat przywracania geograficznego z artykułu pojęcia dotyczące tworzenia kopii zapasowych i przywracania.

Ważne

Przywracanie geograficzne jest możliwe tylko w przypadku aprowizacji serwera z geograficznie nadmiarowym magazynem kopii zapasowych. Jeśli chcesz przełączyć się z lokalnie nadmiarowych do geograficznie nadmiarowych kopii zapasowych dla istniejącego serwera, musisz wykonać zrzut przy użyciu pg_dump istniejącego serwera i przywrócić go do nowo utworzonego serwera skonfigurowanego przy użyciu geograficznie nadmiarowych kopii zapasowych.

Repliki do odczytu między regionami

Repliki do odczytu między regionami można użyć, aby zwiększyć ciągłość działalności biznesowej i planowanie odzyskiwania po awarii. Repliki do odczytu są aktualizowane asynchronicznie przy użyciu technologii replikacji fizycznej bazy danych PostgreSQL i mogą opóźnić replikację podstawową. Dowiedz się więcej na temat replik do odczytu, dostępnych regionów i sposobu przełączania w tryb failover z artykułu pojęcia dotyczące replik do odczytu.

Często zadawane pytania

Gdzie usługa Azure Database for PostgreSQL przechowuje dane klientów?

Domyślnie usługa Azure Database for PostgreSQL nie przenosi ani nie przechowuje danych klientów z regionu, w którym jest wdrażany. Jednak klienci mogą opcjonalnie wybrać opcję włączenia geograficznie nadmiarowych kopii zapasowych lub utworzyć replikę do odczytu między regionami na potrzeby przechowywania danych w innym regionie.

Następne kroki