Magas rendelkezésre állás (megbízhatóság) az Azure Database for PostgreSQL-ben

Ez a cikk az Azure Database for PostgreSQL magas rendelkezésre állását ismerteti, amely magában foglalja a rendelkezésre állási zónákat , a régiók közötti helyreállítást és az üzletmenet folytonosságát. Az Azure-beli megbízhatóság részletesebb áttekintéséhez tekintse meg az Azure megbízhatóságát.

Az Azure Database for PostgreSQL támogatja a magas rendelkezésre állást azáltal, hogy fizikailag elkülönített elsődleges és készenléti replikákat biztosít ugyanazon rendelkezésre állási zónán belül (zóna) vagy rendelkezésre állási zónák között (zónaredundáns). Ez a magas rendelkezésre állású modell úgy lett kialakítva, 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 az adatok szinkron módon le lesznek kötelezve az elsődleges és a készenléti kiszolgálókra is. A modell úgy lett kialakítva, hogy az adatbázis ne váljon egyetlen meghibásodási ponttá a szoftverarchitektúrában. A magas rendelkezésre állásról és a rendelkezésre állási zónák támogatásáról további információt a rendelkezésre állási zónák támogatásával kapcsolatban talál.

Rendelkezésre állási zóna támogatása

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

Az Azure Database for PostgreSQL a zónaredundáns és a zónaszintű modelleket is támogatja 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:

• Kitörhető számítási szint

• Régiók egyzónás rendelkezésre állással

• Zonal. 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 zónatelepítési lehetőség minden Olyan 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.

Zonális rugalmasság konfigurálása a portálon

A magas rendelkezésre állás (HA) kétféleképpen konfigurálható: zónaredundáns HA, amely a készenléti kiszolgálót egy másik rendelkezésre állási zónába helyezi a maximális rugalmasság érdekében, vagy ugyanaz a zóna 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.

A konfiguráció egyszerűsítése és a zonális rugalmasság biztosítása érdekében a portál egy Zonal Resiliency 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 alábbi képen kiemelve) az azonos zónás 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, az Azure értesíti Önt, hogy a PITR vagy az olvasási replikák használatával zónaredundáns HA-konfigurációra migrálhassa. 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 ugyanahhoz a zónához, biztosítva, hogy a számítási feladatok végül manuális beavatkozás nélkül teljes zónarezisztenciát érjenek el.

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

• A készenléti replika ugyanabban a virtuálisgép-konfigurációban van üzembe helyezve – beleértve a virtuális magokat, a tárterületet és a hálózati beállításokat –, mint az elsődleges kiszolgáló.

• A rendelkezésre állási zóna támogatása meglévő adatbázis-kiszolgálóhoz is hozzáadható.

• A magas rendelkezésre állás letiltásával eltávolíthatja a készenléti replikát.

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

• A leállítási, indítási és újraindítási műveletek egyidejűleg az elsődleges és a készenléti adatbázis-kiszolgálókon is végbemennek.

• Zónaredundáns és zónaalapú modellekben 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. Ha a régió támogatja a rendelkezésre állási zónákat, a biztonsági mentési adatok zónaredundáns tárolóban (ZRS) vannak tárolva. Azokban a régiókban, amelyek nem támogatják a rendelkezésre állási zónákat, a biztonsági mentési adatok tárolása helyi redundáns tárolóban (LRS) történik.

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

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

• Újraindíthatja a kiszolgálót a statikus kiszolgálóparaméterek változásainak felvételéhez.

• 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 készenléti állapotot elsődlegesre előléptetik, hogy a számítási feladatok folytatódhassanak, miközben a karbantartási feladatokat a fennmaradó csomóponton alkalmazzák.

Megjegyzés:

A magas rendelkezésre állás megfelelő működéséhez konfigurálja a max_replication_slots és a max_wal_senders szerver paraméterértékeit. 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.

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

Az Azure Database for PostgreSQL magas rendelkezésre állású állapotmonitorozása 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ó az 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 HA állapotainak konfigurálásáról és értelmezéséről részletes útmutatót az Azure Database for PostgreSQL magas rendelkezésre állású állapotmonitorozásában talál.

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

• A készenléti kiszolgálóra történő szinkron replikáció miatt, különösen zónaredundáns konfiguráció esetén az alkalmazások magas írási és véglegesítési késést tapasztalhatnak.

• A készenléti replika 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. A szerver jelenleg nem végez feladatátvételt a tervezett műveletekhez.

• Ha logikai dekódolást vagy logikai replikációt konfigurál egy HA-kompatibilis rugalmas kiszolgálón:

  • A PostgreSQL 16-os és korábbi verzióiban a logikai replikációs pontok alapértelmezés szerint nem maradnak meg a készenléti kiszolgálón a feladatátvétel után.
  • Ahhoz, hogy a logikai replikáció a feladatátvétel után is működjön, engedélyeznie kell a pg_failover_slots bővítményt, és konfigurálnia kell az olyan támogató beállításokat, mint a hot_standby_feedback = on.
  • A PostgreSQL 17-től kezdve a pontszinkronizálás natív módon támogatott. Ha engedélyezi a megfelelő PostgreSQL-konfigurációkat (sync_replication_slots, hot_standby_feedback), a logikai replikációs pontok automatikusan megmaradnak a feladatátvétel után, és nincs szükség bővítményre.
  • A telepítési lépésekről és előfeltételekről a PG_Failover_Slots bővítmény dokumentációjában talál további információt.

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

SLA

• A Zonal modell körülbelül 99,95% üzemidőt kínál az SLA követelményeknek megfelelően.

• A zóna-redundancia-modell körülbelül 99,99%-os üzemidőt biztosít egy SLA számára.

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

Ha tudni szeretné, hogyan hozhat létre Azure Database for PostgreSQL-et magas rendelkezésre állási zónákkal, olvassa el a rövid útmutatót: Azure Database for PostgreSQL létrehozása az Azure Portalon.

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ú ö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ó 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é tartoznak az Azure ütemezett rendszeres szoftverfrissítései és az 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.

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 lehetséges az átváltás a készenléti kiszolgálóra csökkentett állásidővel. 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.	Nem
2	A belső figyelési rendszer elindítja a feladatátvételi munkafolyamatot.	Nem
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.	Nem
7	Létrejön egy új készenléti kiszolgáló egy másik zónában.	Nem
8	A készenléti kiszolgáló megkezdi azoknak a naplóknak a helyreállítását (az Azure Blobból), amelyeket a létrehozása során kihagyott.	Nem
9	Állandó állapot jön létre az elsődleges és a készenléti kiszolgáló között.	Nem
10	A tervezett feladatátvételi folyamat befejeződött.	Nem

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 ütemezheti az Azure által kezdeményezett karbantartási tevékenységeket úgy, hogy kiválaszt egy 60 perces időszakot a kívánt napon, amikor az adatbázisokban végzett tevékenységek várhatóan alacsonyak lesznek. Az Azure karbantartási feladatai, 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 az 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 előre nem látható fennakadások, például a mögöttes hardverhibák, a hálózatkezelési problémák és a szoftverhibák miatt fordulhatnak elő. 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 a nem tervezett állásidőt nem lehet elkerülni, 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.

Átállás-tesztelés (kényszerített átállás)

Kényszerített feladatátvétel esetén szimulálhat egy nem tervezett üzemszüneti forgatókönyvet az éles munkaterhelés futtatása közben, és megfigyelheti 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.	Nem
8	Létrejön egy készenléti kiszolgáló az előnyben részesített zónában.	Nem
9	A készenléti kiszolgáló megkezdi azoknak a naplóknak a helyreállítását (az Azure Blobból), amelyeket a létrehozása során kihagyott.	Nem
10	Állandó állapot jön létre az elsődleges és a készenléti kiszolgáló között.	Nem
11	A kényszerített feladatátvételi folyamat befejeződött.	Nem

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 többi lépés a háttérben fut anélkül, hogy hatással van az alkalmazás írására és véglegesítésére.

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étele után az optimális adatbázis-teljesítmény fenntartása magában foglalja a pg_statistic és a pg_stat_* táblák 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_* táblák, amelyek tevékenységstatisztikákat, például a vizsgálatok számát, az olvasott sorokat és a frissítéseket rögzítik, átálláskor alaphelyzetbe állnak. Ilyen tábla például a pg_stat_user_tablesfelhasználó által definiált táblák tevékenységeit nyomon követi. 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, futtassa a ANALYZE parancsot a PostgreSQL-átállás után. Ez a művelet frissíti a pg_stat_* táblákat, például pg_stat_user_tablesfriss tevékenységstatisztikákkal, segítve az autovacuum-folyamatot, és 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.

Zónacsökkentési élmény

Zonal: Zónaszintű hiba utáni helyreállításhoz 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őponthoz kötött visszaá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óban című témakörben talál.

Zónaredundáns: A rugalmas kiszolgáló 60–120 másodpercen belül automatikusan, nulla adatvesztéssel automatikusan áttér a készenléti kiszolgálóra.

Rendelkezésre állási zónák nélküli konfigurációk

Bár ez nem ajánlott, konfigurálhatja a rugalmas kiszolgálót anélkül, hogy engedélyezve lenne 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, zónaredundáns biztonsági mentéssel (azokban a régiókban, ahol támogatott), valamint beépített kiszolgálói rugalmassággal, hogy automatikusan újraindítsa az összeomlott kiszolgálót, és áthelyezhesse a kiszolgálót egy másik fizikai csomópontra. Ez a konfiguráció 99,9-%üzemidős SLA-t kínál. 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ó.

Régiók közötti vészhelyreállítás és üzletmenet-folytonosság

Ha régiószintű katasztrófa történik, az Azure egy másik régió használatával védelmet nyújthat a regionális vagy nagy földrajzi katasztrófák ellen vészhelyreállítással. További információ az Azure vészhelyreállítási architektúrájáról: Azure–Azure vészhelyreállítási architektúra.

A rugalmas kiszolgáló olyan funkciókat biztosít, amelyek védik az adatokat, és csökkentik a kritikus fontosságú adatbázisok állásidejét a tervezett és nem tervezett leállási események során. A robusztus rugalmasságot és rendelkezésre állást biztosító Azure-infrastruktúrára épülő rugalmas kiszolgáló olyan üzletmenet-folytonossági funkciókat kínál, amelyek hibavédelmet biztosítanak, kezelik a helyreállítási idő követelményeit, és csökkentik az adatveszteség-kitettséget. Az alkalmazások kialakításakor vegye figyelembe az állásidő-tűrést – a helyreállítási idő célkitűzését (RTO) és az adatvesztés expozícióját – a helyreállítási pont célkitűzését (RPO). Az üzleti szempontból kritikus adatbázis például szigorúbb üzemidőt igényel, mint egy tesztadatbázis.

Vészhelyreállítás többrégiós földrajzi területen

Georedundáns biztonsági mentés és visszaállítás

A georedundáns biztonsági mentés és visszaállítás lehetővé teszi a kiszolgáló visszaállítását egy másik régióban, ha katasztrófa történik. Emellett legalább 99,999999999999999999999999 százalékos (16 kilences) tartósságot biztosít egy év alatt a biztonsági mentési objektumok számára.

A georedundáns biztonsági mentést csak a kiszolgáló létrehozásakor konfigurálhatja. Ha georedundáns biztonsági mentéssel konfigurálja a kiszolgálót, a rendszer a biztonsági mentési adatokat és a tranzakciónaplókat aszinkron módon másolja a párosított régióba a tárreplikálással.

További információ a georedundáns biztonsági mentésről és visszaállításról: georedundáns biztonsági mentés és visszaállítás.

Olvasási másolatok

Régiók közötti olvasási replikákat helyezhet üzembe, hogy megvédje az adatbázisokat a régiószintű hibáktól. Az olvasási replikák a PostgreSQL fizikai replikációs technológiájának használatával aszinkron módon frissülnek, és az elsődleges példányok késését okozhatják. Az általános célú és memóriaoptimalizált számítási szintek támogatják az olvasási replikákat.

További információ a read replica funkcióiról és szempontjairól: Read replicas.

Üzemkimaradás észlelése, értesítés és felügyelet

Ha georedundáns biztonsági mentéssel konfigurálja a kiszolgálót, georedundáns visszaállítást végezhet a párosított régióban. A rendszer új kiszolgálót üzembe helyez és visszaállítja a régióba másolt utolsó elérhető adatokat.

Régióközi olvasásra szánt replikákat is használhat. Ha régióhiba történik, vészhelyreállítási műveletet hajthat végre úgy, hogy átalakítja az olvasási replikát önálló írható-olvasható kiszolgálóvá. Az RPO várhatóan legfeljebb 5 percet vesz igénybe (adatvesztés lehetséges), kivéve, ha súlyos regionális hiba történik, ha az RPO közel lehet a replikáció késéséhez a hiba időpontjában.

További információ a regionális katasztrófa utáni nem tervezett állásidő-csökkentésről és helyreállításról: Nem tervezett állásidő-csökkentés.

Kapcsolódó tartalom

• Az Azure Database for PostgreSQL dokumentációja
• Megbízhatóság az Azure-ban