Skalowanie zasobów w usłudze Azure Database for PostgreSQL — serwer elastyczny
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Usługa Azure Database for PostgreSQL — serwer elastyczny obsługuje zarówno opcje skalowania w pionie, jak i w poziomie.
Skalowanie w pionie
Wystąpienie można skalować w pionie, dodając więcej zasobów do wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Możesz zwiększyć lub zmniejszyć liczbę przypisanych procesorów CPU i pamięci.
Przepływność sieci wystąpienia zależy od wartości wybieranych dla procesora CPU i pamięci.
Po utworzeniu wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL można niezależnie skalować:
- Warstwa obliczeniowa i jednostka SKU.
- Warstwa magazynowania i rozmiar.
- Okres przechowywania kopii zapasowej.
Warstwę obliczeniową można skalować w górę lub w dół między funkcją Burstable, Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci, aby dostosować się do potrzeb obciążenia. W każdej z tych warstw istnieje szeroki wybór wstępnie skonfigurowanego sprzętu różnych generacji i z większą lub mniejszą ilością procesorów CPU i mniej lub bardziej zainstalowaną pamięcią. Spośród tych szerokich wyborów można wybrać ten, który obsługuje wymagania dotyczące zasobów w dowolnym momencie, przy jednoczesnym zmniejszeniu i dostosowaniu kosztów operacyjnych do Twoich potrzeb.
Liczbę rdzeni wirtualnych i zainstalowanej pamięci można skalować w górę lub w dół. Warstwę magazynowania można również skonfigurować w górę lub w dół, aby dostosować się do wymagań dotyczących przepływności i liczby operacji we/wy na sekundę, których wymaga obciążenie. Rozmiar magazynu można zwiększyć tylko. Ponadto 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
Wystąpienie można skalować w poziomie, tworząc repliki 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 skalowanej w poziomie wystąpienie podstawowe i repliki do odczytu można również skalować w pionie.
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ń, zalecamy zaimplementowanie wzorca ponawiania transakcji.
Skalowanie magazynu nie wymaga w większości przypadków ponownego uruchomienia serwera. Aby uzyskać więcej informacji, zobacz Opcje magazynu w usłudze Azure Database for PostgreSQL — serwer elastyczny.
Zmiany okresu przechowywania kopii zapasowych to operacja online.
Aby poprawić czas ponownego uruchomienia, zalecamy wykonywanie operacji 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 przejdzie ponowne uruchomienie, 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 jest synchronizowana z maszyną wirtualną, która aktualnie uruchamia wystąpienie, a następnie przełącza się na nową z krótką przerwą. Następnie proces w tle eliminuje starą maszynę wirtualną. Cały ten proces odbywa się bez dodatkowych kosztów.
Ten proces umożliwia bezproblemowe aktualizacje, jednocześnie minimalizując przestoje i zapewniając efektywność kosztową. Ten proces skalowania jest wyzwalany po wprowadzeniu zmian w warstwach magazynowania i obliczeniowych. Do korzystania z tej możliwości nie jest wymagana żadna akcja klienta.
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 te połączenia nie są dozwolone, proces skalowania przestojów niemal zerowy nie działa, a skalowanie odbywa się za pośrednictwem standardowego przepływu 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 z Twoich danych, wszystkie dane w tych tabelach zostaną utracone po skalowaniu przestojów niemal zerowych.