Skalowanie zasobów na serwerze elastycznym usługi Azure Database for PostgreSQL
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Serwer elastyczny usługi Azure Database for PostgreSQL obsługuje opcje skalowania w pionie i w poziomie.
Skalowanie w pionie: możesz skalować w pionie, dodając więcej zasobów do wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL, na przykład zwiększając liczbę procesorów i pamięci przypisanych do wystąpienia. 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 zmienić następujące elementy:
- Procesor CPU (rdzenie wirtualne).
- Ilość miejsca do magazynowania.
- Okres przechowywania kopii zapasowej.
Liczbę rdzeni wirtualnych można skalować w górę lub w dół, ale rozmiar magazynu można zwiększyć tylko. Okres przechowywania kopii zapasowych można również skalować w górę lub w dół z 7 do 35 dni. Zasoby można skalować przy użyciu wielu narzędzi, na przykład witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.
Uwaga
Po zwiększeniu rozmiaru magazynu nie można wrócić do mniejszego rozmiaru magazynu.
Skalowanie w poziomie: skalowanie w poziomie 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.
Po zmianie liczby rdzeni wirtualnych lub warstwy obliczeniowej wystąpienie zostanie ponownie uruchomione, aby nowy typ serwera został zastosowany. 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. Podobnie 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 nowej funkcji skalowania przestojów niemal zerowej 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 tworzymy nową kopię serwera (vm) ze zaktualizowaną konfiguracją. Synchronizujemy go z bieżącą kopią i przełączamy się na nową kopię z 30-sekundową przerwą. Następnie wycofamy stary serwer. Ten proces odbywa się bez dodatkowych kosztów.
Ten proces umożliwia bezproblemowe aktualizacje przy jednoczesnym zminimalizowaniu przestojów i zapewnieniu wydajności kosztowej. Ten proces skalowania jest wyzwalany po wprowadzeniu zmian w warstwach magazynowania i obliczeniowych. Ta funkcja jest dostępna tylko na serwerach innych niż ha i jest włączona we wszystkich regionach świadczenia usługi Azure. Do korzystania z tej możliwości nie jest wymagana żadna akcja klienta.
W przypadku serwerów skonfigurowanych do odczytu operacje skalowania muszą być zgodne z określoną sekwencją, aby zapewnić spójność danych i zminimalizować przestoje. Aby uzyskać szczegółowe informacje na temat tej sekwencji, zapoznaj się ze skalowaniem za pomocą replik do odczytu.
Uwaga
Proces skalowania przestojów zbliżony do zera jest operacją domyślną. 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. Ten okres nie jest bezpośrednio kontrolowany przez proces skalowania. 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, włącz wszystkie połączenia przychodzące/wychodzące między adresami IP w podsieci delegowanej podczas korzystania ze zintegrowanej sieci wirtualnej. Jeśli te połączenia nie są włączone, proces skalowania przestojów niemal zerowy nie działa i skalowanie odbywa się za pośrednictwem standardowego przepływu pracy skalowania.
- Skalowanie przestojów niemal zerowych nie działa, jeśli istnieją regionalne ograniczenia pojemności lub limity przydziału dla subskrypcji klientów.
- Skalowanie przestojów niemal zerowych nie działa dla serwera repliki, ponieważ jest obsługiwane tylko na serwerze podstawowym. W przypadku serwera repliki jest on automatycznie przechodzi przez zwykły proces skalowania.
- Skalowanie przestojów zbliżone do zera nie działa, jeśli serwer z podsiecią delegowana nie ma wystarczających adresów IP, których można używać. 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ć 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 na serwerze elastycznym.
- Skalowanie przestojów niemal zerowych nie działa z tabelami nieznakowanym. Klienci korzystający z nielogowanych tabel dla dowolnego z ich danych utracą wszystkie dane w tych tabelach po niemal zerowym skalowaniu przestojów.
- Skalowanie przestojów niemal zerowych nie jest obecnie obsługiwane dla serwerów z obsługą wysokiej dostępności.