Az Azure-adatbázis a PostgreSQL számára korlátjai

Az alábbi szakaszok az Azure Database for PostgreSQL rugalmas kiszolgálópéldányainak kapacitási és működési korlátait ismertetik. Ha szeretne többet megtudni az erőforrás-(számítási, memória-, tárolási) szintekről, tekintse meg a számítási és tárolási cikkeket.

Kapcsolatok maximális száma

Az alábbi táblázat az egyes tarifacsomagokhoz és virtuálismag-konfigurációkhoz tartozó kapcsolatok alapértelmezett maximális számát mutatja. A rugalmas Azure Database for PostgreSQL-kiszolgálópéldányok 15 kapcsolatot foglalnak le a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány fizikai replikációja és monitorozása céljából. Következésképpen a tábla a maximális felhasználói kapcsolatok értékét 15-tal csökkenti a teljes maximális kapcsolatból.

Terméknév	Virtuális magok	Memória mérete	Kapcsolatok maximális száma	Felhasználói kapcsolatok maximális száma
Kipukkanható
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 GiB	3,437	3,422
B12ms	12	48 GiB	5000	4,985
B16ms	16	64 GiB	5000	4,985
B20ms	20	80 GiB	5000	4,985
Általános célú
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 GiB	3,437	3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5	16	64 GiB	5000	4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5	32	128 GiB	5000	4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5	48	192 GiB	5000	4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5	64	256 GiB	5000	4,985
D96ds_v5/ D96ads_v5	96	384 GiB	5000	4,985
Memóriaoptimalizált
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 GiB	3,437	3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5	8	64 GiB	5000	4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5	16	128 GiB	5000	4,985
E20ds_v4 / E20ds_v5 / E20ads_v5	20	160 GiB	5000	4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5	32	256 GiB	5000	4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5	48	384 GiB	5000	4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5	64	432 GiB	5000	4,985
E96ds_v5/ E96ads_v5	96	672 GiB	5000	4,985

A fenntartott csatlakozási pontok jelenleg 15-nél változhatnak. Javasoljuk, hogy rendszeresen ellenőrizze a teljes fenntartott kapcsolatot a kiszolgálón. Ezt a számot a kiszolgálói és reserved_connections a kiszolgálói paraméterek értékeinek superuser_reserved_connections összegzésével számítja ki. Az elérhető felhasználói kapcsolatok maximális száma : max_connections (reserved_connections + superuser_reserved_connections).

A rendszer a rugalmas Azure Database for PostgreSQL-kiszolgáló példányának kiépítésekor kiszámítja a max_connections kiszolgálóparaméter alapértelmezett értékét a számításhoz kiválasztott terméknév alapján. A példányt támogató számítás termékkijelölésének későbbi módosítása nem befolyásolja az adott példány kiszolgálóparaméterének alapértelmezett értékét max_connections . Javasoljuk, hogy amikor módosítja a példányhoz rendelt terméket, a paraméter értékét max_connections is módosítsa az előző táblázatban szereplő értékek szerint.

A max_connections értékének módosítása

Az Azure Database for Postgres rugalmas kiszolgálópéldányának első beállításakor automatikusan meghatározza az egyidejűleg kezelni kívánt kapcsolatok számát. A kiszolgáló konfigurációja határozza meg ezt a számot, és nem módosíthatja.

A beállítással max_connections azonban módosíthatja, hogy egy adott időpontban hány kapcsolat engedélyezett. A beállítás módosítása után újra kell indítania a kiszolgálót, hogy az új korlát működjön.

Figyelemfelhívás

Bár az alapértelmezett beállításon túl is növelhető az érték max_connections , javasoljuk, hogy ellenezzük.

A példányok nehézségekbe ütközhetnek, amikor a számítási feladat kibővül, és több memóriát igényel. A kapcsolatok számának növekedésével a memóriahasználat is nő. A korlátozott memóriával rendelkező példányok problémákba ütközhetnek, például összeomlásokkal vagy nagy késéssel. Bár a nagyobb érték max_connections elfogadható lehet, ha a kapcsolatok többsége tétlen, az aktívvá válás után jelentős teljesítményproblémákhoz vezethet.

Ha több kapcsolatra van szüksége, javasoljuk, hogy inkább a PgBouncert, a kapcsolatkészletek kezelésére szolgáló beépített Azure-megoldást használja. Használja tranzakciós módban. Első lépésként javasoljuk, hogy konzervatív értékeket használjon a virtuális magok 2–5 tartományon belüli megszorzásával. Ezután gondosan monitorozza az erőforrás-kihasználtságot és az alkalmazás teljesítményét a zökkenőmentes működés érdekében. A PgBouncerről további információt az Azure Database for PostgreSQL-ben található PgBouncerben talál.

Ha a kapcsolatok túllépik a korlátot, a következő hibaüzenet jelenhet meg:

FATAL: sorry, too many clients already.

Ha rugalmas Azure Database for PostgreSQL-kiszolgálópéldányt használ nagy számú egyidejű kapcsolattal rendelkező foglalt adatbázishoz, az erőforrások jelentős terhelést jelenthetnek. Ez a terhelés magas cpu-kihasználtságot eredményezhet, különösen akkor, ha sok kapcsolat jön létre egyidejűleg, és ha a kapcsolatok rövid időtartamúak (kevesebb mint 60 másodperc). Ezek a tényezők negatívan befolyásolhatják az adatbázis általános teljesítményét azáltal, hogy növelik a kapcsolatok és a leválasztások feldolgozására fordított időt.

A rugalmas Azure Database for PostgreSQL-kiszolgálópéldányok minden kapcsolata – függetlenül attól, hogy inaktív vagy aktív – jelentős mennyiségű erőforrást használ fel az adatbázisból. Ez a felhasználás teljesítményproblémákhoz vezethet a magas processzorhasználaton túl, például lemez- és zárolási versengéshez. A PostgreSQL Wiki adatbázis-kapcsolatok száma című cikke részletesebben ismerteti ezt a cikket. További információ: Kapcsolati teljesítmény azonosítása és megoldása az Azure Postgresben.

Funkcionális korlátozások

Az alábbi szakaszok a rugalmas Azure Database for PostgreSQL-kiszolgálópéldányok esetében támogatott és nem támogatott szempontokat sorolják fel.

Skálázási műveletek

• Jelenleg a kiszolgáló tárterületének vertikális felskálázásához újra kell indítani a kiszolgálót.
• A szerver tárolókapacitása csak 2x lépésenként skálázható. A részletekért tekintse meg a Storage című témakört.
• Jelenleg nem támogatjuk a kiszolgálói tárhely méretének csökkentését. Az egyetlen módja ennek a műveletnek az, hogy azt egy új, rugalmas Azure Database for PostgreSQL kiszolgálópéldányra mentse és visszaállítsa.

Storage

• Miután konfigurálta a tárterület méretét, nem csökkentheti azt. Létre kell hoznia egy új kiszolgálót a kívánt tárterülettel, manuális memóriakép- és visszaállítási műveletet kell végrehajtania, és át kell telepítenie az adatbázisokat az új kiszolgálóra.
• Ha a tárterület kihasználtsága eléri a 95%, vagy ha a rendelkezésre álló kapacitás kisebb, mint 5 GiB (amelyik több), a rendszer automatikusan írásvédett üzemmódra vált a kiszolgálót a lemeztel kapcsolatos hibák elkerülése érdekében. Ritka esetekben, ha az adatnövekedés sebessége túllépi az írásvédett módra való váltáshoz szükséges időt, előfordulhat, hogy a kiszolgáló még mindig elfogy. Engedélyezheti a tárterület automatikus használatát, hogy elkerülje ezeket a problémákat, és automatikusan skálázza a tárterületet a számítási feladatok igényei alapján.
• Azt javasoljuk, hogy bizonyos küszöbértékek túllépésekor storage used vagy storage percent amikor túllépik a riasztási szabályokat, hogy proaktívan végrehajthassa az olyan műveleteket, mint a tárterület méretének növelése. Beállíthat például egy riasztást, ha a tárterület százalékos kihasználtsága meghaladja a 80%-ot.
• Ha logikai replikációt használ, el kell dobnia a logikai replikációs pontot az elsődleges kiszolgálón, ha a megfelelő előfizető már nem létezik. Ellenkező esetben az előre írt naplózási (WAL) fájlok az elsődleges helyen halmozódnak fel, és kitöltik a tárterületet. Ha a tároló túllép egy bizonyos küszöbértéket, és a logikai replikációs pont nincs használatban (egy nem elérhető előfizető miatt), a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány automatikusan elveti a nem használt logikai replikációs pontot. Ez a művelet felszabadítja a felhalmozott WAL-fájlokat, és megakadályozza, hogy a kiszolgáló elérhetetlenné váljon, mert a tárterület megtelt.
• Nem támogatjuk a táblaterek létrehozását. Ha adatbázist hoz létre, ne adjon meg táblatérnevet. Egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldány a sablonadatbázis által örökölt alapértelmezett táblateret használja. Nem biztonságos olyan táblateret biztosítani, mint az ideiglenes, mert nem tudjuk biztosítani, hogy az ilyen objektumok állandóak maradjanak az olyan események után, mint a kiszolgáló újraindítása és a magas rendelkezésre állású (HA) feladatátvételek.
• Árva adatfájlok és lemezhasználati eltérések: Ritka esetekben előfordulhat, hogy a PostgreSQL árva adatfájlokat hagy a lemezen – azokat a fájlokat, amelyek már nem rendelkeznek megfelelő bejegyzésekkel az adatbázis rendszerkatalógusában (amely az összes táblát és adatot nyomon követi). Ez akkor fordulhat elő, ha egy tábla létrehozása és feltöltése sikertelen tranzakción belül történik (például egy kiszolgáló összeomlása vagy megszakítása miatt), ami az adatbázis által jelentett méret és a tényleges lemezhasználat közötti eltérést eredményez. Ez a viselkedés a PostgreSQL közösségi kódbázisából származik, és nem az Azure-ra jellemző. A PostgreSQL-közösség tisztában van a problémával, és a jövőbeli kiadásokban az automatikus törlés fejlesztéseit vizsgálja. További részletekért lásd: PostgreSQL: Árva fájlok a PostgreSQL-ben. Ez váratlanul magas lemez- vagy tárterület-használathoz vezethet.
  • Észlelés: Hasonlítsa össze az adatbázis által jelentett méretet (például SELECT pg_database_size('your_database')lekérdezések használatával) az Azure Portal tényleges lemezhasználati metrikáival . Ha jelentős eltérés van, az árva fájlok lehetnek az oka. Ha igen:
    • Futtassa a VACUUM FULL parancsot az érintett táblákon a terület felszabadításához (megjegyzés: ez erőforrás-igényes, táblazárolást igényel, és állásidőt igényelhet).
    • Alternatív megoldásként használja az olyan eszközöket, mint a pg_repack vagy a pg_squeeze bővítmények állásidő nélküli átszervezéshez, de először tesztkörnyezetben végezze el a próbát.
    • Monitorozás az Azure Portal metrikáival a lemezhasználati küszöbértékekhez. Ha a probléma továbbra is fennáll, vagy nem biztos benne, forduljon az Azure ügyfélszolgálatához segítségért.
  • Megelőzés: Győződjön meg arról, hogy a tranzakciók megfelelően vannak kezelve az alkalmazásokban a hiányos műveletek minimalizálása érdekében. Rendszeresen monitorozza a lemezhasználatot az Azure Portal metrikáin keresztül. A legújabb támogatott PostgreSQL-verzióra való frissítés közösségi javításokat is tartalmazhat a kapcsolódó problémákhoz.

hálózat

• Jelenleg nem támogatjuk a virtuális hálózatokba való áthelyezést.
• Jelenleg nem támogatjuk a nyilvános hozzáférés és a virtuális hálózat üzembe helyezésének kombinálását.
• A virtuális hálózatok nem támogatják a tűzfalszabályokat. Ehelyett hálózati biztonsági csoportokat használhat.
• A nyilvános hozzáférésű adatbázis-kiszolgálók csatlakozhatnak a nyilvános internethez; például: .postgres_fdw Ezt a hozzáférést nem korlátozhatja. A virtuális hálózatok kiszolgálói hálózati biztonsági csoportokon keresztül korlátozott kimenő hozzáféréssel rendelkezhetnek.

Magas szintű rendelkezésre állás

• Lásd a magas rendelkezésre állásra vonatkozó korlátozásokat.

Rendelkezésreállási zónák

• Jelenleg nem támogatjuk a kiszolgálók másik rendelkezésre állási zónába történő manuális áthelyezését. Ha azonban az előnyben részesített rendelkezésre állási zónát használja készenléti zónaként, bekapcsolhatja a HA-t. A készenléti zóna létrehozása után feladatátvételt végezhet rajta, majd kikapcsolhatja a HA-t.

Postgres motor, bővítmények és PgBouncer

• Egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldány támogatja a PostgreSQL-motor összes funkcióját, beleértve a particionálást, a logikai replikációt és a külső adatburkolókat.
• Egy Azure Database for PostgreSQL flexibilis kiszolgálópéldány az összes contrib bővítményt és többet is támogat. További információ: PostgreSQL-bővítmények.
• A rugalmas teljesítményű szerverek jelenleg nem férnek hozzá a beépített PgBouncer kapcsolatkészlet-kezelőhöz.

Leállítási/indítási műveletek

• Miután leállítja a rugalmas Azure Database for PostgreSQL-kiszolgálópéldányt, az hét nap után automatikusan elindul.

Ütemezett karbantartás

• Az egyéni karbantartási időszakot a hét bármely napjára/idejére módosíthatja. A karbantartási értesítés fogadása után végrehajtott módosítások azonban nem lesznek hatással a következő karbantartásra. A módosítások csak a következő havi ütemezett karbantartással lépnek érvénybe.

Kiszolgáló biztonsági mentései

• A rendszer kezeli a biztonsági mentéseket. A biztonsági mentések jelenleg nem futtathatók manuálisan. Javasoljuk, hogy inkább használja pg_dump .

• Az első pillanatkép egy teljes biztonsági mentés, az egymást követő pillanatképek pedig különbözeti biztonsági másolatok. A különbségi biztonsági másolatok csak a legutóbbi pillanatkép-biztonsági mentés óta módosított adatokról készít biztonsági másolatot.

  Ha például az adatbázis mérete 40 GB, a kiépített tárterület pedig 64 GB, az első pillanatkép biztonsági mentése 40 GB. Most, ha 4 GB adatot módosít, a következő különbségi pillanatkép biztonsági mentési mérete csak 4 GB lesz. A tranzakciónaplók (előreírási naplók) elkülönülnek a teljes és a különbözeti biztonsági másolatoktól, és folyamatosan archiválva vannak.

Kiszolgáló visszaállítása

• Az időponthoz kötött visszaállítás (PITR) használatakor a rendszer az új kiszolgálót ugyanazokkal a számítási és tárolási konfigurációkkal hozza létre, mint a kiszolgáló, amelyen alapul.
• A rendszer visszaállítja a virtuális hálózatok adatbázis-kiszolgálóit ugyanarra a virtuális hálózatra, amikor biztonsági másolatból állít vissza.
• A visszaállítás során létrehozott új kiszolgáló nem rendelkezik az eredeti kiszolgálón meglévő tűzfalszabályokkal. Az új kiszolgálóhoz külön tűzfalszabályokat kell létrehoznia.
• Nem támogatjuk a másik előfizetésre való visszaállítást. Áthidaló megoldásként visszaállíthatja a kiszolgálót ugyanabban az előfizetésben, majd migrálhatja a visszaállított kiszolgálót egy másik előfizetésbe.

Biztonság

• A Postgres 14- és újabb verziói letiltják az MD5-kivonatolást, és a rendszer csak SCRAM-SHA-256 metódussal kivonatolta a natív Postgres-jelszavakat.

Kapcsolódó tartalom

• Számítási lehetőségek az Azure Database for PostgreSQL-ben.
• Tárolási lehetőségek az Azure Database for PostgreSQL-ben.
• A PostgreSQL támogatott verziói az Azure Database for PostgreSQL-ben.