Ograniczenia w usłudze Azure Database for PostgreSQL — serwer elastyczny
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_connections
superuser_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
lubstorage 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ść
- Zobacz Wysoka dostępność (niezawodność) w usłudze Azure Database for PostgreSQL — serwer elastyczny.
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.
Zabezpieczenia
- Skróty MD5 są wyłączone z programu Postgres 14 i nowszych wersji, a natywne hasła Postgres zostaną skróty tylko przy użyciu metody SCRAM-SHA-256.
Powiązana zawartość
- Informacje o dostępnych opcjach obliczeniowych
- Informacje o dostępnych opcjach magazynu
- Dowiedz się więcej o obsługiwanych wersjach bazy danych PostgreSQL
- Dowiedz się, jak utworzyć kopię zapasową serwera i przywrócić go na serwerze elastycznym usługi Azure Database for PostgreSQL przy użyciu witryny Azure Portal