Udostępnij za pośrednictwem

Ograniczenia w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W poniższych sekcjach opisano limity pojemności i funkcjonalności na serwerze elastycznym usługi Azure Database for PostgreSQL. Jeśli chcesz dowiedzieć się więcej na temat warstw zasobów (zasobów obliczeniowych, pamięci, magazynu), zobacz artykuły dotyczące zasobów obliczeniowych i magazynu .

Maksymalna liczba połączeń

W poniższej tabeli przedstawiono domyślną maksymalną liczbę połączeń dla każdej warstwy cenowej i konfiguracji rdzeni wirtualnych. Serwer elastyczny usługi Azure Database for PostgreSQL rezerwuje 15 połączeń na potrzeby replikacji fizycznej i monitorowania wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. W związku z tym wartość maksymalnej liczby połączeń użytkowników wymienionych w tabeli jest zmniejszana o 15 z łącznej maksymalnej liczby połączeń.

Nazwa produktu Rdzenie wirtualne Rozmiar pamięci Maksymalna liczba połączeń Maksymalna liczba połączeń użytkowników
Możliwość serii
B1MS 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 100 16 GiB 1,718 1,703
B8ms 8 32 GiB 3,437 3,422
B12ms 12 48 GiB 5,000 4,985
B16ms 16 64 GiB 5,000 4,985
B20ms 20 80 GiB 5,000 4,985
Ogólnego przeznaczenia
D2s_v3/D2ds_v4/D2ds_v5/D2ads_v5 2 8 GiB 859 844
D4s_v3/D4ds_v4/D4ds_v5/D4ads_v5 100 16 GiB 1,718 1,703
D8s_v3/D8ds_V4/D8ds_v5/D8ads_v5 8 32 GiB 3,437 3,422
D16s_v3/D16ds_v4/D16ds_v5/D16ads_v5 16 64 GiB 5,000 4,985
D32s_v3/D32ds_v4/D32ds_v5/D32ads_v5 32 128 GiB 5,000 4,985
D48s_v3/D48ds_v4/D48ds_v5/D48ads_v5 48 192 GiB 5,000 4,985
D64s_v3/D64ds_v4/D64ds_v5/D64ads_v5 64 256 GiB 5,000 4,985
D96ds_v5/D96ads_v5 96 384 GiB 5,000 4,985
Zoptymalizowane pod kątem pamięci
E2s_v3/E2ds_v4/E2ds_v5/E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3/E4ds_v4/E4ds_v5/E4ads_v5 100 32 GiB 3,437 3,422
E8s_v3/E8ds_v4/E8ds_v5/E8ads_v5 8 64 GiB 5,000 4,985
E16s_v3/E16ds_v4/E16ds_v5/E16ads_v5 16 128 GiB 5,000 4,985
E20ds_v4/E20ds_v5/E20ads_v5 20 160 GiB 5,000 4,985
E32s_v3/E32ds_v4/E32ds_v5/E32ads_v5 32 256 GiB 5,000 4,985
E48s_v3/E48ds_v4/E48ds_v5/E48ads_v5 48 384 GiB 5,000 4,985
E64s_v3/E64ds_v4/E64ds_v5/E64ads_v5 64 432 GiB 5,000 4,985
E96ds_v5/E96ads_v5 96 672 GiB 5,000 4,985

Zarezerwowane gniazda połączeń, obecnie na 15, mogą ulec zmianie. Zalecamy regularne weryfikowanie łącznej liczby połączeń zarezerwowanych na serwerze. Tę liczbę oblicza się, sumując wartości parametrów reserved_connections serwera i .superuser_reserved_connections Maksymalna liczba dostępnych połączeń użytkowników to max_connections - ( + reserved_connectionssuperuser_reserved_connections).

Wartość domyślna parametru max_connections serwera jest obliczana podczas aprowizowania wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL na podstawie nazwy produktu wybranej dla jego obliczeń. Wszelkie kolejne zmiany wyboru produktu do obliczeń, które obsługują serwer elastyczny, nie będą miały żadnego wpływu na wartość max_connections domyślną parametru serwera tego wystąpienia. Zalecamy, aby za każdym razem, gdy zmienisz produkt przypisany do wystąpienia, należy również dostosować wartość max_connections parametru zgodnie z wartościami w poprzedniej tabeli.

Zmienianie wartości max_connections

Po pierwszym skonfigurowaniu wystąpienia serwera elastycznego usługi Azure Database for Postgres automatycznie decyduje o największej liczbie połączeń, które może obsługiwać współbieżnie. Ta liczba jest oparta na konfiguracji serwera i nie można jej zmienić.

Można jednak użyć max_connections tego ustawienia, aby dostosować liczbę dozwolonych połączeń w danym momencie. Po zmianie tego ustawienia należy ponownie uruchomić serwer, aby nowy limit zaczął działać.

Uwaga

Chociaż można zwiększyć wartość max_connections poza ustawieniem domyślnym, zalecamy jej zwiększenie.

Wystąpienia mogą napotkać trudności, gdy obciążenie rozszerza się i wymaga większej ilości pamięci. Wraz ze wzrostem liczby połączeń użycie pamięci również rośnie. Wystąpienia z ograniczoną ilością pamięci mogą napotykać problemy, takie jak awarie lub duże opóźnienia. Chociaż wyższa wartość może max_connections być akceptowalna, gdy większość połączeń jest bezczynna, może to prowadzić do poważnych problemów z wydajnością po ich aktywowania.

Jeśli potrzebujesz więcej połączeń, sugerujemy, aby zamiast tego używać narzędzia PgBouncer, wbudowanego rozwiązania platformy Azure do zarządzania pulą połączeń. Użyj go w trybie transakcji. Aby rozpocząć, zalecamy użycie konserwatywnych wartości przez pomnożenie rdzeni wirtualnych w zakresie od 2 do 5. Następnie dokładnie monitoruj wykorzystanie zasobów i wydajność aplikacji, aby zapewnić płynną operację. Aby uzyskać szczegółowe informacje na temat narzędzia PgBouncer, zobacz PgBouncer w usłudze Azure Database for PostgreSQL — serwer elastyczny.

W przypadku przekroczenia limitu połączeń może zostać wyświetlony następujący błąd:

FATAL: sorry, too many clients already.

W przypadku korzystania z serwera elastycznego usługi Azure Database for PostgreSQL dla zajętej bazy danych z dużą liczbą współbieżnych połączeń może wystąpić znaczne obciążenie zasobów. To obciążenie może spowodować wysokie wykorzystanie procesora CPU, zwłaszcza gdy wiele połączeń jest nawiązywanych jednocześnie i gdy połączenia mają krótki czas trwania (mniej niż 60 sekund). Te czynniki mogą negatywnie wpłynąć na ogólną wydajność bazy danych, zwiększając czas spędzony na przetwarzaniu połączeń i rozłączeń.

Należy pamiętać, że każde połączenie na serwerze elastycznym usługi Azure Database for PostgreSQL, niezależnie od tego, czy jest bezczynne, czy aktywne, zużywa znaczną ilość zasobów z bazy danych. To użycie może prowadzić do problemów z wydajnością poza wysokim użyciem procesora CPU, takich jak rywalizacja o dyski i blokadę. W artykule Liczba połączeń bazy danych w witrynie Typu Wiki bazy danych PostgreSQL bardziej szczegółowo omówiono ten temat. Aby dowiedzieć się więcej, zobacz Identyfikowanie i rozwiązywanie problemów z wydajnością połączenia na serwerze elastycznym usługi Azure Database for PostgreSQL.

Ograniczenia funkcjonalne

W poniższych sekcjach wymieniono zagadnienia dotyczące tego, co jest i nie jest obsługiwane na serwerze elastycznym usługi Azure Database for PostgreSQL.

Operacje skalowania

  • W tej chwili skalowanie w górę magazynu serwera wymaga ponownego uruchomienia serwera.
  • Magazyn serwera można skalować tylko w 2 razy więcej, zobacz Magazyn , aby uzyskać szczegółowe informacje.
  • Zmniejszenie rozmiaru magazynu serwera nie jest obecnie obsługiwane. Jedynym sposobem wykonania jest zrzut i przywrócenie go do nowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.

Storage

  • Po skonfigurowaniu rozmiaru magazynu nie można go zmniejszyć. Musisz utworzyć nowy serwer o żądanym rozmiarze magazynu, wykonać ręczną operację zrzutu i przywracania oraz przeprowadzić migrację baz danych na nowy serwer.
  • Gdy użycie magazynu osiągnie 95% lub jeśli dostępna pojemność jest mniejsza niż 5 GiB (w zależności od tego, co więcej), serwer zostanie automatycznie przełączony do trybu tylko do odczytu, aby uniknąć błędów związanych z sytuacjami pełnymi dysku. W rzadkich przypadkach, jeśli szybkość wzrostu danych przewyższa czas przełączenia się do trybu tylko do odczytu, serwer może nadal zabraknąć miejsca do magazynowania. Możesz włączyć automatyczne zwiększanie magazynu, aby uniknąć tych problemów i automatycznie skalować magazyn na podstawie wymagań dotyczących obciążeń.
  • Zalecamy ustawienie reguł alertów dla storage used lub storage percent przekroczenia określonych progów, aby można było aktywnie podjąć działania, takie jak zwiększenie rozmiaru magazynu. Można na przykład ustawić alert, jeśli wartość procentowa magazynu przekroczy 80% użycia.
  • Jeśli używasz replikacji logicznej, musisz usunąć miejsce replikacji logicznej na serwerze podstawowym, jeśli odpowiedni subskrybent już nie istnieje. W przeciwnym razie pliki rejestrowania z wyprzedzeniem zapisu (WAL) gromadzą się w magazynie podstawowym i wypełniają magazyn. Jeśli magazyn przekroczy określony próg i jeśli miejsce replikacji logicznej nie jest używane (z powodu niedostępnego subskrybenta), serwer elastyczny usługi Azure Database for PostgreSQL automatycznie pominie to nieużywane miejsce replikacji logicznej. Ta akcja zwalnia skumulowane pliki WAL i uniemożliwia serwerowi stanie się niedostępny, ponieważ magazyn jest wypełniony.
  • Nie obsługujemy tworzenia przestrzeni tabel. Jeśli tworzysz bazę danych, nie podaj nazwy przestrzeni tabel. Serwer elastyczny usługi Azure Database for PostgreSQL używa domyślnego serwera dziedziczonego z bazy danych szablonów. Nie jest to niebezpieczne, aby zapewnić przestrzeń tabel, taką jak tymczasową, ponieważ nie możemy zagwarantować, że takie obiekty pozostaną trwałe po wystąpieniu zdarzeń, takich jak ponowne uruchomienie serwera i przejście w tryb failover o wysokiej dostępności (HA).

Sieć

  • Przenoszenie i wyjście z sieci wirtualnej nie jest obecnie obsługiwane.
  • Łączenie dostępu publicznego z wdrożeniem w sieci wirtualnej nie jest obecnie obsługiwane.
  • Reguły zapory nie są obsługiwane w sieciach wirtualnych. Zamiast tego można użyć sieciowych grup zabezpieczeń.
  • Serwery baz danych dostępu publicznego mogą łączyć się z publicznym Internetem; na przykład za pośrednictwem postgres_fdw. Nie można ograniczyć tego dostępu. Serwery w sieciach wirtualnych mogą mieć ograniczony dostęp wychodzący za pośrednictwem sieciowych grup zabezpieczeń.

Wysoka dostępność

Strefy dostępności

  • Ręczne przenoszenie serwerów do innej strefy dostępności nie jest obecnie obsługiwane. Jednak przy użyciu preferowanej strefy dostępności jako strefy rezerwowej można włączyć wysoką dostępność. Po ustanowieniu strefy rezerwowej możesz przejść do niej w tryb failover, a następnie wyłączyć wysoką dostępność.

Aparat Postgres, rozszerzenia i narzędzie PgBouncer

  • Wersje postgres 10 i starsze nie są obsługiwane, ponieważ społeczność open source wycofała je. Jeśli musisz użyć jednej z tych wersji, musisz użyć opcji pojedynczego serwera usługi Azure Database for PostgreSQL, która obsługuje starsze wersje główne 9.5, 9.6 i 10.
  • Serwer elastyczny usługi Azure Database for PostgreSQL obsługuje wszystkie contrib rozszerzenia i nie tylko. Aby uzyskać więcej informacji, zobacz Rozszerzenia PostgreSQL.
  • Wbudowany moduł puli połączeń PgBouncer nie jest obecnie dostępny dla serwerów z możliwością rozszerzenia.

Operacje zatrzymywania/uruchamiania

  • Po zatrzymaniu wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL zostanie ono automatycznie uruchomione po upływie 7 dni.

Konserwacja zaplanowana

  • Niestandardowe okno obsługi można zmienić na dowolny dzień/godzinę tygodnia. Jednak wszelkie zmiany wprowadzone po otrzymaniu powiadomienia o konserwacji nie będą miały wpływu na następną konserwację. Zmiany obowiązują tylko z następującą miesięczną zaplanowaną konserwacją.

Kopie zapasowe serwera

  • System zarządza kopiami zapasowymi. Obecnie nie ma możliwości ręcznego uruchamiania kopii zapasowych. Zalecamy użycie pg_dump zamiast tego.

  • Pierwsza migawka to pełna kopia zapasowa, a kolejne migawki to różnicowe kopie zapasowe. Różnicowe kopie zapasowe są kopiami zapasowymi tylko zmienionymi danymi od czasu utworzenia ostatniej kopii zapasowej migawki.

    Jeśli na przykład rozmiar bazy danych wynosi 40 GB, a a aprowizowany magazyn wynosi 64 GB, pierwsza kopia zapasowa migawki będzie wynosić 40 GB. Teraz, jeśli zmienisz 4 GB danych, następny różnicowy rozmiar kopii zapasowej migawki będzie wynosić tylko 4 GB. Dzienniki transakcji (dzienniki zapisu z wyprzedzeniem) są oddzielone od pełnych i różnicowych kopii zapasowych i są archiwizowane w sposób ciągły.

Przywracanie serwera

  • W przypadku korzystania z funkcji przywracania do punktu w czasie (PITR) nowy serwer jest tworzony z tymi samymi konfiguracjami obliczeniowymi i magazynowymi co serwer, na którym jest oparty.
  • Serwery baz danych w sieciach wirtualnych są przywracane do tych samych sieci wirtualnych podczas przywracania z kopii zapasowej.
  • Nowy serwer utworzony podczas przywracania nie ma reguł zapory, które istniały na oryginalnym serwerze. Należy utworzyć reguły zapory oddzielnie dla nowego serwera.
  • Przywracanie do innej subskrypcji nie jest obsługiwane. Aby obejść ten problem, możesz przywrócić serwer w ramach tej samej subskrypcji, a następnie przeprowadzić migrację przywróconego serwera do innej subskrypcji.

Powiązana zawartość