Sdílet prostřednictvím

Omezení ve službě Azure Database for PostgreSQL

Následující části popisují limity kapacity a funkčnosti pro instance flexibilních serverů Azure Database for PostgreSQL. Pokud se chcete dozvědět o úrovních prostředků (výpočetních prostředků, paměti, úložiště), přečtěte si články 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í instance serveru Azure Database for PostgreSQL si vyhrazuje 15 připojení pro fyzickou replikaci a monitorování instance flexibilního serveru Azure Database for PostgreSQL. V důsledku toho tabulka zmenšuje hodnotu maximálního počtu uživatelských připojení o 15 z celkového maximálního počtu připojení.

Název produktu virtuálních jader Velikost paměti Maximální počet připojení Maximální počet uživatelských připojení
Nárazové rozšíření
B1ms 0 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é použití
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 součtem hodnot reserved_connections parametrů serveru a superuser_reserved_connections serveru. 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 serveru při zřizování instance flexibilního serveru Azure Database for PostgreSQL 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 serveru 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

Při prvním nastavení instance flexibilního serveru Azure Database for Postgres se automaticky rozhodne nejvyšší počet připojení, která dokáže zpracovat současně. 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 přijatelné, max_connections když je většina připojení nečinná, může vést k významným problémům s výkonem po jejich aktivní činnosti.

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 vynásobením virtuálních jader v rozsahu 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.

Pokud používáte instanci flexibilního serveru Azure Database for PostgreSQL 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í v instanci flexibilního serveru Azure Database for PostgreSQL bez ohledu na to, jestli je nečinné nebo aktivní, spotřebovává z vaší databáze značné množství prostředků. Tato spotřeba může vést k problémům s výkonem nad rámec vysokého využití procesoru, jako jsou kolize disků a zámků. Článek Počet připojení k databázi na wikiwebu PostgreSQL podrobněji popisuje tento článek. 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 není podporované pro instance flexibilních serverů 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.
  • V současné době nepodporujeme zmenšení velikosti úložiště serveru. Jediným způsobem, jak tuto operaci provést, je výpis a obnovení do nové instance 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 dojít k výpadku rychlosti růstu dat v době, která trvá přepnutí do režimu jen pro čtení, může dojít k výpadku úložiště vašeho serveru. 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 překročení určitých prahových hodnot nebo storage percent když překročí určité prahové hodnoty, abyste mohli aktivně provádět akce, jako je zvýšení velikosti ú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 protokolování pro zápis (WAL) hromadí v primárním objektu a zaplní úložiště. Pokud úložiště překročí určitou prahovou hodnotu a pokud se slot logické replikace nepoužívá (kvůli nedostupnosti odběratele), instance flexibilního serveru Azure Database for PostgreSQL automaticky klesne tento nepoužívaný slot logické replikace. Tato akce uvolní kumulované soubory WAL a zabrání tomu, aby váš server nebyl dostupný, protože je vyplněné úložiště.
  • Nepodporujeme vytváření tabulkových prostorů. Pokud vytváříte databázi, nezadávejte název tabulkového prostoru. Instance flexibilního serveru Azure Database for PostgreSQL používá výchozí tabulkový prostor, který databáze šablony dědí. Je nebezpečné poskytnout tabulkový prostor, jako je dočasný prostor, protože nemůžeme zajistit, aby tyto objekty zůstaly trvalé po událostech, jako jsou restartování serveru a převzetí služeb při selhání vysoké dostupnosti (HA).
  • Nesrovnalosti v osamocených datových souborech a využití disků: Ve výjimečných případech může PostgreSQL zanechat osamocené datové soubory na disku – soubory, které už nemají odpovídající položky v systémovém katalogu databáze (které sledují všechny tabulky a data). K tomu může dojít v případě, že se v rámci transakce vytvoří a naplní tabulka, která se úspěšně nedokončí (např. 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ší podrobnosti najdete v tématu: PostgreSQL: Osamocené soubory v PostgreSQL. To 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 v ovlivněných tabulkách vakuum full a uvolněte místo (poznámka: to je náročné na prostředky, vyžaduje zámek tabulky a může vyžadovat výpadek).
      • Alternativně můžete použít nástroje, jako je pg_repack nebo pg_squeeze rozšíření k 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 vytvoříte pohotovostní zónu, můžete převzít služby při selhání a pak vypnout vysokou dostupnost.

Modul Postgres, rozšíření a PgBouncer

  • Flexibilní serverová instance Azure Database for PostgreSQL podporuje všechny funkce modulu PostgreSQL, včetně dělení, logické replikace a obálky cizích dat.
  • Flexibilní instance serveru 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í instance 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í jenom s následující měsíční plánovanou údržbou.

Zálohy serveru

  • Systém spravuje zálohy. V současné době nemůžete zálohování spouštět ručně. Doporučujeme místo toho použít 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í

  • Postgres 14 a novější verze zakazují hashování MD5 a systém hashuje nativní hesla Postgresu pouze pomocí metody SCRAM-SHA-256.

Související obsah

  • Last updated on