Magas rendelkezésre állás az Azure Database for PostgreSQL rugalmas kiszolgálóban

Azure Database for PostgreSQL fizikailag elkülönített elsődleges és készenléti replikák kiépítésével támogatja a magas rendelkezésre állást. Ez a magas rendelkezésre állási modell biztosítja, hogy a véglegesített adatok soha ne vesszenek el a hibák során. Magas rendelkezésre állású (HA) beállítás esetén a rendszer szinkron módon véglegesíti az adatokat az elsődleges és a készenléti kiszolgálókon is. A modell úgy lett kialakítva, hogy az adatbázis ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában.

A szolgáltatás alapértelmezés szerint a legtöbb régióban az elsődleges replikától eltérő rendelkezésre állási zónába helyezi üzembe a készenléti replikát (zónaredundáns). Az elsődleges és a készenléti replikákat ugyanabban a rendelkezésre állási zónában (zonal) is üzembe helyezheti.

Magas rendelkezésre állású funkciók

• Az elsődleges kiszolgáló és a készenléti replika ugyanazt a virtuálisgép-konfigurációt használja, beleértve a virtuális magokat, a tárterületet és a hálózati beállításokat.

• A rendelkezésre állási zónák támogatását meglévő adatbázis-kiszolgálóhoz is hozzáadhatja.

• A készenléti kiszolgáló mellett az architektúra tartalmaz egy WAL replikakiszolgálót a kvórum véglegesítésének fenntartásához. Olyan esetekben, amikor a készenléti kiszolgáló átmenetileg nem érhető el, a rendszer a tartósság biztosítása érdekében véglegesíteni kívánja a tranzakciókat az elsődleges kiszolgálón és a WAL replikakiszolgálón. Amikor a készenléti kiszolgáló ismét elérhetővé válik, automatikusan utoléri az elsődleges kiszolgálót. Ez az architektúra biztosítja a véglegesített rekordok tartós megőrzését.

• Feladatátvétel esetén a folyamat csak a készenléti kiszolgálót előlépteti az új elsődleges kiszolgálóvá. A WAL replikakiszolgáló nincs előléptetve, és kizárólag a véglegesítés kvórumának fenntartására szolgál.

• Letilthatja a magas rendelkezésre állást, ami eltávolítja a készenléti replikát.

• A zónaredundáns magas rendelkezésre állás érdekében kiválaszthatja az elsődleges és a készenléti adatbázis-kiszolgálók rendelkezésre állási zónáit.

• Egyszerre hajthat végre olyan műveleteket, mint a leállítás, az indítás és az újraindítás mind az elsődleges, mind a készenléti adatbázis-kiszolgálókon.

• Az elsődleges adatbázis-kiszolgáló rendszeres időközönként automatikus biztonsági mentéseket végez. Ugyanakkor a készenléti replika folyamatosan archiválja a tranzakciónaplókat a biztonsági mentési tárban. Zónaredundáns kiszolgálók esetén a biztonsági mentési adatok zónaredundáns tárolóban (ZRS) vannak tárolva. A zónaredundancia nélkül konfigurált kiszolgálók, a zónaalapú (egyzónás) kiszolgálók és a rendelkezésre állási zónákat nem támogató régiókban a biztonsági mentési adatok helyileg redundáns tárolóban (LRS) vannak tárolva.

• Az ügyfelek mindig az elsődleges adatbázis-kiszolgáló végső állomásnevéhez csatlakoznak.

• A paraméterek módosításait a készenléti replikára is alkalmazza a rendszer.

• A kiszolgáló újraindításával érvénybe léptetheti a statikus paraméterek módosításait.

• Az időszakos karbantartási tevékenységek, például az alverziófrissítések először a készenléti állapotban történnek. Az állásidő csökkentése érdekében a folyamat a készenléti csomópontot elsődleges csomóponttá lépteti elő, hogy a számítási feladatok tovább futhassanak, miközben a karbantartási feladatokat a másik csomóponton végrehajtják.

Megjegyzés:

A magas rendelkezésre állás megfelelő működésének biztosításához konfigurálja a max_replication_slots és max_wal_senders paraméterértékeket. A magas rendelkezésre állás érdekében négy-négy eszköz vagy rendszer szükséges a feladatátvétel és a zökkenőmentes frissítések kezelésére. Ha magas rendelkezésre állású beállítást szeretne beállítani öt olvasási replikával és 12 logikai replikációs tárolóhellyel, állítsa mindkettőt max_replication_slots és max_wal_senders paraméterértéket 21-re. Erre a konfigurációra azért van szükség, mert minden olvasási replikához és logikai replikációs ponthoz szükség van egy-egyre, valamint a magas rendelkezésre álláshoz szükséges négyre a megfelelő működéshez. További információt max_replication_slots és max_wal_senders paramétereket a dokumentációban talál.

Rendelkezésre állási zóna támogatási típusai

Azure Database for PostgreSQL támogatja a zónaredundáns és a zónaalapú modelleket a magas rendelkezésre állású konfigurációkhoz. Mindkét magas rendelkezésre állású konfiguráció lehetővé teszi az automatikus feladatátvételi képességet, amely a tervezett és a nem tervezett események során is zéró adatvesztést eredményez.

• Zónaredundáns. A zónaredundáns magas rendelkezésre állás egy készenléti replikát helyez üzembe egy másik zónában automatikus feladatátvételi képességgel. A zónaredundancia biztosítja a legmagasabb rendelkezésre állást, de az alkalmazás redundanciát a zónák között kell konfigurálnia. Ezért válassza ki a zónaredundanciát, ha védelmet szeretne kapni a rendelkezésre állási zónaszintű hibáktól, és ha a rendelkezésre állási zónák késése elfogadható. Bár a szinkron replikáció miatt az írások és véglegesítések némi késéssel járhatnak, az nem befolyásolja az olvasási lekérdezéseket. Ez a hatás a számítási feladatokra, a kiválasztott termékváltozat típusára és a régióra vonatkozik.

  Az elsődleges és a készenléti kiszolgálókhoz is kiválaszthatja a régiót és a rendelkezésre állási zónákat. A készenléti replikakiszolgáló a kiválasztott rendelkezésre állási zónában van kiépítve ugyanabban a régióban, az elsődleges kiszolgálóhoz hasonló számítási, tárolási és hálózati konfigurációval. Az adatfájlokat és a tranzakciós naplófájlokat (írási naplók, más néven WAL) helyileg redundáns tárolóban (LRS) tárolják az egyes rendelkezésre állási zónákban, és automatikusan három adatmásolatot tárolnak. A zónaredundáns konfiguráció biztosítja a teljes verem fizikai elkülönítését az elsődleges és a készenléti kiszolgálók között.

  

  A zónaredundáns beállítás csak olyan régiókban érhető el , amelyek támogatják a rendelkezésre állási zónákat.

  Nem érhető el zónaredundancia az alábbiakhoz:

  • Rugalmas számítási szint
  • Régiók egyzónás rendelkezésre állással

• Azonos zóna (zonális). Válassza a zónális telepítést, ha egy rendelkezésre állási zónán belül szeretné elérni a legmagasabb rendelkezésre állási szintet, ugyanakkor a lehető legalacsonyabb hálózati késleltetést. Kiválaszthatja a régiót és a rendelkezésre állási zónát az elsődleges adatbázis-kiszolgáló üzembe helyezéséhez. A készenléti replikakiszolgálók automatikusan ugyanabban a rendelkezésre állási zónában vannak kiépítve és felügyelve – hasonló számítási, tárolási és hálózati konfigurációval – mint az elsődleges kiszolgáló. Az zonális konfiguráció védi az adatbázisokat a csomópontszintű hibáktól, és segít csökkenteni az alkalmazások állásidejét a tervezett és nem tervezett leállási események során. Az elsődleges kiszolgáló adatai szinkron módban replikálódnak a készenléti replikára. ha bármilyen fennakadás történik az elsődleges kiszolgálón, a kiszolgáló automatikusan átesik a készenléti replikán.

  

  A zonal üzembe helyezési lehetőség minden Azure régióban elérhető ahol rugalmas kiszolgálót helyezhet üzembe.

Megjegyzés:

A zóna- és zónaredundáns üzemi modellek is architekturálisan ugyanúgy viselkednek. A következő szakaszokban szereplő különböző viták mindkettőre vonatkoznak, hacsak másként nem említjük.

Zónahibák helyreállítása

• Zone-redundáns: Azure Database for PostgreSQL automatikusan 60–120 másodpercen belül, nulla adatvesztéssel automatikusan átveszi a készenléti kiszolgálót.

• Zóna: Ha egy zóna meghibásodik, az elsődleges és a készenléti kiszolgáló sem érhető el. Ha zónaszintű hiba miatt szeretne helyreállni, a biztonsági másolat használatával időponthoz kötött visszaállítást hajthat végre . Kiválaszthatja az egyéni visszaállítási pontot a legújabb időponttal a legújabb adatok visszaállításához. A rendszer üzembe helyez egy új rugalmas kiszolgálót egy másik, nem érintett zónában. A visszaállítás időtartama az előző biztonsági mentéstől és a helyreállítandó tranzakciónaplók mennyiségétől függ.

  Az időpontra jellemző helyreállításról további információt a Biztonsági mentés és visszaállítás az Azure Database for PostgreSQL rugalmas kiszolgálón menüpontban talál.

Szolgáltatásiszint-szerződés (SLA)

A zóna-redundancia-modell körülbelül 99,99%-os üzemidőt biztosít egy SLA számára. A Zonal modell körülbelül 99,95% üzemidőt kínál az SLA követelményeknek megfelelően.

Azure Database for PostgreSQL magas rendelkezésre állás nélkül

Bár nem ajánlott, konfigurálhatja a rugalmas kiszolgálót anélkül, hogy engedélyezve van a magas rendelkezésre állás. A magas rendelkezésre állás nélkül konfigurált rugalmas kiszolgálók esetében a szolgáltatás helyileg redundáns tárolást biztosít három adatmásolattal és beépített kiszolgálói rugalmassággal az összeomlott kiszolgáló automatikus újraindításához és a kiszolgáló másik fizikai csomópontra való áthelyezéséhez. Ez a konfiguráció alacsonyabb üzemidejű SLA-t kínál, mint a magas rendelkezésre állású kiszolgálók. Tervezett vagy nem tervezett feladatátvételi események során, ha a kiszolgáló leáll, a szolgáltatás az alábbi automatizált eljárással fenntartja a kiszolgálók rendelkezésre állását:

1. Kiépült egy új számítási Linux rendszerű virtuális gép.
2. Az adatfájlokat tartalmazó tároló az új virtuális gépre van leképezve.
3. A PostgreSQL adatbázismotorja online állapotba kerül az új virtuális gépen.

Az alábbi képen a virtuális gép és a tárolási hiba közötti átmenet látható.

Üzletileg kritikus (magas rendelkezésre állás) beállítások konfigurálása

A magas rendelkezésre állás (HA) kétféleképpen konfigurálható: zónaredundáns HA, amely a maximális zónarugalmasság érdekében egy másik rendelkezésre állási zónába helyezi a készenléti kiszolgálót, vagy ugyanazzal a zónával rendelkező HA, amely az elsődleges kiszolgálóval azonos zónában helyezi üzembe a készenléti kiszolgálót a késés minimalizálása érdekében.

Az Üzleti szempontból kritikus (magas rendelkezésre állás) szakasz lehetővé teszi, hogy zónaredundáns konfigurációval rendelkező készenléti HA-kiszolgálót hozzon létre. A konfiguráció egyszerűsítése és a zóna rugalmasságának biztosítása érdekében a portál egy zonális rugalmassági lehetőséget biztosít két választógombdal: Engedélyezve és Letiltva. A készenléti kiszolgáló más rendelkezésre állási zónában (zónaredundáns HA módban) történő létrehozásának engedélyezése. Ha a régió nem támogatja a zónaredundáns HA-t, jelölje be a tartalék jelölőnégyzetet az azonos zónás (zónaszintű) HA engedélyezéséhez.

Ha bejelöli a tartalék jelölőnégyzetet, a rendszer ugyanabban a zónában hozza létre a készenléti kiszolgálót. Ha a zonális kapacitás később elérhetővé válik, Azure automatikusan migrálja a számítási feladatokat az azonos zónájú HA-ból a zónaredundáns HA-ba. Ha nem bejelöli a jelölőnégyzetet, és a zónakapacitás nem érhető el, a HA engedélyezése meghiúsul. Ez a kialakítás a zónaredundáns HA-t kényszeríti alapértelmezettként, miközben szabályozott tartalékot biztosít az azonos zónás HA-hoz, így biztosítva, hogy a számítási feladatok végül teljes zónaszintű rugalmasságot érjenek el.

Azure Database for PostgreSQL létrehozása engedélyezett rendelkezésre állási zónával

A magas rendelkezésre állású Azure Database for PostgreSQL rendelkezésre állási zónákkal való létrehozásáról a Gyorsútmutató: Azure Database for PostgreSQL létrehozása az Azure portálon.

Rendelkezésre állási zóna ismételt üzembe helyezése és migrálása

Ha szeretné megtudni, hogyan engedélyezheti vagy tilthatja le a magas rendelkezésre állású konfigurációt a rugalmas kiszolgálón zónaredundáns és zónaalapú üzemi modellekben, olvassa el a Rugalmas kiszolgáló magas rendelkezésre állásának kezelése című témakört.

Magas rendelkezésre állású állapotfelügyelet

A magas rendelkezésre állás (HA) állapotmonitorozása Azure Database for PostgreSQL folyamatos áttekintést nyújt a HA-kompatibilis példányok állapotáról és felkészültségéről. Ez a figyelési funkció a Azure Resource Health Check (RHC) keretrendszerét alkalmazza az adatbázis feladatátvételi készültségét vagy általános rendelkezésre állását esetlegesen befolyásoló problémák észlelésére és riasztására. A fő metrikák, például a kapcsolat állapota, a feladatátvételi állapot és az adatreplikációs állapot felmérésével a HA állapotmonitorozása proaktív hibaelhárítást tesz lehetővé, és segít fenntartani az adatbázis üzemidejét és teljesítményét.

Használja a HA egészségügyi állapot figyelésére:

• Valós idejű elemzéseket kaphat az elsődleges és a készenléti replikák állapotáról, olyan állapotjelzőkkel, amelyek potenciális problémákat, például csökkentett teljesítményt vagy hálózati blokkolást tárnak fel.
• Állítson be riasztásokat a HA állapotának esetleges változásaival kapcsolatos időben történő értesítésekhez, így azonnali lépéseket tehet a lehetséges fennakadások kezelése érdekében.
• Optimalizálhatja a feladatátvételi készültséget a problémák azonosításával és kezelésével, mielőtt azok hatással lennének az adatbázis-műveletekre.

A magas rendelkezésre állású állapotok konfigurálásáról és értelmezéséről az Azure Database for PostgreSQL magas rendelkezésre állási állapotának monitorozása című útmutatóban olvashat.

Magas rendelkezésre állási korlátozások

• Az elsődleges és a készenléti kiszolgáló közötti replikáció szinkron.

• A készenléti HA-kiszolgáló nem használható olvasási lekérdezésekhez.

• Az elsődleges kiszolgáló számítási feladataitól és tevékenységétől függően a feladatátvételi folyamat 120 másodpercnél hosszabb időt vehet igénybe, mert a készenléti replikát helyre kell állítani, mielőtt előléptethető lenne.

• A készenléti kiszolgáló általában 40 MB/s sebességgel helyreállítja a WAL-fájlokat. Nagyobb verziók esetén ez a sebesség akár 200 MB/s-ra is nőhet. Ha a számítási feladat túllépi ezt a korlátot, a helyreállítás hosszabb időt vehet igénybe a feladatátvétel során vagy egy új készenléti állapot létrehozása után.

• Az elsődleges adatbázis-kiszolgáló újraindítása szintén újraindítja a készenléti replikát.

• Nem konfigurálhat további készenléti állapotot.

• A felügyelt karbantartási időszak alatt nem ütemezhet ügyfél által kezdeményezett felügyeleti feladatokat.

• A tervezett események, mint például a számítástechnika méretezése és a tárhely méretezése először a készenléti gépen, majd az elsődleges kiszolgálón történnek. Jelenleg a kiszolgáló nem hajt végre automatikus átváltást ezeknél a tervezett műveleteknél.

• Nem támogatott a rendelkezésre állási zónák konfigurálása privát (virtuális hálózat) és nyilvános hozzáférés között privát végpontokkal. A rendelkezésre állási zónákat egy virtuális hálózaton belül kell konfigurálnia (egy régió rendelkezésre állási zónáira kiterjedően), vagy nyilvános hozzáférést magánvégpontokkal.

• A rendelkezésre állási zónákat csak egyetlen régión belül konfigurálhatja. A rendelkezésre állási zónák nem konfigurálhatók régiók között.

Magas rendelkezésre állású összetevők és munkafolyamat

Tranzakció befejezése

Egy alkalmazástranzakció elindít egy írást és véglegesítést, amely először naplózza a WAL-t az elsődleges kiszolgálón. Az elsődleges kiszolgáló a Postgres streaming protokoll használatával streameli ezeket a naplókat a készenléti kiszolgálóra. Ha a készenléti kiszolgáló tárolója megőrzi a naplókat, az elsődleges kiszolgáló nyugtázza az írás befejezését. Az alkalmazás csak a nyugtázás után véglegesíti a tranzakciót. Ez a plusz oda-vissza utazás késést ad az alkalmazásnak. A hatás százalékos aránya az alkalmazástól függ. Ez a nyugtázási folyamat nem várja meg, amíg a naplók a készenléti kiszolgálóra lesznek alkalmazva. A készenléti kiszolgáló helyreállítási módban marad, amíg nem kerül előléptetésre.

Állapot-ellenőrzés

A rugalmas kiszolgálóállapot-monitorozás rendszeres időközönként ellenőrzi az elsődleges és a készenléti kiszolgálók állapotát is. Ha több pingelés után az állapotfigyelés azt észleli, hogy az elsődleges kiszolgáló nem érhető el, a szolgáltatás automatikus feladatátvételt kezdeményez a készenléti kiszolgálóra. Az állapotmonitorozási algoritmus több adatpontot használ a hamis pozitív helyzetek elkerülése érdekében.

Átkapcsolási módok

A rugalmas kiszolgáló két feladatátvételi módot támogat, a tervezett feladatátvételt és a nem tervezett feladatátvételt. Mindkét módban a replikáció megszakadása után a készenléti kiszolgáló a helyreállítást az előléptetés előtt futtatja elsődlegesként, és megnyílik az olvasási/írási műveletek számára. Az új elsődleges kiszolgálóvégponttal frissített automatikus DNS-bejegyzések esetén az alkalmazások ugyanazzal a végponttal csatlakozhatnak a kiszolgálóhoz. A háttérben létrejön egy új készenléti kiszolgáló, hogy az alkalmazás fenntarthassa a kapcsolatot.

Magas rendelkezésre állás állapota

A rendszer folyamatosan figyeli az elsődleges és a készenléti kiszolgálók állapotát. Megfelelő műveleteket végez a problémák megoldásához, beleértve a feladatátvételt a készenléti kiszolgálóra. Az alábbi táblázat a lehetséges magas rendelkezésre állási állapotokat sorolja fel:

Status	Leírás
Inicializálás	Új készenléti kiszolgáló létrehozása folyamatban.
Adatok replikálása	A készenléti állapot létrehozása után felzárkózni fog az elsődlegeshez.
Egészséges	A replikáció stabil állapotban és kifogástalan állapotban van.
Átváltás	Az adatbázis-kiszolgáló éppen átkapcsol a készenléti rendszerre.
Készenléti állapot eltávolítása	A készenléti kiszolgáló törlésének folyamatában.
Nincs engedélyezve	A magas rendelkezésre állás nincs engedélyezve.

Megjegyzés:

A magas rendelkezésre állást a kiszolgáló létrehozásakor vagy egy későbbi időpontban engedélyezheti. Ha a létrehozás utáni szakaszban engedélyezi vagy letiltja a magas rendelkezésre állást, ezt akkor tegye, ha az elsődleges kiszolgáló tevékenysége alacsony.

Állandó állapotú műveletek

A PostgreSQL-ügyfélalkalmazások a DB-kiszolgáló nevével csatlakoznak az elsődleges kiszolgálóhoz. Az elsődleges kiszolgáló közvetlenül az alkalmazás olvasását szolgálja ki. Ugyanakkor az alkalmazás csak akkor kap visszaigazolást a véglegesítésekről és az írásokról, ha a naplóadatok az elsődleges kiszolgálón és a készenléti replikán is megmaradnak. Ennek a plusz oda-visszaútnak köszönhetően az alkalmazások megnövekedett késésre számíthatnak az írások és véglegesítések esetében. A portálon figyelheti a magas rendelkezésre állás állapotát.

1. Az ügyfelek a rugalmas kiszolgálóhoz csatlakoznak, és írási műveleteket hajtanak végre.
2. A módosítások replikálódnak a készenléti helyre.
3. Az elsődleges kap visszaigazolást.
4. Az írásokat és a véglegesítéseket a rendszer nyugtázza.

Magas rendelkezésre állású kiszolgálók időponthoz kötött visszaállítása

A magas rendelkezésre állású rugalmas kiszolgálók esetében a rendszer valós időben replikálja a naplóadatokat a készenléti kiszolgálóra. Az elsődleges kiszolgálón jelentkező felhasználói hibák – például egy tábla véletlen elvetése vagy helytelen adatfrissítések – replikálódnak a készenléti replikára. Így nem használhatja a készenléti üzemmódot az ilyen logikai hibák utáni helyreállításhoz. Az ilyen hibákból való helyreállításhoz időhöz kötött visszaállítást kell végrehajtania a biztonsági másolatból. A rugalmas kiszolgáló időponthoz kötött visszaállítási funkciójának használatával visszaállíthatja a hiba bekövetkezése előtti időpontot. Az új adatbázis-kiszolgáló zonális (egyzónás) rugalmas kiszolgálóként lesz visszaállítva, a magas rendelkezésre állással konfigurált adatbázisok új, felhasználó által megadott kiszolgálónevével. A visszaállított kiszolgálót több használati esetre is használhatja:

• Használja a visszaállított kiszolgálót éles környezetben, és igény szerint engedélyezze a magas rendelkezésre állást készenléti replikával ugyanazon a zónán vagy egy másik régión belül.

• Ha vissza szeretne állítani egy objektumot, exportálja a visszaállított adatbázis-kiszolgálóról, és importálja az éles adatbázis-kiszolgálóra.

• Ha tesztelési és fejlesztési célokra szeretné klónozni az adatbázis-kiszolgálót, vagy bármilyen más célra szeretné visszaállítani, elvégezheti az időponthoz kötött visszaállítást.

Egy rugalmas kiszolgáló időponthoz kötött visszaállításáról a Rugalmas kiszolgáló időponthoz kötött visszaállítása című témakörben olvashat.

Rendszerátváltás támogatása

Tervezett átállás

A tervezett állásidő-események közé tartozik az Azure ütemezett rendszeres szoftverfrissítések és alverziófrissítések. A tervezett feladatátvétellel az elsődleges kiszolgálót egy előnyben részesített rendelkezésre állási zónába is visszaadhatja. A magas rendelkezésre állás konfigurálásakor ezek a műveletek először a készenléti replikára vonatkoznak, miközben az alkalmazások továbbra is hozzáférnek az elsődleges kiszolgálóhoz. Miután a folyamat frissíti a készenléti replikát, kiüríti az elsődleges kiszolgáló kapcsolatait, és elindít egy feladatátvételt, amely aktiválja a készenléti replikát elsődleges kiszolgálóként ugyanazzal az adatbázis-kiszolgálónévvel. Az ügyfélalkalmazások ugyanazzal az adatbázis-kiszolgálónévvel csatlakoznak az új elsődleges kiszolgálóhoz, és folytathatják a műveleteket. A folyamat egy új készenléti kiszolgálót hoz létre ugyanabban a zónában, mint a régi elsődleges.

Jótanács

Ha zónaredundáns rugalmas kiszolgálóval rendelkezik, egy tervezett feladatátvétellel is visszaállíthatja az elsődleges kiszolgálót egy előnyben részesített rendelkezésre állási zónába, csökkentve az állásidőt. Előfordulhat például, hogy az elsődleges kiszolgáló más rendelkezésre állási zónában van, mint az alkalmazás a nem tervezett feladatátvétel után. A tervezett feladatátvételi folyamat visszaviszi az elsődleges kiszolgálót az eredeti zónába, és létrehoz egy új készenléti kiszolgálót ugyanabban a zónában, mint a régi elsődleges.

Más, felhasználó által kezdeményezett műveletek, például a méretezési számítás vagy a skálázási tárterület esetében a folyamat először a készenléti, majd az elsődleges területen alkalmazza a módosításokat. A szolgáltatás jelenleg nem vált át a készenléti rendszerre. Ezért amíg a méretezési művelet az elsődleges kiszolgálón fut, az alkalmazások rövid állásidőt tapasztalnak.

Ezzel a funkcióval csökkentett leállási idővel is átveheti a feladatokat a tartalék szerverre. Előfordulhat például, hogy az elsődleges kiszolgáló más rendelkezésre állási zónában van, mint az alkalmazás a nem tervezett feladatátvétel után. Az elsődleges szervert vissza szeretné helyezni az előző zónába az alkalmazással való együtt elhelyezés érdekében.

A funkció végrehajtásakor a folyamat először előkészíti a készenléti kiszolgálót, hogy biztosan elkapja a legutóbbi tranzakciókat, így az alkalmazás folytathatja az olvasási és írási műveleteket. A folyamat aktiválja a készenléti folyamatot, és megszakítja az elsődlegessel kapcsolatos kapcsolatokat. Az alkalmazás továbbra is írhat az elsődlegesre, miközben a folyamat létrehoz egy új készenléti kiszolgálót a háttérben. Az alábbi táblázat a tervezett feladatátvétel lépéseit ismerteti:

Step	Leírás	Várható az alkalmazás leállása?
1	Várja meg, amíg a készenléti kiszolgáló felzárkózni fog az elsődleges kiszolgálóhoz.	No
2	A belső figyelési rendszer elindítja a feladatátvételi munkafolyamatot.	No
3	Az alkalmazás írása le lesz tiltva, ha a készenléti kiszolgáló közel van az elsődleges naplósorozatszámhoz (LSN).	Igen
4	A készenléti kiszolgálót a rendszer független kiszolgálóként előlépteti.	Igen
5	A DNS-rekord frissül az új készenléti kiszolgáló IP-címével.	Igen
6	Az alkalmazás újracsatlakozik, és az új elsődleges kiszolgálóval folytatja az olvasási/írási műveletet.	No
7	Létrejön egy új készenléti kiszolgáló. Zónaredundáns kiszolgálók esetén az új kiszolgáló egy másik zónában található.	No
8	A készenléti kiszolgáló megkezdi azoknak a naplóknak a helyreállítását (Azure Blobból), amelyeket a létrehozása során elmulasztott.	No
9	Állandó állapot jön létre az elsődleges és a készenléti kiszolgáló között.	No
10	A tervezett feladatátvételi folyamat befejeződött.	No

Az alkalmazás leállása a 3. lépésben kezdődik, és az 5. lépés után folytathatja a működését. A többi lépés a háttérben történik anélkül, hogy hatással van az alkalmazás írására és véglegesítésére.

Jótanács

Rugalmas kiszolgálóval igény szerint ütemezhet Azure által kezdeményezett karbantartási tevékenységeket, ha kiválaszt egy 60 perces ablakot a kívánt napon, amikor az adatbázisokban végzett tevékenységek várhatóan alacsonyak lesznek. Azure karbantartási feladatok, például a javítások vagy az alverziófrissítések az adott időszakban történnek. Ha nem egyéni ablakot választ, a rendszer helyi idő szerint 11:00 és 19:00 óra között foglal le egy egyórás ablakot a kiszolgáló számára. Ezek a Azure által kezdeményezett karbantartási tevékenységek a rendelkezésre állási zónákkal konfigurált rugalmas kiszolgálók készenléti replikáján is elvégezhetők.

A lehetséges tervezett állásidő-események listáját a Tervezett állásidő események című témakörben találja.

Nem tervezett átállás

A nem tervezett állásidők olyan előre nem látható meghibásodások miatt fordulhatnak elő, mint a mögöttes hardverhibák, a hálózatkezelési problémák és a szoftverhibák. Ha a magas rendelkezésre állással konfigurált adatbázis-kiszolgáló váratlanul leáll, a folyamat aktiválja a készenléti replikát, és az ügyfelek folytathatják a műveleteket. Ha nem konfigurálja a magas rendelkezésre állást (HA), és az újraindítási kísérlet meghiúsul, a folyamat automatikusan kiépít egy új adatbázis-kiszolgálót. Bár nem tudja elkerülni a nem tervezett állásidőt, a rugalmas kiszolgáló úgy segít csökkenteni az állásidőt, hogy automatikusan végrehajtja a helyreállítási műveleteket emberi beavatkozás nélkül.

A nem tervezett feladatátvételekkel és állásidőkkel kapcsolatos információkért , beleértve a lehetséges forgatókönyveket is, tekintse meg a nem tervezett állásidő-csökkentést.

Kényszerített feladatátvétel

A feladatátvételi teszteléshez használjon kényszerített feladatátvételt egy nem tervezett üzemkimaradási forgatókönyv szimulálásához az éles számítási feladat futtatása közben. Nyomon követheti az alkalmazás leállási idejét. Kényszerített feladatátvételt is használhat, ha az elsődleges kiszolgáló nem válaszol.

A kényszerített feladatátvétel leállítja az elsődleges kiszolgálót, és elindítja azt a feladatátvételi munkafolyamatot, amelyben a készenléti előléptetési műveletet végrehajtják. Amint a készenléti szerver befejezi a helyreállítási folyamatot az utolsó véglegesített adatokig, előléptetik elsődleges szerverré. A DNS-rekordok frissülnek, és az alkalmazás csatlakozhat az előléptetett elsődleges kiszolgálóhoz. Az alkalmazás továbbra is írhat az elsődlegesre, miközben új készenléti kiszolgáló jön létre a háttérben, ami nem befolyásolja az üzemidőt.

Az alábbi táblázat a kényszerített feladatátvétel lépéseit ismerteti:

Step	Leírás	Várható az alkalmazás leállása?
1	Az elsődleges kiszolgáló röviddel a feladatátvételi kérelem fogadása után leáll.	Igen
2	Az alkalmazás állásidőt tapasztal az elsődleges kiszolgáló leállása esetén.	Igen
3	A belső figyelési rendszer észleli a hibát, és feladatátvételt kezdeményez a készenléti kiszolgálóra.	Igen
4	A készenléti kiszolgáló helyreállítási módba lép, mielőtt teljes mértékben előléptetik őket független kiszolgálóként.	Igen
5	A feladatátvételi folyamat megvárja a készenléti helyreállítás befejezését.	Igen
6	A kiszolgáló üzembe helyezése után a folyamat ugyanazzal a gazdagépnévvel frissíti a DNS-rekordot, de a készenléti ip-címet használja.	Igen
7	Az alkalmazás újracsatlakozhat az új elsődleges kiszolgálóhoz, és folytathatja a műveletet.	No
8	Létrejön egy készenléti kiszolgáló az előnyben részesített zónában.	No
9	A készenléti kiszolgáló megkezdi azoknak a naplóknak a helyreállítását (Azure Blobból), amelyeket a létrehozása során elmulasztott.	No
10	Állandó állapot jön létre az elsődleges és a készenléti kiszolgáló között.	No
11	A kényszerített feladatátvételi folyamat befejeződött.	No

Az alkalmazás állásideje az 1. lépés után kezdődik, és folytatódik, amíg a 6. lépés be nem fejeződik. A fennmaradó lépések a háttérben futnak, az alkalmazás írási és véglegesítési folyamatának befolyásolása nélkül.

Fontos

A végpontok közötti feladatátvételi folyamat magában foglalja a (a) a készenléti kiszolgálónak az elsődleges hiba utáni feladatátvételt, és (b) az új készenléti kiszolgáló állandó állapotban történő létrehozását. Mivel az alkalmazás állásidőt von maga után, amíg a feladatátvétel a készenléti állapotba nem fejeződik be, az állásidőt az alkalmazás/ügyfél szempontjából mérje meg a teljes feladatátvételi folyamat helyett.

Megfontolandó szempontok a kényszerített feladatátvételek végrehajtásakor

• A teljes teljes üzemidő hosszabb lehet, mint az alkalmazás által tapasztalt tényleges állásidő.

  Fontos

  Mindig tartsa szem előtt az állásidőt az alkalmazás nézőpontjából!

• Ne végezzen azonnali, egymás utáni feladatátvételt. Várjon legalább 15–20 percet a feladatátvételek között, hogy az új készenléti kiszolgáló teljesen létre lehessen hozni.

• Alacsony tevékenységű időszakban kényszerített feladatátvételt hajthat végre az állásidő csökkentése érdekében.

Ajánlott eljárások a PostgreSQL-statisztikák feladatátvétel utáni statisztikáihoz

A PostgreSQL-feladatátvételt követően az optimális adatbázis-teljesítmény fenntartása magában foglalja a pg_statistic és a pg_stat_* nézetek különböző szerepköreinek megértését. A pg_statistic tábla optimalizáló statisztikákat tárol, amelyek kulcsfontosságúak a lekérdezéstervező számára. Ezek a statisztikák tartalmazzák a táblákon belüli adateloszlásokat, és a feladatátvétel után is érintetlenek maradnak, biztosítva, hogy a lekérdezéstervező továbbra is hatékonyan optimalizálhassa a lekérdezések végrehajtását pontos, előzményadatok alapján.

Ezzel szemben a pg_stat_* nézetek, a futtatási idő alatti tevékenységi statisztikái, például a vizsgálatok száma, az olvasott sorok és a frissítések száma, a memóriában vannak tárolva, és átálláskor alaphelyzetbe állnak. Ilyen például a pg_stat_user_tablesfelhasználó által definiált táblák tevékenységeinek nyomon követése. Ez az alaphelyzetbe állítás pontosan tükrözi az új elsődleges szerver működési állapotát, de azt is jelenti, hogy elvesznek azok a korábbi tevékenységi metrikák, amelyek tájékoztathatják az autovacuum folyamatot és egyéb működési hatékonyságokat.

Ezt a különbséget figyelembe véve fontolja meg a(z) ANALYZE futtatását egy PostgreSQL-es feladatátvétel után. Ez a művelet friss vákuumtevékenység-statisztikákkal frissíti az pg_stat_* adatokat (például pg_stat_user_tables) az autovacuum folyamatának segítése révén, ami biztosítja, hogy az adatbázis teljesítménye optimális maradjon az új szerepkörében. Ez a proaktív lépés áthidalja az alapvető optimalizálási statisztikák megőrzése és a tevékenységmetrikák frissítése közötti szakadékot, hogy igazodjon az adatbázis jelenlegi állapotához.

Logikai replikáció támogatása a HA használatával

Ha logikai replikációt vagy logikai dekódolást használ magas rendelkezésre állású (HA) használatával Azure Database for PostgreSQL rugalmas kiszolgálón, fontos megérteni, hogyan viselkednek a replikációs pontok a feladatátvétel során, és hogyan biztosítható a replikáció folytonossága.

PostgreSQL 16 és korábbi verziók

A PostgreSQL 16-os és korábbi verzióiban a logikai replikációs pontok nem maradnak automatikusan a készenléti kiszolgálón a feladatátvétel után. A logikai replikáció feladatátvételi szinten való fenntartásához a következőt kell tennie:

• A pg_failover_slots bővítmény engedélyezése
• Konfigurálja a szükséges beállításokat, például:
  • hot_standby_feedback = on

Ezen konfigurációk nélkül előfordulhat, hogy a logikai replikáció leáll a feladatátvétel után, mert a replikációs pontok nem érhetők el az új elsődlegesen.

PostgreSQL 17 és újabb verziók

A PostgreSQL 17-től kezdve a logikai replikációs pont szinkronizálása natív módon támogatott. Ha megfelelően konfigurálja ezt a funkciót, a rendszer automatikusan szinkronizálja a replikációs pontokat a készenléti kiszolgálóval.

A viselkedés engedélyezéséhez:

• Állítsa be sync_replication_slots-t on-re.
• Állítsa be hot_standby_feedback-t on-re.

Ezekkel a beállításokkal a rendszer megőrzi a logikai replikációs helyeket a feladatátvétel során, és a replikáció bővítmények nélkül is folytatódhat. További részletekért tekintse meg a PG_Failover_Slots bővítmény dokumentációját.

Fontos tényezők

• Az elsődleges kiszolgálón kezelheti a logikai replikációs helyeket, de a készenléti kiszolgálónak is rendelkeznie kell ezekkel a tárolóhelyekkel, hogy a logikai replikáció a HA feladatátvétel után is folytatódjon.
• A rendszernézetek (például lekérdezés pg_replication_slots) csak az elsődleges állapotot mutatják, és nem ellenőrzik, hogy a helyek szinkronban vannak-e a készenléti állapottal. A rendszer egészségesnek tűnhet az elsődleges tárolón, de a logikai replikációs helyek készenléti állapotban való megőrzéséhez még nem biztos, hogy készen áll a feladatátvételre.

A logikai replikáció feladatátvételi készenlétének figyelése

A feladatátvételi készültség ellenőrzéséhez használja a Azure Monitor metrikát logical_replication_slot_sync_status (előzetes verzió).

Fontos

A metrika kibocsátásához győződjön meg arról, hogy a paraméter metrics.collector_database_activity be van állítva on.

Ez a metrika azt jelzi, hogy a logikai replikációs pontok szinkronizálva vannak-e a ha elsődleges és a készenléti állapot között:

• 1 azt jelzi, hogy a helyek az elsődleges és a készenléti rendszer között szinkronizálva vannak.
• 0 azt jelzi, hogy a slotok nincsenek szinkronizálva a tartalék szerveren.

Ha a metrika értéke 0, előfordulhat, hogy a logikai replikáció továbbra is működik az aktuális elsődlegesen, de feladatátvétel után nem folytatódhat. A logikai replikációs metrikák teljes listájáért tekintse meg a logikai replikáció monitorozását.

Megjegyzés:

Ez a szinkronizálási állapot a HA-csomópontok állapotát tükrözi, és nem ellenőrizhető csak az elsődleges rendszernézetek használatával. A metrika riasztásokkal való használatával észlelheti, hogy a logikai replikáció nem áll készen a feladatátvételre, különösen a tervezett karbantartási vagy feladatátvételi események előtt. Fontolja meg a riasztások konfigurálását, ha a metrika tartós ideig 0 marad.