Omezení na flexibilním serveru Azure Database for PostgreSQL

Následující části popisují limity kapacity a funkčnosti pro flexibilní servery Azure Database for PostgreSQL. Informace o úrovních prostředků pro výpočetní prostředky, paměť a úložiště najdete v článcích o výpočetních prostředcích a úložištích .

Maximální počet připojení

Následující tabulka uvádí výchozí maximální počet připojení pro každou cenovou úroveň a konfiguraci virtuálních jader. Flexibilní server Azure Database for PostgreSQL vyhrazuje 15 připojení pro fyzickou replikaci a monitorování Azure Database for PostgreSQL flexibilního serveru. Tabulka tedy zmenšuje hodnotu maximálního počtu připojení uživatelů o 15 z celkového maximálního počtu připojení.

Název produktu vCores Velikost paměti Maximální počet připojení Maximální počet uživatelských připojení
Dynamická kapacita
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1,718 1,703
B8ms 8 32 GB 3,437 3,422
B12ms 12 48 GiB 5 000 4,985
B16ms 16 64 GiB 5 000 4,985
B20ms 20 80 GiB 5 000 4,985
Obecné účely
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1,718 1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 GB 3,437 3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 GiB 5 000 4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GiB 5 000 4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5 000 4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GB 5 000 4,985
D96ds_v5 / D96ads_v5 96 384 GiB 5 000 4,985
Optimalizováno pro paměť
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 GB 3,437 3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 GiB 5 000 4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GiB 5 000 4,985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5 000 4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GB 5 000 4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5 000 4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5 000 4,985
E96ds_v5 / E96ads_v5 96 672 GiB 5 000 4,985

Aktuálně je rezervováno 15 slotů připojení, které se mohou změnit. Doporučujeme pravidelně ověřovat celková rezervovaná připojení na serveru. Toto číslo vypočítáte sečtením hodnot parametrů reserved_connections a superuser_reserved_connections. Maximální počet dostupných uživatelských připojení je max_connections – (reserved_connections + superuser_reserved_connections).

Systém vypočítá výchozí hodnotu parametru max_connections při zřizování instance Azure Database for PostgreSQL flexibilního serveru na základě názvu produktu, který vyberete pro jeho výpočetní prostředky. Jakékoli následné změny výběru produktu na výpočetní prostředky, které podporují instanci, nebudou mít žádný vliv na výchozí hodnotu parametru max_connections dané instance. Doporučujeme, abyste pokaždé, když změníte produkt přiřazený k instanci, upravte hodnotu max_connections parametru také podle hodnot v předchozí tabulce.

Změna hodnoty max_connections

Když nastavíte flexibilní server Azure Database for PostgreSQL, automaticky určí nejvyšší počet souběžných připojení, která dokáže zpracovat. Konfigurace vašeho serveru určuje toto číslo a nemůžete ho změnit.

Nastavení ale můžete použít max_connections k úpravě počtu povolených připojení v určitém okamžiku. Po změně tohoto nastavení je potřeba restartovat server, aby nový limit začal fungovat.

Upozornění

I když je možné zvýšit hodnotu nad rámec výchozího max_connections nastavení, doporučujeme, abyste ji nepoužíli.

Instance můžou narazit na potíže, když se úloha rozšíří a vyžaduje více paměti. S rostoucím počtem připojení se také zvyšuje využití paměti. Instance s omezenou pamětí můžou čelit problémům, jako jsou chyby nebo vysoká latence. I když může být vyšší hodnota pro max_connections přijatelná, když je většina připojení nečinná, může vést ke značným problémům s výkonem poté, co se stanou aktivními.

Pokud potřebujete více připojení, doporučujeme místo toho použít PgBouncer, integrované řešení Azure pro správu fondu připojení. Použijte ho v režimu transakce. Pro začátek doporučujeme použít konzervativní hodnoty a vCores vynásobit koeficientem v rozmezí 2 až 5. Následně pečlivě monitorujte využití prostředků a výkon aplikace, abyste zajistili hladký provoz. Podrobné informace o nástroji PgBouncer najdete v tématu PgBouncer ve službě Azure Database for PostgreSQL.

Pokud připojení překročí limit, může se zobrazit následující chyba:

FATAL: sorry, too many clients already.

Při použití Azure Database for PostgreSQL flexibilního serveru pro zaneprázdněnou databázi s velkým počtem souběžných připojení může dojít k značnému zatížení prostředků. Tato zátěž může vést k vysokému využití procesoru, zejména v případě, že je navázáno mnoho připojení současně a když připojení mají krátkou dobu (méně než 60 sekund). Tyto faktory můžou negativně ovlivnit celkový výkon databáze zvýšením doby strávené zpracováním připojení a odpojení.

Každé připojení na Azure Database for PostgreSQL flexibilním serveru bez ohledu na to, jestli je nečinné nebo aktivní, spotřebovává z vaší databáze značné množství prostředků. Toto zatížení může vést k problémům s výkonem kromě vysokého využití procesoru, například ke konfliktům v přístupu k disku a k soutěžení o zámky. Článek Počet připojení k databázi na wikiwebu PostgreSQL podrobněji popisuje toto téma. Další informace najdete v tématu Identifikace a řešení výkonu připojení v Azure Postgres.

Funkční omezení

V následujících částech najdete důležité informace o tom, co je a co není podporované pro vaše flexibilní servery Azure Database for PostgreSQL.

Operace škálování

  • V tuto chvíli vyžaduje vertikální navýšení kapacity úložiště serveru restartování serveru.
  • Úložiště serveru je možné škálovat pouze v 2x přírůstcích. Podrobnosti naleznete v Úložišti.
  • Snížení velikosti úložiště serveru se nepodporuje. Chcete-li zmenšit velikost úložiště, musíte exportovat a obnovit data do nového flexibilního serveru Azure Database for PostgreSQL.

Storage

  • Jakmile nakonfigurujete velikost úložiště, nemůžete ji zmenšit. Musíte vytvořit nový server s požadovanou velikostí úložiště, provést ruční operaci výpisu a obnovení a migrovat databáze na nový server.
  • Když využití úložiště dosáhne 95% nebo pokud je dostupná kapacita menší než 5 GiB (podle toho, co je vyšší), systém automaticky přepne server do režimu jen pro čtení , aby se zabránilo chybám spojeným s plnými disky. Ve výjimečných případech může váš server přesto vyčerpat dostupné úložiště, pokud rychlost růstu dat převýší dobu potřebnou k přepnutí do režimu jen pro čtení. Automatickému zvětšování úložiště můžete povolit, abyste se těmto problémům vyhnuli, a automaticky škálovat úložiště na základě vašich požadavků na úlohy.
  • Doporučujeme nastavit pravidla upozornění pro storage used nebo storage percent, když překročí určité prahové hodnoty, abyste mohli proaktivně přijmout opatření, například navýšit kapacitu úložiště. Pokud například procento úložiště překročí 80 % využití, můžete nastavit upozornění.
  • Pokud používáte logickou replikaci, musíte v primárním serveru vynechat slot logické replikace, pokud už odpovídající odběratel neexistuje. Jinak se soubory protokolu se záznamem před zápisem (WAL) budou hromadit na primárním serveru a zaplní úložiště. Pokud úložiště překročí určitou prahovou hodnotu a slot logické replikace se nepoužívá (kvůli nedostupnému odběrateli), flexibilní server Azure Database for PostgreSQL tento nepoužívaný slot logické replikace automaticky odstraní. Tato akce uvolní kumulované soubory WAL a zabrání tomu, aby váš server nebyl dostupný, protože je vyplněné úložiště.
  • Vytváření tabulkových prostorů není podporováno. Pokud vytváříte databázi, nezadávejte název tabulkového prostoru. Flexibilní server Azure Database for PostgreSQL používá výchozí tabulkový prostor, který databáze šablony dědí. Není bezpečné poskytnout tablespace, například dočasný tablespace, protože služba nemůže zajistit, aby takové objekty zůstaly zachovány po událostech, jako je restart serveru a přepnutí při selhání v režimu vysoké dostupnosti (HA).
  • Osiřelé datové soubory a nesrovnalosti ve využití disku: Ve výjimečných případech může PostgreSQL zanechat na disku osiřelé datové soubory. Tyto soubory již nemají odpovídající položky v systémovém katalogu databáze (které sledují všechny tabulky a data). K této podmínce může dojít v případě, že se v rámci transakce vytvoří a naplní tabulka, která se úspěšně nedokončí (například kvůli chybovému ukončení nebo přerušení serveru), což vede k neshodě mezi velikostí hlášenou databází a skutečným využitím disku. Toto chování pochází z komunitního základu PostgreSQL a není specifické pro Azure. Komunita PostgreSQL o problému ví a zkoumá vylepšení automatického čištění v budoucích verzích. Další informace najdete v tématu: PostgreSQL: Osamocené soubory v PostgreSQL. Tento stav může vést k neočekávanému vysokému využití disku nebo úložiště.
    • Zjištění: Porovnání velikosti hlášené databáze (pomocí dotazů, jako je SELECT pg_database_size('your_database')) s metrikami webu Azure Portal pro skutečné využití disku Pokud dojde k významné nesrovnalosti, sirotčí soubory můžou být příčinou. Pokud ano:
      • Spusťte VACUUM FULL na ovlivněných tabulkách, abyste uvolnili místo (poznámka: je to náročné na prostředky, vyžaduje zámek tabulky a může vyžadovat plánovanou odstávku).
      • Alternativně můžete použít nástroje, jako jsou rozšíření pg_repack nebo pg_squeeze pro reorganizaci bez výpadků, ale nejprve otestujte v neprodukčním prostředí.
      • Monitorování prostřednictvím metrik webu Azure Portal pro prahové hodnoty využití disků Pokud problém přetrvává nebo si nejste jistí, požádejte o pomoc podporu Azure.
    • Jak zabránit: Zajistěte, aby se transakce ve vašich aplikacích správně spravily, aby se minimalizovaly neúplné operace. Pravidelně monitorujte využití disků prostřednictvím metrik webu Azure Portal. Upgrade na nejnovější podporovanou verzi PostgreSQL může zahrnovat komunitní opravy souvisejících problémů.

Sítě

  • V současné době nepodporujeme přesun do a z virtuální sítě.
  • V současné době nepodporujeme kombinování veřejného přístupu s nasazením ve virtuální síti.
  • Virtuální sítě nepodporují pravidla brány firewall. Místo toho můžete použít skupiny zabezpečení sítě.
  • Databázové servery s veřejným přístupem se mohou připojit k veřejnému internetu; například prostřednictvím postgres_fdw. Tento přístup nemůžete omezit. Servery ve virtuálních sítích můžou mít omezený odchozí přístup prostřednictvím skupin zabezpečení sítě.

Vysoká dostupnost

Zóny dostupnosti

  • Momentálně nepodporujeme ruční přesun serverů do jiné zóny dostupnosti. Pokud ale jako pohotovostní zónu použijete upřednostňovanou zónu dostupnosti, můžete zapnout vysokou dostupnost. Jakmile nastavíte záložní zónu, můžete na ni přepnout při selhání a poté vypnout HA.

Modul Postgres, rozšíření a PgBouncer

  • Flexibilní server Azure Database for PostgreSQL podporuje všechny funkce modulu PostgreSQL, včetně dělení, logické replikace a obálky cizích dat.
  • Flexibilní server Azure Database for PostgreSQL podporuje všechna contrib rozšíření a další možnosti. Další informace najdete v tématu Rozšíření PostgreSQL.
  • Servery s možností rozšíření v současné době nemají přístup k integrovanému nástroji pro sdružování připojení PgBouncer.

Operace zastavení/spuštění

  • Po zastavení flexibilního serveru Azure Database for PostgreSQL se automaticky spustí po sedmi dnech.

Plánovaná údržba

  • Vlastní časové období údržby můžete změnit na libovolný den/čas v týdnu. Jakékoli změny, které provedete po přijetí oznámení o údržbě, ale nebudou mít žádný vliv na další údržbu. Změny se projeví pouze během nejbližší plánované měsíční údržby.

Zálohy serveru

  • Systém spravuje zálohy. V současné době nemůžete zálohování spouštět ručně. Místo toho doporučujeme používat pg_dump.

  • První snímek je úplná záloha a po sobě jdoucí snímky jsou rozdílové zálohy. Rozdílové zálohy zálohují pouze změněná data od posledního zálohování snímků.

    Pokud je například velikost databáze 40 GB a zřízené úložiště je 64 GB, první zálohování snímků je 40 GB. Pokud teď změníte 4 GB dat, velikost dalšího rozdílového zálohování snímků bude jenom 4 GB. Transakční protokoly (protokoly před zápisem) jsou oddělené od úplných a rozdílových záloh a archivují se nepřetržitě.

Obnovení serveru

  • Když používáte funkci obnovení k určitému bodu v čase (PITR), systém vytvoří nový server se stejnými konfiguracemi výpočetních prostředků a úložiště jako server, na kterém je založen.
  • Systém při obnovení ze zálohy obnoví databázové servery ve virtuálních sítích do stejných virtuálních sítí.
  • Nový server vytvořený během obnovení nemá pravidla brány firewall, která existovala na původním serveru. Pro nový server potřebujete vytvořit pravidla brány firewall samostatně.
  • Obnovení do jiného předplatného nepodporujeme. Jako alternativní řešení můžete obnovit server ve stejném předplatném a potom migrovat obnovený server do jiného předplatného.

Zabezpečení

  • PostgreSQL verze 14 a novější automaticky zakazují používání MD5 hashů a pro nativní Postgres hesla používají k hashování pouze metodu SCRAM-SHA-256.

Související obsah

  • Last updated on