Share via

Repliki do odczytu w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Funkcja repliki do odczytu umożliwia replikowanie danych z wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL do repliki tylko do odczytu. Repliki są aktualizowane asynchronicznie przy użyciu natywnej technologii replikacji fizycznej aparatu PostgreSQL. Domyślnym trybem operacji jest replikacja strumieniowa przy użyciu miejsc replikacji. W razie potrzeby wysyłanie dziennika opartego na plikach jest używane do nadrabiania zaległości. Można replikować z serwera podstawowego do maksymalnie pięciu replik.

Repliki to nowe serwery, którymi zarządzasz podobnie jak zwykłe wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Dla każdej repliki do odczytu opłaty są naliczane za aprowizowane zasoby obliczeniowe w rdzeniach wirtualnych i magazynie w GB/miesiąc.

Dowiedz się, jak tworzyć repliki i zarządzać nimi.

Kiedy używać repliki do odczytu

Funkcja repliki do odczytu ułatwia poprawę wydajności i skalowania obciążeń intensywnie korzystających z odczytu. Obciążenia odczytu mogą być odizolowane do replik, a obciążenia zapisu mogą być kierowane do serwera podstawowego. Repliki do odczytu można również wdrożyć w innym regionie i mogą być promowane do serwera odczytu i zapisu, jeśli jest potrzebne odzyskiwanie po awarii.

Typowy scenariusz polega na tym, że obciążenia analizy biznesowej i analityczne używają repliki do odczytu jako źródła danych do raportowania.

Ponieważ repliki są przeznaczone tylko do odczytu, nie zmniejszają bezpośrednio obciążeń związanych z pojemnością zapisu na serwerze podstawowym.

Kwestie wymagające rozważenia

Repliki do odczytu są przeznaczone głównie dla scenariuszy, w których odciążanie zapytań jest korzystne, a niewielkie opóźnienie jest możliwe do zarządzania. Są one zoptymalizowane pod kątem dostarczania aktualizacji niemal w czasie rzeczywistym z podstawowych dla większości obciążeń, dzięki czemu są doskonałym rozwiązaniem dla scenariuszy z dużą ilością odczytu. Należy jednak pamiętać, że nie są one przeznaczone do scenariuszy replikacji synchronicznej wymagającej dokładności danych do minuty. Chociaż dane repliki w końcu staną się zgodne z podstawowymi, może wystąpić opóźnienie, które zwykle waha się od kilku sekund do minut, a w niektórych scenariuszach o dużym obciążeniu lub dużym opóźnieniu to opóźnienie może wydłużyć się do kilku godzin. Zazwyczaj repliki do odczytu w tym samym regionie co podstawowy mają mniejsze opóźnienie niż repliki geograficzne, ponieważ te ostatnie często dotyczą opóźnienia spowodowanego odległością geograficzną. Aby uzyskać więcej informacji na temat wpływu na wydajność replikacji geograficznej, zapoznaj się z artykułem Replikacja geograficzna. Dane repliki w końcu staną się spójne z danymi podstawowymi. Użyj tej funkcji w przypadku obciążeń, które mogą uwzględnić to opóźnienie.

Uwaga

W przypadku większości obciążeń repliki do odczytu oferują aktualizacje niemal w czasie rzeczywistym z serwera podstawowego. Jednak w przypadku trwałych dużych obciążeń podstawowych intensywnie korzystających z zapisu opóźnienie replikacji może nadal rosnąć i może być w stanie nadrobić zaległości tylko w podstawowej wersji. Może to również zwiększyć użycie magazynu w warstwie podstawowej, ponieważ pliki WAL są usuwane tylko raz odebrane w repliki. Jeśli ta sytuacja będzie się powtarzać, usunięcie i ponowne utworzenie repliki do odczytu po zakończeniu obciążeń intensywnie korzystających z zapisu, można przywrócić replikę do dobrego stanu opóźnienia. Asynchroniczne repliki do odczytu nie są odpowiednie dla takich dużych obciążeń zapisu. Podczas oceniania replik do odczytu dla aplikacji należy monitorować opóźnienie repliki pod kątem pełnego cyklu obciążenia aplikacji przez okres szczytowy i poza szczytem, aby ocenić możliwe opóźnienie i oczekiwany cel czasu odzyskiwania/cel punktu odzyskiwania w różnych punktach cyklu obciążenia.

Tworzenie repliki

Serwer podstawowy dla serwera elastycznego usługi Azure Database for PostgreSQL można wdrożyć w dowolnym regionie obsługującym usługę. Repliki serwera podstawowego można tworzyć w tym samym regionie lub w różnych globalnych regionach świadczenia usługi Azure, w których jest dostępny serwer elastyczny usługi Azure Database for PostgreSQL. Możliwość tworzenia replik jest teraz rozszerzana na niektóre specjalne regiony świadczenia usługi Azure. Zapoznaj się z artykułem Replikacja geograficzna , aby zapoznać się z listą regionów specjalnych, w których można tworzyć repliki.

Po uruchomieniu przepływu pracy tworzenia repliki zostanie utworzone puste wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL. Nowy serwer jest wypełniony danymi na serwerze podstawowym. W przypadku tworzenia replik w tym samym regionie jest używane podejście do migawek. W związku z tym czas tworzenia jest niezależny od rozmiaru danych. Repliki geograficzne są tworzone przy użyciu podstawowej kopii zapasowej wystąpienia podstawowego, które jest następnie przesyłane za pośrednictwem sieci; w związku z tym czas tworzenia może wahać się od minut do kilku godzin, w zależności od rozmiaru podstawowego.

Replika jest uznawana za pomyślnie utworzoną tylko wtedy, gdy zostaną spełnione dwa warunki: cała kopia zapasowa wystąpienia podstawowego musi zostać skopiowana do repliki, a dzienniki transakcji muszą być zsynchronizowane z opóźnieniem nie większym niż 1 GB.

Aby osiągnąć pomyślną operację tworzenia, należy unikać tworzenia replik w okresach dużego obciążenia transakcyjnego. Na przykład należy unikać tworzenia replik podczas migracji z innych źródeł do serwera elastycznego usługi Azure Database for PostgreSQL lub podczas dużych operacji ładowania zbiorczego. Jeśli migrujesz dane lub ładujesz teraz duże ilości danych, najlepiej najpierw wykonać to zadanie. Po zakończeniu tego procesu można rozpocząć konfigurowanie replik. Po zakończeniu operacji migracji lub ładowania zbiorczego sprawdź, czy rozmiar dziennika transakcji powrócił do normalnego rozmiaru. Zazwyczaj rozmiar dziennika transakcji powinien być zbliżony do wartości zdefiniowanej w parametrze serwera max_wal_size dla wystąpienia. Możesz śledzić ślad magazynu dziennika transakcji przy użyciu używanej metryki Magazyn dzienników transakcji, która zapewnia wgląd w ilość miejsca używanego przez dziennik transakcji. Monitorując tę metryę, można upewnić się, że rozmiar dziennika transakcji mieści się w oczekiwanym zakresie i że proces tworzenia repliki może zostać uruchomiony.

Ważne

Repliki do odczytu są obecnie obsługiwane w warstwach obliczeniowych serwera Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci. Warstwa obliczeniowa serwera z możliwością rozszerzenia nie jest obsługiwana.

Ważne

Podczas wykonywania operacji tworzenia, usuwania i podwyższania poziomu repliki serwer podstawowy wprowadzi stan aktualizacji. W tym czasie operacje zarządzania serwerem, takie jak modyfikowanie parametrów serwera, zmienianie opcji wysokiej dostępności lub dodawanie lub usuwanie zapór będą niedostępne. Należy pamiętać, że stan aktualizacji dotyczy tylko operacji zarządzania serwerem i nie ma wpływu na operacje płaszczyzny danych. Oznacza to, że serwer bazy danych pozostanie w pełni funkcjonalny i będzie mógł akceptować połączenia, a także obsługiwać ruch odczytu i zapisu.

Dowiedz się, jak utworzyć replikę do odczytu w witrynie Azure Portal.

Zarządzanie konfiguracją

Podczas konfigurowania replik do odczytu dla serwera elastycznego usługi Azure Database for PostgreSQL niezbędne jest zrozumienie konfiguracji serwera, które można dostosować, dziedziczone z podstawowego i powiązanych ograniczeń.

Konfiguracje dziedziczone

Po utworzeniu repliki do odczytu dziedziczy ona określone konfiguracje serwera z serwera podstawowego. Te konfiguracje można zmienić podczas tworzenia repliki lub po jej skonfigurowaniu. Jednak określone ustawienia, takie jak geograficzna kopia zapasowa, nie będą replikowane do repliki do odczytu.

Konfiguracje podczas tworzenia repliki

  • Warstwa, rozmiar magazynu: w przypadku operacji "podwyższanie poziomu do serwera podstawowego" musi być taka sama jak podstawowa. W przypadku operacji "podwyższanie poziomu do niezależnego serwera i usuwanie z replikacji" może być taka sama lub wyższa niż podstawowa.
  • Warstwa wydajności (IOPS): regulowane.
  • Szyfrowanie danych: Regulowane, obejmują przenoszenie z kluczy zarządzanych przez usługę do kluczy zarządzanych przez klienta.

Konfiguracje po utworzeniu

  • Reguły zapory: można dodawać, usuwać lub modyfikować.
  • Warstwa, rozmiar magazynu: w przypadku operacji "podwyższanie poziomu do serwera podstawowego" musi być taka sama jak podstawowa. W przypadku operacji "podwyższanie poziomu do niezależnego serwera i usuwanie z replikacji" może być taka sama lub wyższa niż podstawowa.
  • Warstwa wydajności (IOPS): regulowane.
  • Metoda uwierzytelniania: Regulowane, opcje obejmują przełączanie z uwierzytelniania PostgreSQL do firmy Microsoft Entra.
  • Parametry serwera: Większość z tych parametrów jest regulowanych. Jednak osoby wpływające na rozmiar pamięci udostępnionej powinny być zgodne z podstawowymi scenariuszami, szczególnie w przypadku scenariuszy "podwyższania poziomu do serwera podstawowego". W przypadku operacji "podwyższanie poziomu do niezależnego serwera i usuwanie z replikacji" te parametry powinny być takie same lub przekraczać te na serwerze podstawowym.
  • Harmonogram konserwacji: regulowany.

Nieobsługiwane funkcje replik do odczytu

Niektóre funkcje są ograniczone do serwerów podstawowych i nie można ich skonfigurować w replikach do odczytu. Są to:

  • Kopie zapasowe, w tym kopie zapasowe geograficzne.
  • Wysoka dostępność (HA)

Jeśli źródłowe wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL jest szyfrowane przy użyciu kluczy zarządzanych przez klienta, zapoznaj się z dokumentacją, aby zapoznać się z innymi zagadnieniami.

Nawiązywanie połączenia z repliką

Podczas tworzenia repliki dziedziczy reguły zapory lub punkt końcowy usługi sieci wirtualnej serwera podstawowego. Te reguły mogą zostać zmienione podczas tworzenia repliki i w dowolnym późniejszym momencie.

Replika dziedziczy konto administratora z serwera podstawowego. Wszystkie konta użytkowników na serwerze podstawowym są replikowane do replik do odczytu. Można nawiązać połączenie tylko z repliką do odczytu przy użyciu kont użytkowników dostępnych na serwerze podstawowym.

Istnieją dwie metody nawiązywania połączenia z repliką:

  • Bezpośrednio do wystąpienia repliki: możesz nawiązać połączenie z repliką przy użyciu jego nazwy hosta i prawidłowego konta użytkownika, tak jak w przypadku zwykłego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. W przypadku serwera o nazwie myreplica z nazwą użytkownika administratora myadmin możesz nawiązać połączenie z repliką przy użyciu polecenia psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Po wyświetleniu monitu wprowadź hasło dla konta użytkownika.

Ponadto w celu ułatwienia procesu połączenia witryna Azure Portal udostępnia gotowe do użycia parametry połączenia. Można je znaleźć na stronie Połączenie. Obejmują one zarówno libpq zmienne, jak i parametry połączenia dostosowane do konsoli powłoki bash.

  • Za pośrednictwem wirtualnych punktów końcowych: istnieje alternatywna metoda połączenia przy użyciu wirtualnych punktów końcowych, zgodnie z opisem w artykule Virtual endpoints (Wirtualne punkty końcowe). Korzystając z wirtualnych punktów końcowych, można skonfigurować punkt końcowy tylko do odczytu, aby konsekwentnie wskazywał replikę, niezależnie od tego, który serwer obecnie posiada rolę repliki.

Monitorowanie replikacji

Funkcja repliki do odczytu na serwerze elastycznym usługi Azure Database for PostgreSQL opiera się na mechanizmie miejsc replikacji. Główną zaletą miejsc replikacji jest automatyczne dostosowanie liczby dzienników transakcji (segmentów WAL) wymaganych przez wszystkie serwery repliki. Dzięki temu repliki nie będą synchronizowane, ponieważ zapobiega to usuwaniu segmentów WAL na serwerze podstawowym przed ich wysłaniem do replik. Wadą podejścia jest ryzyko wyjścia z miejsca na podstawowym w przypadku, gdy miejsce replikacji pozostaje nieaktywne przez dłuższy czas. W takich sytuacjach podstawowa gromadzi pliki WAL powodujące przyrostowy wzrost użycia magazynu. Gdy użycie magazynu osiągnie 95% lub jeśli dostępna pojemność jest mniejsza niż 5 GiB, serwer jest automatycznie przełączany do trybu tylko do odczytu, aby uniknąć błędów związanych z sytuacjami pełnymi dysku.
W związku z tym monitorowanie opóźnienia replikacji i stanu miejsc replikacji ma kluczowe znaczenie dla replik do odczytu.

Zalecamy ustawienie reguł alertów dotyczących użycia magazynu lub procentu magazynu oraz opóźnienia replikacji, gdy przekraczają one określone progi, aby można było aktywnie działać, zwiększyć rozmiar magazynu i usunąć opóźnione repliki do odczytu. Można na przykład ustawić alert, jeśli wartość procentowa magazynu przekracza 80% użycia, a opóźnienie repliki jest wyższe niż 5 minut. Metryka Użyty magazyn dzienników transakcji pokazuje, czy akumulacja plików WAL jest główną przyczyną nadmiernego użycia magazynu.

Serwer elastyczny usługi Azure Database for PostgreSQL udostępnia dwie metryki do monitorowania replikacji. Dwie metryki to Maksymalne opóźnienie replikacji fizycznej i Opóźnienie repliki do odczytu. Aby dowiedzieć się, jak wyświetlić te metryki, zobacz sekcję Monitorowanie repliki artykułu z instrukcjami dotyczącymi repliki do odczytu.

Metryka Maksymalne opóźnienie replikacji fizycznej pokazuje opóźnienie w bajtach między repliką podstawową i najbardziej opóźniającą. Ta metryka ma zastosowanie i jest dostępna tylko na serwerze podstawowym i będzie dostępna tylko wtedy, gdy co najmniej jedna replika do odczytu jest połączona z serwerem podstawowym. Informacje o opóźnieniu są obecne również wtedy, gdy replika jest w trakcie nadrabiania zaległości przy użyciu elementu podstawowego, podczas tworzenia repliki lub gdy replikacja staje się nieaktywna.

Metryka Opóźnienie repliki do odczytu pokazuje czas od ostatniej ponownej transakcji. Jeśli na przykład na serwerze podstawowym nie występują żadne transakcje, a ostatnia transakcja została odtworzona 5 sekund temu, opóźnienie repliki do odczytu pokazuje 5-sekundowe opóźnienie. Ta metryka ma zastosowanie i jest dostępna tylko w replikach.

Ustaw alert, aby poinformować Cię, gdy opóźnienie repliki osiągnie wartość, która nie jest akceptowalna dla obciążenia.

Aby uzyskać więcej szczegółowych informacji, wykonaj zapytanie dotyczące serwera podstawowego bezpośrednio, aby uzyskać opóźnienie replikacji we wszystkich replikach.

Uwaga

Jeśli serwer podstawowy lub replika do odczytu zostanie uruchomiony ponownie, czas ponownego uruchomienia i nadrobienie zaległości zostanie odzwierciedlone w metryce Opóźnienie repliki.

Stan replikacji

Aby monitorować postęp i stan replikacji oraz podwyższyć poziom operacji, zapoznaj się z kolumną Stan replikacji w witrynie Azure Portal. Ta kolumna znajduje się na stronie replikacji i wyświetla różne stany, które zapewniają wgląd w bieżący stan replik do odczytu i ich link do podstawowego. W przypadku użytkowników korzystających z interfejsu API usługi Azure Resource Manager podczas wywoływania interfejsu GetReplica API stan jest wyświetlany jako ReplicationState w torbie replica właściwości.

Poniżej przedstawiono możliwe wartości:

Stan replikacji Opis Podwyższanie poziomu zamówienia Kolejność tworzenia repliki do odczytu
Ponownej konfiguracji Oczekiwanie na początek łącza podstawowego repliki. Może on pozostać dłuższy, jeśli replika lub jej region jest niedostępny, na przykład z powodu awarii. 1 Nie dotyczy
Inicjowania obsługi Replika do odczytu jest aprowizowana, a replikacja między dwoma serwerami nie została jeszcze uruchomiona. Dopóki aprowizacja nie zostanie ukończona, nie będzie można nawiązać połączenia z repliką do odczytu. Nie dotyczy 1
Aktualizacji Konfiguracja serwera jest przygotowywana po wyzwalanej akcji, takiej jak podwyższanie poziomu lub tworzenie repliki do odczytu. 2 2
Nadrabianie zaległości Pliki WAL są stosowane w repliki. Czas trwania tej fazy podczas podwyższania poziomu zależy od wybranej opcji synchronizacji danych — planowanej lub wymuszonej. 3 3
Aktywne Stan w dobrej kondycji wskazujący, że replika do odczytu została pomyślnie połączona z serwerem podstawowym. Jeśli serwery zostaną zatrzymane, ale zostały pomyślnie połączone wcześniej, stan pozostaje aktywny. 4 4
Złamane Stan złej kondycji wskazujący, że operacja podwyższania poziomu mogła zakończyć się niepowodzeniem lub replika nie może nawiązać połączenia z serwerem podstawowym z jakiegoś powodu. Upuść replikę i utwórz ponownie replikę, aby rozwiązać ten problem". Brak Brak

Dowiedz się, jak monitorować replikację.

Kwestie wymagające rozważenia

Ta sekcja zawiera podsumowanie zagadnień dotyczących funkcji repliki do odczytu. Należy wziąć pod uwagę następujące kwestie.

  • Operacje zasilania: operacje zasilania, w tym akcje uruchamiania i zatrzymywania, mogą być stosowane zarówno do serwerów podstawowych, jak i replik. Jednak aby zachować integralność systemu, należy wykonać określoną sekwencję. Przed zatrzymaniem replik do odczytu upewnij się, że serwer podstawowy został zatrzymany jako pierwszy. Podczas rozpoczynania operacji zainicjuj akcję uruchamiania na serwerach repliki przed uruchomieniem serwera podstawowego.
  • Jeśli serwer ma repliki do odczytu, przed usunięciem serwera podstawowego należy najpierw usunąć repliki do odczytu.
  • Uaktualnienie wersji głównej na serwerze elastycznym usługi Azure Database for PostgreSQL wymaga usunięcia wszystkich replik do odczytu, które są obecnie włączone na serwerze. Po usunięciu replik można uaktualnić serwer podstawowy do żądanej wersji głównej. Po zakończeniu uaktualniania można ponownie utworzyć repliki, aby wznowić proces replikacji.
  • Ssd w warstwie Premium w wersji 2: od bieżącej wersji, jeśli serwer podstawowy używa dysku SSD w warstwie Premium w wersji 2 do magazynowania, tworzenie replik do odczytu nie jest obsługiwane.
  • Resetowanie hasła administratora: resetowanie hasła administratora na serwerze repliki nie jest obecnie obsługiwane. Ponadto aktualizowanie hasła administratora wraz z promowaniem operacji repliki w tym samym żądaniu również nie jest obsługiwane. Jeśli chcesz to zrobić, musisz najpierw podwyższyć poziom serwera repliki, a następnie zaktualizować hasło na nowo promowanym serwerze oddzielnie.

Nowe repliki

Replika do odczytu jest tworzona jako nowe wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL. Nie można utworzyć istniejącego serwera w repliki. Nie można utworzyć repliki innej repliki do odczytu, czyli replikacji kaskadowej nie jest obsługiwana.

Przenoszenie zasobów

Użytkownicy mogą tworzyć repliki do odczytu w innej grupie zasobów niż podstawowa. Jednak przeniesienie replik do innej grupy zasobów po ich utworzeniu jest nieobsługiwane. Ponadto przeniesienie replik do innej subskrypcji i przeniesienie podstawowej replik z replikami do odczytu do innej grupy zasobów lub subskrypcji nie jest obsługiwane.

Automatyczne skalowanie magazynu

Podczas konfigurowania replik do odczytu dla wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL należy upewnić się, że ustawienie automatycznego zwiększania magazynu na replikach jest zgodne z ustawieniem serwera podstawowego. Funkcja automatycznego zwiększania magazynu umożliwia automatyczne zwiększenie magazynu bazy danych, aby zapobiec wyczerpaniu miejsca, co może prowadzić do awarii bazy danych. Poniżej przedstawiono sposób efektywnego zarządzania ustawieniami automatycznego zwiększania rozmiaru magazynu:

  • Autogrow magazynu można włączyć w dowolnej repliki niezależnie od ustawienia serwera podstawowego.
  • Jeśli funkcja automatycznego zwiększania magazynu jest włączona na serwerze podstawowym, należy ją również włączyć w replikach, aby zapewnić spójność zachowania skalowania magazynu.
  • Aby włączyć automatyczne skalowanie magazynu na serwerze podstawowym, należy najpierw włączyć ją w replikach. Ta kolejność operacji ma kluczowe znaczenie dla zachowania integralności replikacji.
  • Z drugiej strony, jeśli chcesz wyłączyć automatyczne zwiększanie magazynu, zacznij od wyłączenia go na serwerze podstawowym przed replikami, aby uniknąć komplikacji replikacji.

Tworzenie kopii zapasowej i przywracanie

Podczas zarządzania kopiami zapasowymi i przywracaniem dla wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL należy pamiętać o bieżącej i poprzedniej roli serwera w różnych scenariuszach podwyższania poziomu. Oto kluczowe kwestie, które należy zapamiętać:

Podwyższanie poziomu do serwera podstawowego

  1. Żadne kopie zapasowe nie są pobierane z replik do odczytu: kopie zapasowe nigdy nie są pobierane z serwerów replik do odczytu, niezależnie od ich poprzedniej roli.

  2. Zachowywanie poprzednich kopii zapasowych: jeśli serwer był kiedyś podstawowym i ma kopie zapasowe wykonywane w tym okresie, te kopie zapasowe są zachowywane. Zostaną one zachowane do okresu przechowywania zdefiniowanego przez użytkownika.

  3. Ograniczenia operacji przywracania: nawet jeśli istnieją wcześniejsze kopie zapasowe dla serwera, który przeszedł do repliki do odczytu, operacje przywracania są ograniczone. Operację przywracania można zainicjować tylko wtedy, gdy serwer został podwyższony z powrotem do roli podstawowej.

Aby uzyskać jasność, oto tabela ilustrująca następujące kwestie:

Rola serwera Wykonano kopię zapasową Dozwolone przywracanie
Podstawowe Tak Tak
Replika do odczytu Nie Nie.
Replika do odczytu podwyższona do poziomu podstawowego Tak Tak

Podwyższ poziom do niezależnego serwera i usuń z replikacji

Serwer jest repliką do odczytu, ale nie są wykonywane żadne kopie zapasowe. Jednak po podwyższeniu poziomu do niezależnego serwera zarówno promowany serwer, jak i serwer podstawowy mają wykonane kopie zapasowe, a przywracanie jest dozwolone w obu tych przypadkach.

Sieć

Repliki do odczytu obsługują wszystkie opcje sieciowe obsługiwane przez serwer elastyczny usługi Azure Database for PostgreSQL.

Ważne

Dwukierunkowa komunikacja między serwerem podstawowym i replikami do odczytu ma kluczowe znaczenie dla elastycznej konfiguracji serwera usługi Azure Database for PostgreSQL. Musi istnieć aprowizacja wysyłania i odbierania ruchu na porcie docelowym 5432 w podsieci sieci wirtualnej platformy Azure.

Powyższe wymaganie nie tylko ułatwia proces synchronizacji, ale także zapewnia prawidłowe funkcjonowanie mechanizmu podwyższania poziomu, w którym repliki mogą wymagać komunikacji w odwrotnej kolejności — od repliki do podstawowej — zwłaszcza podczas podwyższania poziomu do operacji podstawowych. Ponadto połączenia z kontem usługi Azure Storage, które przechowuje archiwa zapisu i rejestrowania z wyprzedzeniem (WAL, Write-Ahead Logging) muszą być dozwolone, aby zapewnić trwałość danych i umożliwić wydajne procesy odzyskiwania.

Aby uzyskać więcej informacji na temat konfigurowania dostępu prywatnego (integracji sieci wirtualnej) dla replik do odczytu i zrozumienia skutków replikacji między regionami platformy Azure i sieciami wirtualnymi w kontekście sieci prywatnej, zobacz stronę Replikacja między regionami platformy Azure i sieciami wirtualnymi z siecią prywatną.

Rozwiązywanie problemów z miejscem replikacji

W rzadkich przypadkach duże opóźnienie spowodowane przez miejsca replikacji może prowadzić do zwiększenia użycia magazynu na serwerze podstawowym z powodu skumulowanych plików WAL. Jeśli użycie magazynu osiągnie 95% lub dostępna pojemność spadnie poniżej 5 GiB, serwer automatycznie przełącza się do trybu tylko do odczytu, aby zapobiec błędom pełnym dysku.

Ponieważ utrzymanie kondycji i funkcjonalności serwera podstawowego jest priorytetem, w takich przypadkach brzegowych miejsce replikacji może zostać usunięte w celu zapewnienia, że serwer podstawowy pozostaje operacyjny dla ruchu odczytu i zapisu. Dlatego replikacja przełącza się do trybu wysyłania dziennika opartego na plikach, co może spowodować większe opóźnienie replikacji.

Ważne jest, aby ściśle monitorować użycie magazynu i replikację oraz podejmować niezbędne działania, aby rozwiązać potencjalne problemy przed ich eskalacją.

Parametry serwera

Po utworzeniu repliki do odczytu dziedziczy ona parametry serwera z serwera podstawowego. Jest to zapewnienie spójnego i niezawodnego punktu wyjścia. Jednak wszelkie zmiany parametrów serwera na serwerze podstawowym wprowadzone po utworzeniu repliki do odczytu nie są automatycznie replikowane. To zachowanie oferuje zaletę indywidualnego dostrajania repliki do odczytu, takich jak zwiększenie wydajności operacji intensywnie korzystających z odczytu bez modyfikowania parametrów serwera podstawowego. Chociaż zapewnia to elastyczność i opcje dostosowywania, wymaga również starannego i ręcznego zarządzania, aby zachować spójność między repliką podstawową i repliką, gdy wymagana jest jednolitość parametrów serwera.

Administracja istratory mogą zmieniać parametry serwera na serwerze repliki do odczytu i ustawiać różne wartości niż na serwerze podstawowym. Jedynym wyjątkiem są parametry, które mogą mieć wpływ na odzyskiwanie repliki, wymienione również w sekcji "Skalowanie" poniżej: max_connections, , max_prepared_transactionsmax_locks_per_transaction, max_wal_senders, , max_worker_processes. Aby upewnić się, że odzyskiwanie repliki do odczytu jest bezproblemowe i nie napotyka ograniczeń pamięci udostępnionej, te konkretne parametry powinny być zawsze ustawione na wartości, które są równoważne lub większe niż te skonfigurowane na serwerze podstawowym.

Skaluj

Możesz skalować w górę i w dół zasoby obliczeniowe (rdzenie wirtualne), zmieniając warstwę usługi z Ogólnego przeznaczenia na Zoptymalizowane pod kątem pamięci (lub odwrotnie) i skalując magazyn w górę, ale obowiązują następujące zastrzeżenia.

W przypadku skalowania obliczeń:

  • Serwer elastyczny usługi Azure Database for PostgreSQL wymaga kilku parametrów replik, które mają być większe niż lub równe ustawieniu na serwerze podstawowym , aby upewnić się, że replika nie zabraknie pamięci współużytkowanej podczas odzyskiwania. Parametry, których dotyczy problem, to: max_connections, , max_prepared_transactionsmax_locks_per_transaction, max_wal_senders, . max_worker_processes

  • Skalowanie w górę: najpierw przeprowadź skalowanie w górę zasobów obliczeniowych repliki, a następnie przeprowadź skalowanie w górę podstawowego.

  • Skalowanie w dół: najpierw skaluj w dół zasoby obliczeniowe podstawowe, a następnie skaluj replikę w dół.

  • Obliczenia na serwerze podstawowym muszą być zawsze równe lub mniejsze niż obliczenia na najmniejszej repliki.

W przypadku skalowania magazynu:

  • Skalowanie w górę: najpierw przeprowadź skalowanie w górę magazynu repliki, a następnie przeprowadź skalowanie w górę podstawowego.

  • Rozmiar magazynu w podstawowej wersji musi być zawsze równy lub mniejszy niż rozmiar magazynu w najmniejszej repliki.

Powiązana zawartość