Skalowanie w poziomie za pomocą klastrów elastycznych na serwerze elastycznym Azure Database for PostgreSQL

Ten artykuł zawiera instrukcje krok po kroku dotyczące wykonywania operacji skalowania w poziomie dla klastra elastycznego serwera elastycznego Azure Database for PostgreSQL.

Elastyczne klastry usługi Azure Database for PostgreSQL zapewniają skalowanie w poziomie przez dodanie większej liczby węzłów roboczych do klastra. Podczas skalowania klastra elastycznego PostgreSQL można obsłużyć wzrost, udostępniając bazie danych więcej zasobów lub więcej węzłów na potrzeby przetwarzania zapytań równoległych. Wszystkie te korzyści można uzyskać z minimalnym przestojem i wbudowanym zarządzaniem fragmentami.

Metody skalowania w poziomie

Aby dodać węzły robocze do klastra Elastic, użyj jednej z kilku metod, na przykład witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub automatyzacji przy użyciu szablonów ARM i interfejsów API. Wybierz metodę najlepiej dopasowaną do potrzeb przepływu pracy i automatyzacji. Poniższe sekcje zawierają instrukcje krok po kroku dotyczące portalu i interfejsu wiersza polecenia oraz wyjaśniają równoważenie po skalowaniu.

az postgres flexible-server update `
  --resource-group <resource_group> `
  --name <cluster_name> `
  --node-count 4

Równoważenie

Po dodaniu węzłów do klastra nowe modyfikacje danych i nowo dodane tabele rozproszone używają wszystkich dostępnych węzłów. Istniejące fragmenty danych pozostają w ich oryginalnej lokalizacji, dopóki nie zostaną ponownie rozdystrybuowane. Ponowne równoważenie w trybie online gwarantuje, że odczyty i zapisy z aplikacji będą kontynuowane z minimalnymi przerwami podczas przenoszenia danych.

Podczas rozszerzania klastra elastycznego, równoważenie klastra gwarantuje, że istniejące dane są całkowicie rozproszone, a baza danych używa wszystkich dostępnych węzłów. Użyj funkcji citus_rebalance_start , aby uruchomić proces ponownego równoważenia. Ta operacja dystrybuuje istniejące dane równomiernie we wszystkich węzłach.

SELECT citus_rebalance_start();

Równoległe równoważenie

Domyślna operacja ponownego równoważenia wykonuje wiele ruchów fragmentów w kolejności sekwencyjnej. W niektórych przypadkach możesz preferować szybsze zrównoważenie, kosztem użycia większej ilości zasobów, takich jak obliczenia, pamięć i przepustowość sieci. W takich sytuacjach można skonfigurować operację ponownego równoważenia w celu równoległego wykonywania wielu ruchów fragmentów.

Parametr citus.max_background_task_executors_per_node umożliwia równoległe działanie zadań, takich jak ponowne równoważenie fragmentów. Możesz zwiększyć wartość domyślną (1) zgodnie z potrzebami, aby zwiększyć równoległość.

ALTER SYSTEM SET citus.max_background_task_executors_per_node = 2;
SELECT pg_reload_conf();

Ponadto można skonfigurować funkcję citus_rebalance_start w celu ponownego równoważenia fragmentów zgodnie z różnymi strategiami, aby najlepiej dopasować obciążenie bazy danych. Teraz, gdy dodano dodatkowych wykonawców zadań w tle, oto przykład ponownego równoważenia segmentów przy użyciu równoległych pracowników.

SELECT citus_rebalance_start(parallel_transfer_colocated_shards := true, parallel_transfer_reference_tables := true);

Rozważania

Monitoruj klaster po skalowaniu: sprawdź użycie procesora, zużycie pamięci i zużycie IO na wykresach monitoringu w portalu Azure dla klastra elastycznego. Po operacji skalowania w poziomie sprawdź, czy dodanie węzłów odzwierciedla poprawy parametrów dla przepływności i czasów reakcji, w zależności od obciążenia. Dalej dostosuj, jeśli to konieczne.

Skalowanie klastra elastycznego wpływa liniowo na koszty zasobów. Dodawanie węzłów mnoży koszty zasobów obliczeniowych i magazynu przez liczbę węzłów. Na przykład klaster z czterema węzłami, każdy z dwoma vCore'ami, kosztuje około cztery razy więcej niż pojedynczy serwer z dwoma vCore'ami, ponieważ działasz na czterech serwerach. Zawsze przejrzyj wpływ cen w portalu. Szacowany koszt jest aktualizowany na portalu Azure w momencie zmiany konfiguracji przed zapisaniem, aby upewnić się, że mieści się w Twoim budżecie.

Wysoka dostępność: jeśli klaster ma włączoną strefowo nadmiarową wysoką dostępność, operacje skalowania również zapewniają zasoby rezerwowe dla nowych węzłów. Usługa platformy Azure obsługuje to automatycznie. Oczekuj, że proces skalowania w poziomie zajmie nieco więcej czasu, ponieważ konfiguracja replik wysokiej dostępności dla każdego dodanego węzła wymaga dodatkowych ustawień. Charakterystyka procesu i przestoju pozostają prawie takie same, pomnożone dla par podstawowych i rezerwowych.

Repliki do odczytu: jeśli klaster jest skonfigurowany do używania replik do odczytu, należy wykonać określoną kolejność operacji podczas dodawania węzłów do klastra. Najpierw dodaj liczbę węzłów do klastra podstawowego i zapisz zmiany. Po pomyślnym zakończeniu wprowadź odpowiednią zmianę w środowisku repliki do odczytu i zapisz zmiany. Nowe węzły w klastrze podstawowym nie kwalifikują się do operacji klastra, dopóki nie zostaną zaktualizowane i zsynchronizowane środowiska repliki podstawowej i odczytu.

Korzystając z powyższych technik skalowania, elastyczne klastry usługi Azure Database for PostgreSQL zapewniają elastyczność zaczynania od małych rozmiarów i bezproblemowego skalowania bazy danych w miarę wzrostu zapotrzebowania. Otrzymujesz prostotę pojedynczego punktu końcowego w połączeniu z mocą rozproszonej infrastruktury PostgreSQL. Kontynuuj monitorowanie dokumentacji platformy Azure pod kątem najnowszych aktualizacji funkcji klastrów elastycznych i najlepszych rozwiązań dotyczących skalowania.

Treści powiązane

• Opcje obliczeniowe
• Limity w elastycznym serwerze usługi Azure Database for PostgreSQL
• Skalowanie przestojów niemal zerowe.