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. A tábla tehát 15-tal csökkenti a maximális felhasználói kapcsolatok értékét a teljes maximális kapcsolatból.

Terméknév vCores Memória mérete Kapcsolatok maximális száma Felhasználói kapcsolatok maximális száma
Kipukkanható
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 GiB 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
á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 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 GiB 5,000 4,985
D96ds_v5/ D96ads_v5 96 384 GiB 5,000 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 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 GiB 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

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.

Caution

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 (amelyek az összes táblát és adatot nyomon követik). Ez akkor fordulhat elő, ha a rendszer létrehoz és feltölt egy táblát egy olyan tranzakción belül, amely nem sikerül (például egy kiszolgáló összeomlása vagy megszakadása miatt), ami az adatbázis által jelentett méret és a tényleges lemezhasználat közötti eltérést eredményezi. 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 információ: 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 visszanyeréséhez (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áljon olyan eszközöket, mint a pg_repack vagy pg_squeeze bővítmények átszervezésére állásidő nélkül, de először tesztelje nem gyártási környezetben.
      • 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 tartalmazhat közösségi javításokat 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

Elérhetőségi 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. Ehelyett pg_dump használatát javasoljuk.

  • 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 PostgreSQL 14-ös é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

  • Last updated on