Sdílet prostřednictvím

Limity na flexibilním serveru Azure Database for PostgreSQL.

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Následující části popisují limity kapacity a funkčnosti flexibilního serveru 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í server 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 je hodnota maximálního počtu uživatelských připojení uvedených v tabulce snížena 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

Rezervované sloty připojení, které jsou momentálně ve 15, se můžou 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_connectionssuperuser_reserved_connections).

Výchozí hodnota parametru max_connections serveru se vypočítá 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í flexibilní server, 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ě. Toto číslo vychází z konfigurace vašeho serveru a nedá se 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 na flexibilním serveru 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žívání 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í.

Mějte na paměti, že každé připojení na flexibilním 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 toto téma. Další informace najdete v tématu Identifikace a řešení výkonu připojení na flexibilním serveru Azure Database for PostgreSQL.

Funkční omezení

V následujících částech najdete důležité informace o tom, co je a co není podporované na flexibilním serveru 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 po 2x přírůstcích. Podrobnosti najdete v tématu Úložiště .
  • Zmenšení velikosti úložiště serveru se v současné době nepodporuje. Jediným způsobem, jak to udělat, je výpis a obnovení do nové instance flexibilního serveru Azure Database for PostgreSQL.

Úložiště

  • 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šší), server se automaticky přepne 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 nepoužívá slot logické replikace (kvůli nedostupnosti odběratele), flexibilní server Azure Database for PostgreSQL automaticky tento nepoužívaný slot logické replikace automaticky zahodí. 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. Flexibilní server Azure Database for PostgreSQL používá výchozí server, který je zděděný z databáze šablony. 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).

Sítě

  • Přechod do virtuální sítě a z virtuální sítě se v současné době nepodporuje.
  • Kombinace veřejného přístupu s nasazením ve virtuální síti se v současné době nepodporuje.
  • Pravidla brány firewall nejsou ve virtuálních sítích podporovaná. 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

  • Ruční přesun serverů do jiné zóny dostupnosti se v současné době nepodporuje. 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

  • Postgres 10 a starší verze se nepodporují, protože opensourcová komunita je vyřadila z důchodu. Pokud musíte použít jednu z těchto verzí, musíte použít možnost jednoúčelového serveru Azure Database for PostgreSQL, která podporuje starší hlavní verze 9.5, 9.6 a 10.
  • Flexibilní server Azure Database for PostgreSQL podporuje všechna contrib rozšíření a další. Další informace najdete v tématu Rozšíření PostgreSQL.
  • Integrovaný nástroj pro sdružování připojení PgBouncer není aktuálně k dispozici pro servery s možností burstable.

Operace zastavení/spuštění

  • Po zastavení instance flexibilního serveru Azure Database for PostgreSQL se automaticky spustí po 7 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ě neexistuje způsob, jak spustit zálohy 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, bude první zálohování snímků 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), vytvoří se nový server se stejnými konfiguracemi výpočetních prostředků a úložiště jako server, na kterém je založen.
  • Databázové servery ve virtuálních sítích se při obnovení ze zálohy obnoví 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 se nepodporuje. 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í

  • Hashování MD5 je zakázáno z Postgres 14 a novějších verzí a nativní hesla Postgres budou hashována pouze pomocí metody SCRAM-SHA-256.

Související obsah