Wysoka dostępność w usłudze Azure Database for PostgreSQL — pojedynczy serwer
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?.
Usługa Azure Database for PostgreSQL — pojedynczy serwer zapewnia gwarantowany wysoki poziom dostępności z umową dotyczącą poziomu usług (SLA) wspieranej finansowo przez czas pracy. Usługa Azure Database for PostgreSQL zapewnia wysoką dostępność podczas planowanych zdarzeń, takich jak operacja obliczeniowa zainicjowana przez użytkownika, a także w przypadku nieplanowanych zdarzeń, takich jak awarie sprzętu, oprogramowania lub sieci. Usługa Azure Database for PostgreSQL może szybko odzyskać sprawność po najbardziej krytycznych okolicznościach, zapewniając praktycznie żaden przestój aplikacji podczas korzystania z tej usługi.
Usługa Azure Database for PostgreSQL jest odpowiednia do uruchamiania baz danych o krytycznym znaczeniu, które wymagają wysokiego czasu pracy. Oparta na architekturze platformy Azure usługa ma nieodłączną wysoką dostępność, nadmiarowość i odporność, aby ograniczyć przestoje bazy danych przed zaplanowanymi i nieplanowanymi awariami bez konieczności konfigurowania dodatkowych składników.
Składniki w usłudze Azure Database for PostgreSQL — pojedynczy serwer
| Składnik | Opis |
|---|---|
| Serwer bazy danych PostgreSQL | Usługa Azure Database for PostgreSQL zapewnia zabezpieczenia, izolację, zabezpieczenia zasobów i możliwość szybkiego ponownego uruchamiania serwerów baz danych. Te możliwości ułatwiają wykonywanie operacji, takich jak skalowanie i operacja odzyskiwania serwera bazy danych po awarii w ciągu kilku sekund. Modyfikacje danych na serwerze bazy danych zwykle występują w kontekście transakcji bazy danych. Wszystkie zmiany bazy danych są rejestrowane synchronicznie w postaci dzienników z wyprzedzeniem zapisu (WAL) w usłudze Azure Storage — które są dołączone do serwera bazy danych. Podczas procesu punktu kontrolnego bazy danych strony danych z pamięci serwera bazy danych są również opróżniane do magazynu. |
| Magazyn zdalny | Wszystkie pliki danych fizycznych postgreSQL i pliki WAL są przechowywane w usłudze Azure Storage, która jest zaprojektowana do przechowywania trzech kopii danych w regionie w celu zapewnienia nadmiarowości, dostępności i niezawodności danych. Warstwa magazynu jest również niezależna od serwera bazy danych. Można go odłączyć od nieudanego serwera bazy danych i ponownie dołączyć go do nowego serwera bazy danych w ciągu kilku sekund. Ponadto usługa Azure Storage stale monitoruje błędy magazynu. Jeśli zostanie wykryte uszkodzenie bloku, zostanie ono automatycznie naprawione przez utworzenie wystąpienia nowej kopii magazynu. |
| Brama | Brama działa jako serwer proxy bazy danych, kieruje wszystkie połączenia klientów z serwerem bazy danych. |
Planowane ograniczenie przestojów
Usługa Azure Database for PostgreSQL jest zaprojektowana w celu zapewnienia wysokiej dostępności podczas planowanych operacji przestojów.
- Skalowanie serwerów baz danych PostgreSQL w górę i w dół w ciągu kilku sekund.
- Brama działająca jako serwer proxy do kierowania klienta łączy się z odpowiednim serwerem bazy danych.
- Skalowanie w górę magazynu można wykonać bez żadnych przestojów. Magazyn zdalny umożliwia szybkie odłączanie/ponowne dołączanie po przejściu w tryb failover. Poniżej przedstawiono niektóre scenariusze planowanej konserwacji:
Ograniczanie niezaplanowanych przestojów
Nieplanowany przestój może wystąpić w wyniku nieprzewidzianych awarii, w tym podstawowych błędów sprzętowych, problemów z siecią i usterek oprogramowania. Jeśli serwer bazy danych nieoczekiwanie przestanie działać, nowy serwer bazy danych zostanie aprowizowany automatycznie w ciągu kilku sekund. Magazyn zdalny jest automatycznie dołączany do nowego serwera bazy danych. Aparat PostgreSQL wykonuje operację odzyskiwania przy użyciu plików WAL i plików bazy danych oraz otwiera serwer bazy danych, aby umożliwić klientom nawiązywanie połączeń. Transakcje niezatwierdzone zostaną utracone i muszą zostać ponowione przez aplikację. Chociaż nie można uniknąć nieplanowanego przestoju, usługa Azure Database for PostgreSQL ogranicza przestoje, automatycznie wykonując operacje odzyskiwania zarówno na serwerze bazy danych, jak i w warstwach magazynu bez konieczności interwencji człowieka.
- Serwery usługi Azure PostgreSQL z funkcjami szybkiego skalowania.
- Brama, która działa jako serwer proxy do kierowania połączeń klientów do odpowiedniego serwera bazy danych.
- Usługa Azure Storage z trzema kopiami w celu zapewnienia niezawodności, dostępności i nadmiarowości.
- Magazyn zdalny umożliwia również szybkie odłączanie/ponowne dołączanie po przejściu serwera w tryb failover.
Nieplanowany przestój: scenariusze awarii i odzyskiwanie usługi
Poniżej przedstawiono niektóre scenariusze awarii i sposób automatycznego odzyskiwania usługi Azure Database for PostgreSQL:
| Scenariusz | Automatyczne odzyskiwanie |
|---|---|
| Błąd serwera bazy danych | Jeśli serwer bazy danych nie działa z powodu niektórych podstawowych błędów sprzętowych, aktywne połączenia zostaną porzucone, a wszystkie transakcje w locie zostaną przerwane. Nowy serwer bazy danych jest wdrażany automatycznie, a zdalny magazyn danych jest dołączony do nowego serwera bazy danych. Po zakończeniu odzyskiwania bazy danych klienci mogą łączyć się z nowym serwerem bazy danych za pośrednictwem bramy. Czas odzyskiwania (RTO) zależy od różnych czynników, w tym działania w momencie wystąpienia błędu, takiego jak duża transakcja i ilość odzyskiwania do wykonania podczas procesu uruchamiania serwera bazy danych. Aplikacje korzystające z baz danych PostgreSQL muszą być tworzone w sposób, w jaki wykrywają i ponawiają próby porzuconych połączeń i nieudanych transakcji. Gdy aplikacja ponawia próbę, brama w sposób niewidoczny przekierowuje połączenie z nowo utworzonym serwerem bazy danych. |
| Błąd magazynu | Aplikacje nie widzą żadnego wpływu na problemy związane z magazynem, takie jak awaria dysku lub uszkodzenie bloku fizycznego. Ponieważ dane są przechowywane w trzech kopiach, kopia danych jest obsługiwana przez magazyn ocalały. Uszkodzenia bloków są automatycznie poprawiane. Jeśli kopia danych zostanie utracona, zostanie automatycznie utworzona nowa kopia danych. |
| Błąd obliczeniowy | Błędy obliczeniowe to rzadkie zdarzenia. W przypadku awarii obliczeniowej jest aprowizowany nowy kontener obliczeniowy, a magazyn z plikami danych jest mapowany, aparat bazy danych PostgreSQL jest następnie w trybie online w nowym kontenerze i usłudze bramy zapewnia przezroczysty tryb failover bez konieczności wprowadzania zmian w aplikacji. Należy również pamiętać, że warstwa obliczeniowa ma wbudowaną odporność strefy dostępności, a nowe zasoby obliczeniowe są tworzone w innej strefie dostępności w przypadku awarii obliczeniowej az. |
Poniżej przedstawiono kilka scenariuszy awarii, które wymagają wykonania akcji użytkownika w celu odzyskania:
| Scenariusz | Plan odzyskiwania |
|---|---|
| Błąd regionu | Awaria regionu jest rzadkim zdarzeniem. Jeśli jednak potrzebujesz ochrony przed awarią regionu, możesz skonfigurować co najmniej jedną replikę do odczytu w innych regionach na potrzeby odzyskiwania po awarii. (Zobacz ten artykuł na temat tworzenia replik do odczytu i zarządzania nimi, aby uzyskać szczegółowe informacje). W przypadku awarii na poziomie regionu można ręcznie podwyższyć poziom repliki do odczytu skonfigurowanej w innym regionie, aby był serwerem produkcyjnej bazy danych. |
| Awaria strefy dostępności | Niepowodzenie strefy dostępności jest również rzadkim zdarzeniem. Jeśli jednak potrzebujesz ochrony przed awarią strefy dostępności, możesz skonfigurować co najmniej jedną replikę do odczytu lub rozważyć użycie naszej oferty serwera elastycznego, która zapewnia strefowo nadmiarową wysoką dostępność. |
| Błędy logiczne/użytkownika | Odzyskiwanie po błędach użytkownika, takich jak przypadkowo porzucone tabele lub niepoprawnie zaktualizowane dane, polega na wykonaniu odzyskiwania do punktu w czasie (PITR), przywracając i odzyskując dane do momentu tuż 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. |
Podsumowanie
Usługa Azure Database for PostgreSQL zapewnia możliwość szybkiego ponownego uruchamiania serwerów baz danych, magazynu nadmiarowego i wydajnego routingu z bramy. Aby uzyskać dodatkową ochronę danych, można skonfigurować kopie zapasowe do replikacji geograficznej, a także wdrożyć co najmniej jedną replikę do odczytu w innych regionach. Dzięki nieodłącznym funkcjom wysokiej dostępności usługa Azure Database for PostgreSQL chroni bazy danych przed najczęstszymi awariami i oferuje wiodącą w branży umowę SLA gwarantującą czas pracy oparty na finansach na poziomie 99,99%. Wszystkie te funkcje dostępności i niezawodności umożliwiają platformie Azure idealne uruchamianie aplikacji o krytycznym znaczeniu.
Następne kroki
- Dowiedz się więcej o regionach świadczenia usługi Azure
- Dowiedz się więcej o obsłudze przejściowych błędów łączności
- Dowiedz się, jak replikować dane za pomocą replik do odczytu
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla