Skalowanie zasobów w usłudze Azure Database for PostgreSQL

Instancja elastycznego serwera usługi Azure Database for PostgreSQL obsługuje opcje skalowania w pionie i w poziomie.

Skalowanie w pionie

Wystąpienie można skalować pionowo, dodając więcej zasobów do elastycznego serwera usługi Azure Database for PostgreSQL. Możesz zwiększyć lub zmniejszyć liczbę przypisanych procesorów CPU i pamięci.

Przepustowość sieci twojego wystąpienia zależy od wartości wybranych dla procesora i pamięci.

Po utworzeniu wystąpienia serwera elastycznego Azure Database for PostgreSQL, można niezależnie skalować zasoby.

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

Warstwę obliczeniową można zwiększać lub zmniejszać w zakresie między Burstable, Ogólnego Przeznaczenia i Pamięciowo Zoptymalizowane, aby dostosować się do potrzeb obciążenia. W każdej z tych warstw można wybrać szeroki wybór wstępnie skonfigurowanego sprzętu różnych generacji o różnej liczbie procesorów CPU i ilości zainstalowanej pamięci. Możesz wybrać opcję, która obsługuje Twoje wymagania dotyczące zasobów, jednocześnie zmniejszając koszty operacyjne i dostosowując je do Twoich potrzeb.

Liczbę rdzeni wirtualnych i zainstalowaną pamięć można skalować 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.

Te zasoby można skalować przy użyciu wielu interfejsów. Możesz na przykład użyć witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

Uwaga

Po zwiększeniu rozmiaru magazynu przypisanego do wystąpienia nie można zmniejszyć go do mniejszego rozmiaru.

Skalowanie w poziomie

Elastyczne klastry usługi Azure Database for PostgreSQL umożliwiają skalowanie bazy danych w poziomie w celu obsługi obciążeń danych wykraczających poza możliwości pojedynczego wystąpienia bazy danych. Klastry elastyczne umożliwiają również jednoczesne wykonywanie operacji równoległych we wszystkich węzłach w klastrze, znacznie zwiększając przepływność i odblokowując 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

Kolejnym podejściem do skalowania wystąpienia horyzontalnie jest utworzenie replik do odczytu. Repliki do odczytu umożliwiają skalowanie obciążeń odczytu na oddzielne wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Nie wpływają one na wydajność i dostępność wystąpienia podstawowego.

W konfiguracji z poziomym skalowaniem można również skalować pionowo zarówno wystąpienie podstawowe, jak i repliki do odczytu.

Po zmianie liczby rdzeni wirtualnych lub warstwy obliczeniowej wystąpienie zostanie uruchomione 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 zależy od działania transakcyjnego po zainicjowaniu 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 niemal zerowych przestojów

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 jest możliwe ustanowienie nowych połączeń.

Zazwyczaj ten proces może potrwać od 2 do 10 minut przy regularnym skalowaniu. Dzięki funkcji skalowania niemal zerowego przestoju ten czas trwania jest krótszy niż 30 sekund. Ta redukcja przestojów podczas skalowania zasobów zwiększa ogólną dostępność wystąpienia bazy danych.

Jak to działa

Podczas aktualizowania wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w scenariuszach skalowania usługa tworzy nową maszynę wirtualną dla serwera ze zaktualizowaną konfiguracją. Następnie synchronizuje się z maszyną wirtualną, na której obecnie działa Twoje wystąpienie, a potem przełącza się na nową maszynę wirtualną, co powoduje krótką przerwę. Następnie 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 serwerów elastycznych wysokiej dostępności (HA), jak i serwerów nie-HA usługi Azure Database for PostgreSQL.

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 za pomocą replik do odczytu.

Uwaga

Skalowanie przestojów niemal zerowych jest domyślnym typem operacji. Po napotkaniu poniższych ograniczeń system przełącza się na regularne skalowanie, co wiąże się z większym przestojem w porównaniu z skalowaniem niemal zerowym przestoju.

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 zagadnienia: po zdarzeniu skalowania istnieje nieodłączny okres DNS Time-To-Live (TTL) równy 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.

Rozważania i ograniczenia

• Aby skalowanie przestojów niemal zerowe działało, zezwalaj na wszystkie połączenia przychodzące i wychodzące między adresami IP w podsieci delegowanej podczas korzystania ze zintegrowanej sieci wirtualnej. 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 przestojów niemal zerowych nie działa, jeśli serwer z wstrzykniętą siecią wirtualną nie ma wystarczających adresów IP do użycia w delegowanej podsieci. Jeśli masz serwer autonomiczny, wymagany jest jeden dodatkowy adres IP. W przypadku wystąpienia 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ć miejsca 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 serwera elastycznego.
• Skalowanie przestojów niemal zerowych nie działa z tabelami nieznakowanym. 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.

Powiązana zawartość

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