Škálování prostředků ve službě Azure Database for PostgreSQL

Flexibilní instance serveru Azure Database for PostgreSQL podporuje možnosti vertikálního i horizontálního škálování.

Vertikální škálování

Instanci můžete škálovat vertikálně přidáním dalších prostředků do instance flexibilního serveru Azure Database for PostgreSQL. Můžete zvýšit nebo snížit počet procesorů a paměti přiřazených k němu.

Propustnost sítě vaší instance závisí na hodnotách, které zvolíte pro procesor a paměť.

Po vytvoření instance flexibilního serveru Azure Database for PostgreSQL můžete nezávisle škálovat:

• Úroveň výpočetních prostředků a skladová položka
• Úroveň a velikost úložiště.
• Doba uchovávání záloh.

Úroveň výpočetního výkonu můžete škálovat nahoru nebo dolů mezi režimy Burst, Obecný účel a Optimalizace paměti a přizpůsobit tak potřebám vaší pracovní zátěže. V každé z těchto úrovní si můžete vybrat z širokého výběru předkonfigurovaného hardwaru různých generací s různou čísly procesorů a objemy nainstalované paměti. Můžete vybrat možnost, která podporuje vaše požadavky na prostředky a zároveň snížit provozní náklady a upravit je podle vašich potřeb.

Můžete škálovat počet virtuálních jader a nainstalovanou paměť nahoru nebo dolů. Můžete také nakonfigurovat úroveň úložiště nahoru nebo dolů tak, aby vyhovovala požadavkům na propustnost a vstupně-výstupní operace za sekundu, které vaše úlohy vyžadují. Velikost úložiště můžete zvětšit. V závislosti na vašich požadavcích můžete prodloužit nebo snížit dobu uchovávání záloh mezi 7 až 35 dny.

Tyto prostředky můžete škálovat pomocí více rozhraní. Můžete například použít Azure Portal nebo Azure CLI.

Poznámka:

Po zvětšení velikosti úložiště přiřazeného k vaší instanci ji nemůžete zmenšit na menší velikost.

Horizontální škálování

Elastické clustery Azure Database for PostgreSQL umožňují horizontálně škálovat databázi tak, aby podporovala datové úlohy, které překračují možnosti jedné instance databáze. Elastické clustery také umožňují souběžné spouštění paralelních operací napříč všemi uzly v clusteru, což výrazně zvyšuje propustnost a odemykání ultra-nízké latence. Elastické clustery nabízejí dva modely horizontálního dělení tabulek: horizontální dělení na základě řádků a horizontální dělení založené na schématu.

Škálování repliky pro čtení

Dalším způsobem horizontálního škálování instance je vytvoření replik pro čtení. Repliky pro čtení umožňují škálovat úlohy čtení na samostatné instance flexibilního serveru Azure Database for PostgreSQL. Nemají vliv na výkon a dostupnost primární instance.

V horizontálně škálovaném nastavení můžete také vertikálně škálovat primární instanci a repliky pro čtení.

Když změníte počet virtuálních jader nebo výpočetní úroveň, instance se restartuje, aby nový přiřazený hardware začal spouštět serverovou úlohu. Během této doby se systém přepne na nový typ serveru. Nelze navázat žádná nová připojení a všechny nepotvrzené transakce se vrátí zpět.

Celkový čas potřebný k restartování serveru závisí na procesu zotavení po havárii a aktivitě databáze v době restartování. Restartování obvykle trvá minutu nebo méně, ale může to být několik minut. Časování závisí na transakční aktivitě při zahájení restartování.

Pokud je vaše aplikace citlivá na ztrátu transakcí v testovacích verzích, ke kterým může dojít během škálování výpočetních prostředků, implementujte model opakování transakce.

Škálování úložiště ve většině případů nevyžaduje restartování serveru. Další informace najdete v tématu Možnosti úložiště ve službě Azure Database for PostgreSQL.

Změny doby uchovávání záloh jsou online operace.

Pokud chcete zkrátit dobu restartování, proveďte operace škálování mimo špičku. Tento přístup zkracuje dobu potřebnou k restartování databázového serveru.

Škálování s téměř nulovými výpadky

Škálování téměř nulového výpadku je funkce navržená tak, aby minimalizovala výpadky při úpravě úrovní úložiště a výpočetních prostředků. Pokud upravíte počet virtuálních jader nebo změníte výpočetní úroveň, server se restartuje, aby použil novou konfiguraci. Během tohoto přechodu na nový server není možné navázat žádná nová připojení.

Tento proces obvykle může trvat 2 až 10 minut s pravidelným škálováním. Díky funkci škálování téměř nulového výpadku se tato doba trvání zmenší na méně než 30 sekund. Toto snížení výpadku během škálování prostředků zlepšuje celkovou dostupnost vaší instance databáze.

Jak to funguje

Když aktualizujete instanci flexibilního serveru Azure Database for PostgreSQL ve scénářích škálování, služba pro váš server vytvoří nový virtuální počítač s aktualizovanou konfigurací. Potom se synchronizuje s virtuálním počítačem, na kterém právě běží vaše instance, a pak se přepne na nový virtuální počítač s krátkou přerušením. Proces na pozadí pak eliminuje starý virtuální počítač.

Tento proces umožňuje bezproblémové aktualizace s minimálními výpadky a automaticky se aktivuje při změně úrovně úložiště nebo výpočetních prostředků. Abyste mohli tuto funkci používat, nemusíte provádět žádnou akci. Tato funkce je podporována pro instance flexibilních serverů Azure Database for PostgreSQL s vysokou dostupností i bez ní.

U horizontálně škálovaných konfigurací, které se skládají z primárního serveru a jedné nebo více replik pro čtení, musí operace škálování dodržovat konkrétní sekvenci, aby se zajistila konzistence dat a minimalizovala prostoje. Podrobnosti o této sekvenci najdete v tématu Škálování pomocí replik pro čtení.

Poznámka:

Škálování téměř nulového výpadku je výchozím typem operace. Když dojde k následujícím omezením , systém se přepne na běžné škálování, což v porovnání se škálováním téměř nulového výpadku zahrnuje více výpadků.

Přesná očekávání výpadků

• Doba trvání výpadku: Ve většině případů se výpadek pohybuje od 10 do 30 sekund.
• Další aspekty: Po události škálování existuje období TTL (Inherent DNS Time-To-Live ) přibližně 30 sekund. Proces škálování neřídí toto období přímo. Jedná se o standardní součást chování DNS. Z hlediska aplikace může být celkový výpadek během škálování v rozsahu 40 až 60 sekund.

Úvahy a omezení

• Aby škálování téměř nulového výpadku fungovalo, povolte při použití integrovaných sítí virtuální sítě všechna příchozí a odchozí připojení mezi IP adresami v delegované podsíti. Pokud tato připojení nepovolíte, proces škálování s téměř žádným výpadkem nefunguje a škálování probíhá prostřednictvím standardního postupu škálování.
• Škálování téměř nulového výpadku nefunguje, pokud ve vašem předplatném existují omezení regionální kapacity nebo limity kvót.
• Škálování téměř nulového výpadku nefunguje u serveru repliky, protože je podporováno pouze na primárním serveru. U serverů repliky operace škálování automaticky prochází pravidelným procesem.
• Škálování téměř nulového výpadku nefunguje, pokud server vložený do virtuální sítě nemá v delegované podsíti dostatek použitelných IP adres. Pokud máte samostatný server, je potřeba jedna další IP adresa. Pro instanci s povolenou vysokou dostupností jsou vyžadovány dvě další IP adresy.
• Sloty logické replikace se během události převzetí služeb při selhání téměř nulového výpadku nezachovají. Pokud chcete udržovat sloty logické replikace a zajistit konzistenci dat po operaci škálování, použijte rozšíření pg_failover_slot . Další informace najdete v tématu povolení rozšíření pg_failover_slots v instanci flexibilního serveru.
• Škálování téměř nulového výpadku nefunguje s nepřipojenými tabulkami. Pokud pro některá data používáte neprotokolované tabulky, ztratíte všechna data v těchto tabulkách po škálování s téměř nulovým výpadkem.
• Téměř nula nefunguje, pokud škálujete výpočetní prostředky serveru nebo na výpočetní velikost 1 nebo 2 virtuální jádra vrstvy Burstable.

Související obsah

• Správa služby Azure Database for PostgreSQL