Limity na flexibilním serveru Azure Database for PostgreSQL.

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í.

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.

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

• Podívejte se na vysokou dostupnost (spolehlivost) na flexibilním serveru Azure Database for PostgreSQL.

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

• Vysvětlení dostupných možností výpočetních prostředků
• Vysvětlení toho, co je k dispozici pro možnosti úložiště
• Další informace o podporovaných verzích databáze PostgreSQL
• Přečtěte si , jak zálohovat a obnovit server na flexibilním serveru Azure Database for PostgreSQL pomocí webu Azure Portal.