Skalowanie zasobów na serwerze elastycznym usługi Azure Database for PostgreSQL

Serwer elastyczny Azure Database for PostgreSQL obsługuje opcje skalowania w pionie i w poziomie.

Skalowanie w pionie

Skaluj serwer w pionie, dodając więcej zasobów do serwera elastycznego Azure Database for PostgreSQL. Możesz zwiększyć lub zmniejszyć liczbę przypisanych mu procesorów CPU oraz ilość pamięci.

Przepływność sieci serwera zależy od wartości wybieranych dla procesora CPU i pamięci.

Po utworzeniu serwera elastycznego Azure Database for PostgreSQL można niezależnie skalować:

• Warstwa obliczeniowa i jednostka SKU.
• Warstwa magazynowania i rozmiar.
• Okres przechowywania kopii zapasowej.

Skaluj warstwę mocy obliczeniowej w górę lub w dół, wybierając między Burstable, General Purpose i Memory Optimized, aby dostosować ją do wymagań obciążenia. W każdej z tych warstw wybierz szeroki wybór wstępnie skonfigurowanego sprzętu różnych generacji o różnej liczbie procesorów CPU i ilości zainstalowanej pamięci. Wybierz opcję, która obsługuje wymagania dotyczące zasobów przy jednoczesnym zmniejszeniu kosztów operacyjnych i dostosowaniu ich do Twoich potrzeb.

Skaluj liczbę rdzeni wirtualnych i zainstalowaną pamięć w górę lub w dół. Możesz również skonfigurować warstwę magazynowania w górę lub w dół, aby uwzględnić wymagania dotyczące przepływności i liczby operacji we/wy na sekundę, których wymaga obciążenie. Można zwiększyć tylko rozmiar magazynu. W zależności od wymagań można zwiększyć lub zmniejszyć okres przechowywania kopii zapasowych z zakresu od 7 do 35 dni.

Skaluj te zasoby przy użyciu wielu interfejsów. Można na przykład użyć portalu Azure lub Azure CLI.

Skalowanie w poziomie

Azure Database for PostgreSQL klastry elastyczne umożliwiają skalowanie bazy danych w poziomie w celu obsługi obciążeń danych wykraczających poza możliwości pojedynczego serwera bazy danych. Klastry elastyczne zapewniają również możliwość jednoczesnego wykonywania operacji równoległych we wszystkich węzłach w klastrze, co znacznie zwiększa przepływność i odblokowuje bardzo małe opóźnienia. Klastry elastyczne oferują dwa modele fragmentowania tabel: fragmentowanie oparte na wierszach i dzielenie na fragmenty oparte na schemacie.

Skalowanie replik odczytu

Serwer można skalować w poziomie, tworząc repliki do odczytu. Repliki do odczytu umożliwiają skalowanie obciążeń związanych z odczytem na oddzielne serwery elastyczne usługi Azure Database for PostgreSQL. Nie wpływają one na wydajność i dostępność serwera podstawowego.

W konfiguracji skalowanej horyzontalnie można również skalować serwer główny i repliki do odczytu wertykalnie.

Po zmianie liczby rdzeni wirtualnych lub warstwy obliczeniowej serwer zostanie uruchomiony ponownie, aby nowy przypisany sprzęt zaczął uruchamiać obciążenie serwera. W tym czasie system przełącza się na nowy typ serwera. Nie można ustanowić nowych połączeń, a wszystkie niezatwierdzone transakcje zostaną wycofane.

Całkowity czas potrzebny na ponowne uruchomienie serwera zależy od procesu odzyskiwania awaryjnego i działania bazy danych w momencie ponownego uruchomienia. Ponowne uruchomienie trwa zwykle minutę lub mniej, ale może to być kilka minut. Czas trwania zależy od aktywności transakcyjnej w momencie zainicjowania ponownego uruchomienia.

Jeśli aplikacja jest wrażliwa na utratę transakcji w locie, które mogą wystąpić podczas skalowania obliczeń, zaimplementuj wzorzec ponawiania transakcji.

Skalowanie magazynu nie wymaga w większości przypadków ponownego uruchomienia serwera. Aby uzyskać więcej informacji, zapoznaj się z opcje pamięci masowej w bazie danych Azure dla PostgreSQL.

Zmiany okresu przechowywania kopii zapasowych to operacja online.

Aby poprawić czas ponownego uruchomienia, wykonaj operacje skalowania poza godzinami szczytu. Takie podejście skraca czas potrzebny do ponownego uruchomienia serwera bazy danych.

Skalowanie przy niemal zerowych przestojach

Skalowanie przestojów niemal zerowych to funkcja zaprojektowana w celu zminimalizowania przestojów podczas modyfikowania warstw magazynowania i zasobów obliczeniowych. Jeśli zmodyfikujesz liczbę rdzeni wirtualnych lub zmienisz warstwę obliczeniową, serwer zostanie uruchomiony ponownie, aby zastosować nową konfigurację. Podczas tego przejścia na nowy serwer nie można nawiązać nowych połączeń.

Zazwyczaj ten proces trwa od 2 do 10 minut przy regularnym skalowaniu. Korzystając z funkcji skalowania przestojów niemal zerowych, można skrócić ten czas trwania do mniej niż 30 sekund. Ta redukcja przestojów podczas skalowania zasobów zwiększa ogólną dostępność instancji bazy danych.

Jak to działa

Podczas aktualizowania Azure Database for PostgreSQL serwera elastycznego w scenariuszach skalowania usługa tworzy nową maszynę wirtualną dla serwera ze zaktualizowaną konfiguracją. Następnie synchronizuje się z maszyną wirtualną, która jest obecnie uruchomiona na serwerze, a następnie przełącza się na nową maszynę wirtualną z krótką przerwą. Proces w tle eliminuje starą maszynę wirtualną.

Ten proces umożliwia bezproblemowe aktualizacje z minimalnym przestojem i jest automatycznie wyzwalany podczas zmiany warstw magazynowania lub zasobów obliczeniowych. Nie musisz podejmować żadnych działań w celu korzystania z tej funkcji. Ta funkcja jest obsługiwana zarówno w przypadku serwera elastycznego Azure Database for PostgreSQL z konfiguracją wysokiej dostępności, jak i bez niej.

W przypadku konfiguracji skalowanych w poziomie, składających się z serwera podstawowego i co najmniej jednej repliki do odczytu, operacje skalowania muszą być wykonywane zgodnie z określoną sekwencją, aby zapewnić spójność danych i zminimalizować przestoje. Aby uzyskać szczegółowe informacje na temat tej sekwencji, zobacz skalowanie z użyciem replik do odczytu.

Dokładne oczekiwania dotyczące przestojów

• Czas trwania przestoju: w większości przypadków czas przestoju waha się od 10 do 30 sekund.
• Inne kwestie: po skalowaniu występuje nieodłączny okres ważności DNS Time-To-Live (TTL) wynoszący około 30 sekund. Proces skalowania nie kontroluje tego okresu bezpośrednio. Jest to standardowa część zachowania DNS. Z perspektywy aplikacji całkowity przestój podczas skalowania może wynosić od 40 do 60 sekund.

Uwagi i ograniczenia

• Aby skalowanie przy niemal zerowym czasie przestoju działało, zezwól na wszystkie połączenia przychodzące i wychodzące między adresami IP w delegowanej podsieci podczas korzystania z integracji z siecią wirtualną. Jeśli nie zezwolisz na te połączenia, proces skalowania z niemal zerowym przestojem nie zadziała i skalowanie odbędzie się poprzez standardowy przepływ pracy skalowania.
• Skalowanie przestojów niemal zerowych nie działa, jeśli istnieją ograniczenia pojemności regionalnej lub limity przydziału w ramach subskrypcji.
• Skalowanie przestojów niemal zerowych nie działa dla serwera repliki, ponieważ jest obsługiwane tylko na serwerze podstawowym. W przypadku serwerów replik operacja skalowania odbywa się automatycznie przez zwykły proces.
• Skalowanie z niemal zerowym czasem przestoju nie działa, jeśli serwer z iniekcją do sieci wirtualnej nie ma wystarczającej liczby użytecznych adresów IP w delegowanej podsieci. Jeśli masz serwer autonomiczny, wymagany jest jeden dodatkowy adres IP. W przypadku serwera z włączoną wysoką dostępnością wymagane są dwa dodatkowe adresy IP.
• Miejsca replikacji logicznej nie są zachowywane podczas niemal zerowego przestoju w trybie failover. Aby zachować sloty replikacji logicznej i zapewnić spójność danych po operacji skalowania, użyj rozszerzenia pg_failover_slot. Aby uzyskać więcej informacji, zobacz włączanie rozszerzenia pg_failover_slots w wystąpieniu elastycznego serwera.
• Skalowanie z niemal zerowym przestojem nie działa z tabelami niezapisywanymi w dzienniku. Jeśli używasz nielogowanych tabel dla dowolnego zbioru danych, utracisz wszystkie dane w tych tabelach po skalowaniu z niemal zerowym czasem przestoju.
• Skalowanie do mechanizmu niemal zerowego przestaje działać, jeśli serwer zmienia rozmiar obliczeniowy na 1 lub 2 vCores w warstwie burstable.

Treści powiązane

• Zarządzanie usługą Azure Database for PostgreSQL