Repliki do odczytu w usłudze 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?.

Funkcja repliki do odczytu umożliwia replikowanie danych z serwera usługi Azure Database for PostgreSQL do serwera tylko do odczytu. Repliki są aktualizowane asynchronicznie za pomocą natywnej technologii replikacji fizycznej aparatu PostgreSQL. Można replikować z serwera podstawowego do maksymalnie pięciu replik.

Repliki to nowe serwery, którymi można zarządzać podobnie jak zwykłymi serwerami 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 jako serwer odczytu/zapisu w przypadku odzyskiwania po awarii.

W typowym scenariuszu obciążenia analizy biznesowej i analizy używają replik 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

Ta funkcja jest przeznaczona dla scenariuszy, w których opóźnienie jest akceptowalne i przeznaczone do odciążania zapytań. Nie jest przeznaczona dla scenariuszy replikacji synchronicznej, w których oczekuje się, że dane repliki będą aktualne. Między repliką podstawową a repliką wystąpi mierzalne opóźnienie. Może to potrwać kilka minut, a nawet godzin, w zależności od obciążenia i opóźnienia między repliką podstawową a repliką. 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 i intensywnych pod względem zapisu obciążeń opóźnienie replikacji mogłoby wzrastać i nigdy nie nadgonić serwera podstawowego. Może to również zwiększyć użycie magazynu na serwerze podstawowym, ponieważ pliki WAL nie są usuwane, dopóki nie zostaną odebrane na replice. Jeśli ta sytuacja się utrzymuje, usunięcie i utworzenie ponownie repliki do odczytu po zakończeniu obciążeń intensywnych pod względem zapisu jest jedną z możliwości przywrócenia dobrego stanu opóźnienia repliki. 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 w repliki pod kątem pełnego cyklu obciążenia roboczego aplikacji przez okres szczytowy i inny niż szczyt, aby uzyskać dostęp do możliwego opóźnienia i oczekiwanego celu czasu odzyskiwania/celu punktu odzyskiwania w różnych punktach cyklu obciążenia.

Uwaga

Automatyczne kopie zapasowe są wykonywane dla serwerów replik skonfigurowanych z maksymalnie 4 TB konfiguracji magazynu.

Replikacja między regionami

Replikę do odczytu można utworzyć w innym regionie niż serwer podstawowy. Replikacja między regionami może być przydatna w scenariuszach, takich jak planowanie odzyskiwania po awarii lub przybliżanie danych do użytkowników.

Uwaga

Serwery w warstwie Podstawowa obsługują tylko replikację w tym samym regionie.

Serwer podstawowy może znajdować się w dowolnym regionie usługi Azure Database for PostgreSQL. Serwer podstawowy może mieć replikę w sparowanym regionie lub w regionach repliki uniwersalnej. Na poniższej ilustracji przedstawiono, które regiony repliki są dostępne w zależności od regionu podstawowego.

Regiony repliki do odczytu

Regiony repliki uniwersalnej

Zawsze można utworzyć replikę do odczytu w dowolnym z następujących regionów, niezależnie od tego, gdzie znajduje się serwer podstawowy. Są to regiony repliki uniwersalnej:

Australia Wschodnia, Australia Południowo-Wschodnia, Brazylia Południowa, Kanada Środkowa, Kanada Wschodnia, Środkowe stany USA, Azja Wschodnia, Wschodnie stany USA, Wschodnie stany USA, Wschodnie stany USA, Japonia Zachodnia, Korea Środkowa, Korea Południowa, Północno-środkowe stany USA, Europa Południowo-Środkowa, Azja Południowo-Wschodnia, Południowe Zjednoczone Królestwo, Zachodnie stany USA, Europa Zachodnia, Zachodnie stany USA 2, Zachodnie stany USA.

Sparowane regiony

Oprócz regionów repliki uniwersalnej można utworzyć replikę do odczytu w sparowanym regionie platformy Azure serwera podstawowego. Jeśli nie znasz pary regionów, możesz dowiedzieć się więcej z artykułu Regiony sparowane platformy Azure.

Jeśli używasz replik między regionami do planowania odzyskiwania po awarii, zalecamy utworzenie repliki w sparowanym regionie zamiast jednego z pozostałych regionów. Sparowane regiony unikają równoczesnych aktualizacji i określania priorytetów izolacji fizycznej i rezydencji danych.

Istnieją ograniczenia, które należy wziąć pod uwagę:

  • Pary jednokierunkowe: niektóre regiony platformy Azure są sparowane tylko w jednym kierunku. Te regiony obejmują Indie Zachodnie, Brazylia Południowa. Oznacza to, że serwer podstawowy w Indiach Zachodnich może utworzyć replikę w Indiach Południowych. Jednak serwer podstawowy w Indiach Południowych nie może utworzyć repliki w Indiach Zachodnich. Wynika to z faktu, że region pomocniczy Indii Zachodnich to Indie Południowe, ale region pomocniczy Indii Południowych nie jest Indiami Zachodnimi.

Tworzenie repliki

Po uruchomieniu przepływu pracy tworzenia repliki tworzony jest pusty serwer usługi Azure Database for PostgreSQL. Nowy serwer jest wypełniany danymi, które znajdowały się na serwerze podstawowym. Czas tworzenia zależy od ilości danych bazy podstawowej i czasu od ostatniego tygodniowego tworzenia pełnej kopii zapasowej. Czas może wahać się od kilku minut do kilku godzin.

Każda replika jest włączona do automatycznego zwiększania rozmiaru magazynu. Funkcja automatycznego zwiększania umożliwia replikom nadążanie za replikowanymi danymi i zapobieganie przerwie w replikacji spowodowanej przez błędy braku pamięci masowej.

Funkcja repliki do odczytu używa replikacji fizycznej PostgreSQL, a nie replikacji logicznej. Domyślnym trybem operacji jest replikacja strumieniowa przy użyciu miejsc replikacji. W razie potrzeby do nadganiania służy wysyłanie dziennika.

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

Jeśli źródłowy serwer PostgreSQL jest szyfrowany przy użyciu kluczy zarządzanych przez klienta, zobacz dokumentację, aby zapoznać się z dodatkowymi zagadnieniami.

Nawiązywanie połączenia z repliką

Podczas tworzenia repliki nie dziedziczy reguł zapory ani punktu końcowego usługi sieci wirtualnej serwera podstawowego. Te reguły muszą być konfigurowane niezależnie dla repliki.

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

Możesz nawiązać połączenie z repliką przy użyciu jego nazwy hosta i prawidłowego konta użytkownika, tak jak na zwykłym serwerze usługi Azure Database for PostgreSQL. W przypadku serwera o nazwie moja replika z nazwą administratora myadmin możesz nawiązać połączenie z repliką przy użyciu narzędzia psql:

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

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

Monitorowanie replikacji

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

Metryka Max Lag Across Replicas pokazuje opóźnienie w bajtach między repliką podstawową a najbardziej opóźniającą się repliką. 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, a podstawowy jest w trybie replikacji przesyłania strumieniowego. Informacje o opóźnieniu nie pokazują szczegółów, gdy replika jest w trakcie nadrobienia zaległości w podstawowej korzystaniu z zarchiwizowanych dzienników podstawowego w trybie replikacji wysyłania plików.

Metryka Opóźnienie repliki pokazuje czas od ostatniej ponownej transakcji. Jeśli na serwerze podstawowym nie występują żadne transakcje, metryka odzwierciedla to opóźnienie czasu. Ta metryka ma zastosowanie i jest dostępna tylko dla serwerów repliki. Opóźnienie repliki jest obliczane z pg_stat_wal_receiver widoku:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

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

Aby uzyskać dodatkowe informacje, wykonaj zapytanie dotyczące serwera podstawowego bezpośrednio, aby uzyskać opóźnienie replikacji w bajtach 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.

Zatrzymywanie replikacji/podwyższanie poziomu repliki

Replikację między serwerem podstawowym i repliką można zatrzymać w dowolnym momencie. Akcja zatrzymania powoduje ponowne uruchomienie repliki i podwyższa poziom repliki do niezależnego, autonomicznego serwera do odczytu i zapisu. Dane na tym serwerze autonomicznym to dane, które były dostępne na serwerze repliki w momencie zatrzymania replikacji. Wszystkie kolejne aktualizacje w lokalizacji podstawowej nie są propagowane do repliki. Jednak serwer repliki może mieć skumulowane dzienniki, które nie są jeszcze stosowane. W ramach procesu ponownego uruchamiania replika stosuje wszystkie oczekujące dzienniki przed zaakceptowaniem połączeń klienta.

Uwaga

Resetowanie hasła administratora na serwerze repliki nie jest obecnie obsługiwane. Ponadto aktualizowanie hasła administratora wraz z operacją podwyższania poziomu 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.

Kwestie wymagające rozważenia

  • Przed zatrzymaniem replikacji w repliki do odczytu sprawdź opóźnienie replikacji, aby upewnić się, że replika ma wszystkie wymagane dane.
  • Ponieważ replika do odczytu musi zastosować wszystkie oczekujące dzienniki, zanim będzie można utworzyć autonomiczny serwer, cel czasu odzyskiwania może być wyższy w przypadku dużych obciążeń zapisu, gdy replikacja zatrzymania może wystąpić, ponieważ może wystąpić znaczne opóźnienie w repliki. Zwróć uwagę na to podczas planowania podwyższenia poziomu repliki.
  • Nie można ponownie utworzyć promowanego serwera repliki w replikę.
  • W przypadku podwyższenia poziomu repliki do serwera podstawowego nie można ustanowić replikacji z powrotem do starego serwera podstawowego. Jeśli chcesz wrócić do starego regionu podstawowego, możesz ustanowić nowy serwer repliki z nową nazwą (lub) usunąć stary serwer podstawowy i utworzyć replikę, używając starej nazwy serwera podstawowego.
  • Jeśli masz wiele replik do odczytu i podwyższysz poziom jednej z nich do serwera podstawowego, pozostałe serwery repliki nadal będą połączone ze starym serwerem podstawowym. Konieczne może być ponowne utworzenie replik z nowego serwera o podwyższonym poziomie.

Po zatrzymaniu replikacji replika traci wszystkie łącza do poprzednich replik podstawowych i innych.

Dowiedz się, jak zatrzymać replikację do repliki.

Przechodzenie w tryb failover do repliki

W przypadku awarii serwera podstawowego nie jest on automatycznie przełączony w tryb failover do repliki do odczytu.

Ponieważ replikacja jest asynchroniczna, może wystąpić znaczne opóźnienie między repliką podstawową a repliką. Wpływ na opóźnienie ma wiele czynników, takich jak typ obciążenia uruchomionego na serwerze podstawowym i opóźnienie między serwerem podstawowym a serwerem repliki. W typowych przypadkach z nominalnym obciążeniem zapisu opóźnienie repliki jest oczekiwane od kilku sekund do kilku minut. Jednak w przypadkach, gdy podstawowe działa bardzo duże obciążenie intensywnie korzystające z zapisu, a replika nie nadrabia zaległości wystarczająco szybko, opóźnienie może być znacznie wyższe. Opóźnienie replikacji dla każdej repliki można śledzić przy użyciu metryki Opóźnienie repliki. Ta metryka pokazuje czas od ostatniej ponownej transakcji w replice. Zalecamy zidentyfikowanie średniego opóźnienia przez zaobserwowanie opóźnienia repliki w danym okresie. Możesz ustawić alert dotyczący opóźnienia repliki, aby jeśli wykracza poza oczekiwany zakres, otrzymasz powiadomienie o podjęciu akcji.

Napiwek

Jeśli przejdziesz w tryb failover do repliki, opóźnienie w momencie odłączenia repliki od podstawowego będzie wskazywać, ile danych zostanie utraconych.

Po podjęciu decyzji, że chcesz przejść w tryb failover do repliki,

  1. Zatrzymywanie replikacji do repliki
    Ten krok jest niezbędny, aby serwer repliki stał się serwerem autonomicznym i mógł akceptować zapisy. W ramach tego procesu serwer repliki zostanie uruchomiony ponownie i zostanie odłączony od serwera podstawowego. Po zainicjowaniu zatrzymywania replikacji proces zaplecza zwykle trwa kilka minut, aby zastosować wszystkie dzienniki reszt, które nie zostały jeszcze zastosowane, i otworzyć bazę danych jako serwer z możliwością odczytu i zapisu. Zobacz sekcję Zatrzymywanie replikacji w tym artykule, aby zrozumieć implikacje tej akcji.

  2. Wskazywanie aplikacji na replikę (dawniej)
    Każdy serwer ma unikatowy parametry połączenia. Zaktualizuj aplikację parametry połączenia, aby wskazywała (poprzednią) replikę zamiast podstawowej.

Po pomyślnym przetworzeniu odczytów i zapisów w aplikacji ukończono tryb failover. Czas przestoju środowiska aplikacji zależy od momentu wykrycia problemu i wykonania kroków 1 i 2 powyżej.

Odzyskiwanie po awarii

W przypadku wystąpienia poważnych awarii, takich jak awarie na poziomie strefy dostępności lub awarii regionalnych, można wykonać operację odzyskiwania po awarii, promując replikę do odczytu. W portalu interfejsu użytkownika można przejść do serwera repliki do odczytu. Następnie wybierz kartę replikacji i możesz zatrzymać replikę, aby podwyższyć jej poziom do niezależnego serwera. Alternatywnie możesz użyć interfejsu wiersza polecenia platformy Azure, aby zatrzymać i podwyższyć poziom serwera repliki.

Kwestie wymagające rozważenia

Ta sekcja zawiera podsumowanie zagadnień dotyczących funkcji repliki do odczytu.

Wymagania wstępne

Repliki do odczytu i dekodowanie logiczne zależą od dziennika z wyprzedzeniem zapisu Postgres (WAL) w celu uzyskania informacji. Te dwie funkcje wymagają różnych poziomów rejestrowania z bazy danych Postgres. Dekodowanie logiczne wymaga wyższego poziomu rejestrowania niż repliki do odczytu.

Aby skonfigurować odpowiedni poziom rejestrowania, użyj parametru obsługi replikacji platformy Azure. Obsługa replikacji platformy Azure ma trzy opcje ustawień:

  • Wyłączone — umieszcza najmniej informacji w pliku WAL. To ustawienie nie jest dostępne na większości serwerów usługi Azure Database for PostgreSQL.
  • Replika — więcej informacji niż wyłączone. Jest to minimalny poziom rejestrowania potrzebny do pracy replik do odczytu. To ustawienie jest ustawieniem domyślnym dla większości serwerów.
  • Logiczne — bardziej pełne niż replika. Jest to minimalny poziom rejestrowania dla dekodowania logicznego do pracy. Repliki do odczytu działają również w tym ustawieniu.

Nowe repliki

Replika do odczytu jest tworzona jako nowy serwer usługi Azure Database for PostgreSQL. Nie można utworzyć istniejącego serwera w repliki. Nie można utworzyć repliki innej repliki do odczytu.

Konfiguracja repliki

Replika jest tworzona przy użyciu tych samych ustawień obliczeniowych i magazynu co podstawowa. Po utworzeniu repliki można zmienić kilka ustawień, w tym okres przechowywania magazynu i kopii zapasowej.

Reguły zapory, reguły sieci wirtualnej i ustawienia parametrów nie są dziedziczone z serwera podstawowego do repliki podczas tworzenia repliki lub później.

Skalowanie

Skalowanie rdzeni wirtualnych lub między warstwą Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci:

  • Baza danych PostgreSQL wymaga max_connections , aby ustawienie na serwerze pomocniczym było większe lub równe ustawieniu na serwerze podstawowym. W przeciwnym razie pomocnicze nie zostanie uruchomione.
  • W usłudze Azure Database for PostgreSQL maksymalna dozwolona liczba dozwolonych połączeń dla każdego serwera jest stała dla jednostki SKU obliczeniowej, ponieważ połączenia zajmują pamięć. Więcej informacji na temat mapowania między jednostkami SKU max_connections i obliczeniowymi.
  • Skalowanie w górę: najpierw przeprowadź skalowanie w górę zasobów obliczeniowych repliki, a następnie przeprowadź skalowanie w górę podstawowego. To zamówienie zapobiegnie naruszeniu max_connections wymagania przez błędy.
  • Skalowanie w dół: najpierw skaluj w dół zasoby obliczeniowe podstawowe, a następnie skaluj replikę w dół. Jeśli spróbujesz przeskalować replikę niższą niż podstawowa, wystąpi błąd, ponieważ narusza max_connections to wymaganie.

Skalowanie magazynu:

  • Wszystkie repliki mają włączoną funkcję automatycznego zwiększania magazynu, aby zapobiec problemom z replikacją z repliki pełnej magazynu. Tego ustawienia nie można wyłączyć.
  • Możesz również ręcznie skalować magazyn w górę, tak jak na dowolnym innym serwerze

Warstwa Podstawowa

Serwery w warstwie Podstawowa obsługują tylko replikację w tym samym regionie.

max_prepared_transactions

Baza danych PostgreSQL wymaga , aby wartość parametru max_prepared_transactions repliki do odczytu była większa lub równa wartości podstawowej. W przeciwnym razie replika nie zostanie uruchomiona. Jeśli chcesz zmienić max_prepared_transactions element podstawowy, najpierw zmień ją na replikach.

Zatrzymane repliki

Jeśli zatrzymasz replikację między serwerem podstawowym a repliką do odczytu, replika zostanie ponownie uruchomiona, aby zastosować zmianę. Zatrzymana replika staje się autonomicznym serwerem, który akceptuje zarówno operacje odczytu, jak i zapisu. Nie można ponownie utworzyć autonomicznego serwera w repliki.

Usunięte serwery podstawowe i autonomiczne

Po usunięciu serwera podstawowego wszystkie jego repliki do odczytu stają się serwerami autonomicznymi. Repliki są ponownie uruchamiane, aby odzwierciedlić tę zmianę.

Następne kroki