Megosztás a következőn keresztül:

Főverzió-frissítések az Azure Database for PostgreSQL-ben

A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány támogatja a PostgreSQL 18., 17., 16., 15., 14., 13., 12. és 11. verzióját. A Postgres-közösség egy új főverziót ad ki, amely évente körülbelül egyszer tartalmaz új funkciókat. Emellett minden főverzió rendszeres hibajavításokat kap kisebb kiadások formájában. Az alverziófrissítések olyan módosításokat tartalmaznak, amelyek visszamenőlegesen kompatibilisek a meglévő alkalmazásokkal. Egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldány rendszeresen frissíti az alverziókat az ügyfél karbantartási időszakában.

A főverzió-frissítések bonyolultabbak, mint az alverziófrissítések. Tartalmazhatnak belső módosításokat és olyan új funkciókat, amelyek esetleg nem kompatibilisek a meglévő alkalmazásokkal.

A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány olyan szolgáltatással rendelkezik, amely egyetlen kattintással végrehajtja a kiszolgáló helyi főverzió-frissítését. Ez a funkció leegyszerűsíti a frissítési folyamatot azáltal, hogy minimalizálja a kiszolgálóhoz hozzáférő felhasználók és alkalmazások fennakadásait.

A helyi frissítések megtartják az aktuális kiszolgáló nevét és egyéb beállításait a főverzió frissítése után. Nem igényelnek adatmigrálást vagy az alkalmazás kapcsolati sztring módosítását. A helyi verziófrissítés gyorsabb, és rövidebb állásidőt igényel, mint az adatmigrálás.

Megjegyzés:

Az Azure Database for PostgreSQL csak a jelenleg támogatott PostgreSQL-verziókra támogatja a helyszíni főverzió-frissítéseket. Frissítheti például az aktuális verziót, mivel a célverziót az Azure a frissítés időpontjában hivatalosan is támogatja. A nem támogatott verziók nem választhatók ki frissítési célként, és ha elavult verzióra próbál frissíteni, az meghibásodást vagy szolgáltatáskimaradást okozhat. A főverzió-frissítés megkezdése előtt mindig tekintse meg az Azure PostgreSQL verziószámozási szabályzatát és a frissítés dokumentációját .

Megjegyzés:

A fő verziófrissítéseket a PostgreSQL 18-ra fokozatosan engedélyezik. Jelenleg az MVU és a PostgreSQL 18 elérhető a NorthCentralUS és a WestCentralUS régiókban.

Frissítési folyamat

Íme néhány fontos szempont a helyszíni főverzió-frissítésekkel kapcsolatban:

  • A frissítés megkezdése előtt győződjön meg arról, hogy a kiszolgáló legalább 10–20% szabad tárterület áll rendelkezésre. A frissítési folyamat során az ideiglenes naplófájlok és metaadat-műveletek növelhetik a lemezhasználatot. A szabad terület hiánya frissítési hibákat vagy visszaállítási problémákat okozhat.
  • A helyszíni főverzió-frissítés során a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány egy előzetes ellenőrzési eljárást futtat, amely azonosítja az esetleges problémákat, amelyek miatt a frissítés meghiúsulhat.
    • Ha az előellenőrzés bármilyen inkompatibilitást talál, létrehoz egy naplóeseményt, amely azt mutatja, hogy a frissítési előellenőrzés sikertelen volt, és hibaüzenet jelenik meg.
    • Ha az előzetes ellenőrzés sikeres, a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány leállítja a szolgáltatást, és implicit biztonsági másolatot készít a frissítés megkezdése előtt. A szolgáltatás ezzel a biztonsági mentéssel visszaállíthatja az adatbázispéldányt a korábbi verzióra, ha frissítési hiba történt.
  • Egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldány a pg_upgrade eszközzel hajtja végre a helyi főverzió-frissítéseket. A szolgáltatás rugalmasságot biztosít a verziók kihagyásához és a későbbi verziókra való közvetlen frissítéshez.
  • A magas rendelkezésre állású (HA) kiszolgáló helyszíni főverziójának frissítése során a szolgáltatás letiltja a HA-t, végrehajtja a frissítést az elsődleges kiszolgálón, majd a frissítés befejezése után újra engedélyezi a HA-t.
  • A legtöbb bővítmény automatikusan frissül a későbbi verziókra egy helyszíni főverzió-frissítés során, néhány kivételtől eltekintve.
  • A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány helyi főverzió-frissítésének folyamata automatikusan telepíti a legújabb támogatott alverziót.
  • A helyszíni főverzió-frissítés offline művelet, ami azt jelenti, hogy a kiszolgáló nem lesz elérhető a folyamat során. Bár a legtöbb frissítés 15 perc alatt befejeződik, a tényleges időtartam az adatbázis méretétől és összetettségétől függ. Pontosabban a szükséges idő közvetlenül arányos a PostgreSQL-példányban lévő objektumok (táblák, indexek, sémák) számával. A nagyobb vagy összetettebb sémák hosszabb frissítési időt tapasztalhatnak.
  • A frissítés előtt hosszú ideig futó tranzakciók vagy nagy számítási feladatok növelhetik az adatbázis leállításához és a frissítési idő növeléséhez szükséges időt.
  • A helyszíni főverzió-frissítés sikeres elvégzése után nincs automatizált mód a korábbi verzióra való visszaállításra. A frissítés előtti időpontra történő helyreállítást (PITR) azonban elvégezheti az adatbázispéldány korábbi verziójának visszaállításához.
  • A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány pillanatképet készít az adatbázisról a frissítés során. A pillanatkép a frissítés megkezdése előtt készül el. Ha a frissítés sikertelen, a rendszer automatikusan visszaállítja az adatbázis állapotát a pillanatképből.
  • A PostgreSQL 16 szerepköralapú biztonsági intézkedéseket vezet be. A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány főverzió-frissítése után a kiszolgálón létrehozott első felhasználó – aki rendszergazdai lehetőséget kap – mostantól rendszergazdai jogosultságokkal fog rendelkezni az alapvető karbantartási műveletek más szerepköreivel szemben.

Frissítési szempontok és korlátozások

Ha egy helyszíni főverzió frissítése során egy előzetes ellenőrzési művelet meghiúsul, a frissítés le lesz tiltva egy részletes hibaüzenettel. Az alábbiakban azokat az ismert korlátozásokat ismertetjük, amelyek miatt a frissítés meghiúsulhat vagy váratlanul viselkedhet:

Nem támogatott kiszolgálókonfigurációk

  • Az olvasási replikák nem támogatottak a helyszíni frissítések során. Az elsődleges kiszolgáló frissítése előtt törölnie kell az olvasási replikát (beleértve a kaszkádolt olvasási replikát is). A frissítést követően újból létrehozhatja a replikát.
  • A hálózati forgalmi szabályok blokkolhatják a frissítési műveleteket.
    • Győződjön meg arról, hogy a rugalmas kiszolgálópéldány képes forgalmat küldeni/fogadni az 5432-ben és a 6432-ben lévő portokon a virtuális hálózaton belül, valamint az Azure Storage-ba (naplóarchiválás céljából).
    • Ha a hálózati biztonsági csoportok (NSG-k) korlátozzák ezt a forgalmat, a HA nem engedélyezi újra automatikusan a frissítést követően. Előfordulhat, hogy manuálisan kell frissítenie az NSG-szabályokat, és újra engedélyeznie kell a HA-t.
  • A logikai replikációs pontok nem támogatottak a helyszíni főverzió-frissítések során.
  • Az SSDv2-tárolót használó kiszolgálók nem jogosultak a főverzió-frissítésekre.
  • A főverzió-frissítések során a pg_stat_activity-től függő nézetek nem támogatottak.
  • Ha a PG11-ről egy magasabb verzióra frissít, először konfigurálnia kell a rugalmas szervert a SCRAM-hitelesítés használatára a SCRAM engedélyezése révén és az összes bejelentkezési szerepkör jelszavának alaphelyzetbe állításával.

Bővítménykorlátozások

A helyszíni főverzió-frissítések nem támogatják az összes PostgreSQL-bővítményt. A frissítés sikertelen lesz az előzetes ellenőrzés során, ha nem támogatott bővítmények találhatók.

  • Az alábbi bővítmények rendszeres használat esetén támogatottak, de ha vannak, letiltják a főverziók helyben történő frissítését. Távolítsa el őket a frissítés előtt, és engedélyezze újra őket, ha a célverzió támogatja: timescaledb, dblink, orafce, postgres_fdw.
  • A következő bővítmények nem állandó segédprogrambővítmények , amelyeket el kell dobni és újra létre kell hozni a frissítés után: pg_repack, hypopg.
  • A PostgreSQL 17-re való frissítéskor a következő bővítmények nem támogatottak , ezért a frissítés előtt el kell távolítani őket. Akkor engedélyezheti újra őket, ha a célverzióban támogatottak: age, azure_ai, hll, pg_diskann, pgrouting.

Jegyzet: Ha ezen bővítmények bármelyike megjelenik a azure.extensions kiszolgálóparaméterben, a frissítés le lesz tiltva. A frissítés megkezdése előtt távolítsa el őket a paraméterből.

PostGIS-Specific szempontok

Ha PostGIS-t vagy függő bővítményeket használ, konfigurálnia kell a search_path kiszolgálóparamétert a következőkre:

  • A PostGIS-hez kapcsolódó sémák
  • Függő bővítmények, beleértve a következőket: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_usfuzzystrmatch
  • A search_path helyes konfigurálásának elmulasztása frissítési hibákhoz vagy a frissítés után hibás objektumokhoz vezethet.

Egyéb frissítési szempontok

  • Eseményindítók: A frissítés előtti ellenőrzés letiltja az eseményindítókat, mert DDL-parancsokhoz csatlakoznak, és hivatkozhatnak a fő verziók között változó rendszerkatalógusokra – a frissítés előtt elvetheti az összeset EVENT TRIGGER, majd a frissítés után újból létrehozhatja őket a zökkenőmentes frissítés érdekében.
  • Nagy méretű objektumok (LOs): A több millió nagy objektumot tartalmazó (tárolt pg_largeobject) adatbázisok a magas memóriahasználat vagy a naplók mennyisége miatt frissítési hibákat okozhatnak. Használja a vacuumlo segédprogramot a nem használt LOS-k eltávolításához, és fontolja meg a kiszolgáló skálázását a frissítés előtt, ha sok LOS még használatban van.

Figyelmeztetés

Óvatosan használja a porszívót. vacuumlo a hagyományos referenciaoszlopok (oid, lo) alapján azonosítja az árva nagyméretű objektumokat. Ha az alkalmazás egyéni vagy közvetett hivatkozástípusokat használ, előfordulhat, hogy az érvényes nagy objektumok tévesen törlődnek. Emellett jelentős processzor-, vacuumlo memória- és IOPS-kapacitást is igénybe vehet, különösen nagy méretű objektumokat tartalmazó adatbázisokban. Futtassa a karbantartási időszakokban, és először azt tesztelje a nem éles környezetben.

Frissítés után

A főverzió frissítése után javasoljuk, hogy futtassa a parancsot az ANALYZE egyes adatbázisokban a pg_statistic tábla frissítéséhez. A hiányzó vagy elavult statisztikák rossz lekérdezési tervekhez vezethetnek, ami ronthatja a teljesítményt, és túlzott memóriát vesz igénybe.

postgres=> analyze;
ANALYZE

Frissítési naplók megtekintése

A főverzió-frissítési naplók (PG_Upgrade_Logs) közvetlen hozzáférést biztosítanak a részletes kiszolgálónaplókhoz. A frissítési folyamatba való integrálással PG_Upgrade_Logs zökkenőmentesebbé és átláthatóbbá teheti az új PostgreSQL-verziókra való áttérést.

A fő verziófrissítési naplókat ugyanúgy konfigurálhatja, mint a kiszolgálónaplókat a következő kiszolgálóparaméterek használatával:

  • A funkció bekapcsolásához állítsa logfiles.download_enable értékét ON-re.
  • A naplófájlok napokon belüli megőrzésének meghatározásához használja a következőt logfiles.retention_days: .

Frissítési naplók beállítása

A használat PG_Upgrade_Logsmegkezdéséhez konfigurálhatja a PostgreSQL-kiszolgálónaplók és a fő verziófrissítési naplók rögzítését.

A frissítési naplókat a kiszolgálónaplók felhasználói felületén keresztül érheti el. Itt valós időben követheti nyomon a PostgreSQL főverziófrissítéseinek előrehaladását és részleteit. Ez a felhasználói felület központi helyet biztosít a naplók megtekintéséhez, így könnyebben nyomon követheti és elháríthatja a frissítési folyamatot.

A frissítési naplók használatának előnyei

  • Éleslátó diagnosztikák: PG_Upgrade_Logs értékes betekintést nyújt a frissítési folyamatba. Részletes információkat rögzít az elvégzett műveletekről, és kiemeli az esetleges hibákat és figyelmeztetéseket. Ez a részletesség fontos szerepet játszott a frissítés során felmerülő problémák diagnosztizálásában és megoldásában, a zökkenőmentesebb átmenet érdekében.
  • Egyszerűsített hibaelhárítás: A naplókhoz való közvetlen hozzáféréssel gyorsan azonosíthatja és kezelheti a lehetséges frissítési akadályokat, csökkentheti az állásidőt, és minimalizálhatja a műveletekre gyakorolt hatást. A naplók kulcsfontosságú hibaelhárítási eszközként szolgálnak azáltal, hogy hatékonyabb és hatékonyabb problémamegoldást tesz lehetővé.

Megjegyzés:

A helyszíni főverzió-frissítések támogatottak az automatikusan telepített kiszolgálókon. Miután egy automatikusan migrált kiszolgálón sikeresen végrehajtottak egy helyben történő főverzió-frissítést, a username@servername formátumú felhasználónév többé nem lesz támogatott. Ehelyett a szokásos formátumot kell használnia: felhasználónév. A hitelesítési problémák elkerülése érdekében gondosan tekintse át és frissítse az alkalmazások és szkriptek összes kapcsolati sztringét, hogy a frissítés után a frissített felhasználónév formátumot használják.

Kapcsolódó tartalom

  • Last updated on