Magas rendelkezésre állás (megbízhatóság) az Azure Database for PostgreSQL-ben – rugalmas kiszolgáló
A következőkre vonatkozik:
Azure Database for PostgreSQL – Rugalmas kiszolgáló
Ez a cikk az Azure Database for PostgreSQL rugalmas kiszolgáló 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 – Rugalmas kiszolgáló magas rendelkezésre állási támogatást nyújt fizikailag elkülönített elsődleges és készenléti replikák kiépítésével, akár ugyanazon rendelkezésre állási zónán belül (zónaredundáns), akár 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 ne vesszenek el hibák esetén. A modell úgy is 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
Az Azure rendelkezésre állási zónái legalább három fizikailag különálló adatközpont-csoport az egyes Azure-régiókban. Az egyes zónákban lévő adatközpontok független energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Helyi zónahiba esetén a rendelkezésre állási zónák úgy vannak kialakítva, hogy az egy zóna érintettsége esetén a fennmaradó két zóna támogassa a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.
A hibák a szoftver- és hardverhibáktól az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tűzesetek. A hibáktól való tolerancia az Azure-szolgáltatások redundanciával és logikai elkülönítésével érhető el. Az Azure-beli rendelkezésre állási zónákkal kapcsolatos részletesebb információkért tekintse meg a Régiók és a rendelkezésre állási zónák című témakört.
Az Azure rendelkezésre állási zónákkal kompatibilis szolgáltatások a megfelelő megbízhatósági és rugalmassági szintet biztosítják. Ezek kétféleképpen konfigurálhatók. Ezek lehetnek zónaredundánsak, a zónák közötti automatikus replikációval vagy a zónák közötti automatikus replikációval, egy adott zónába rögzített példányokkal. Ezeket a megközelítéseket kombinálhatja is. A zónaredundáns és a zónaredundáns architektúrával kapcsolatos további információkért tekintse meg a rendelkezésre állási zónák és régiók Javaslatok.
Azure Database for PostgreSQL – A rugalmas kiszolgáló 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ának a zónák közötti konfigurálását igényli. 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ó.
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.
Zonal. Ha egyetlen rendelkezésre állási zónán belül szeretné elérni a legmagasabb rendelkezésre állási szintet, de a legalacsonyabb hálózati késéssel szeretné elérni a zónabeli üzemelő példányt, válasszon ki egy zónatelepíté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. Az elsődleges kiszolgáló esetleges megszakadása esetén a kiszolgáló automatikusan át lesz állítva a készenléti replikára.
Feljegyzés
A zóna- és zónaredundáns üzemi modellek is architekturálisan ugyanúgy viselkednek. A következő szakaszok különböző vitái mindkettőre vonatkoznak, kivéve, ha másként nem szólnak hozzá.
Előfeltételek
Zónaredundancia:
A zónaredundancia beállítás csak a rendelkezésre állási zónákat támogató régiókban érhető el.
A zónaredundancia nem támogatott a következő célokra:
- Azure Database for PostgreSQL – Egykiszolgálós termékváltozat.
- Kipukkanható számítási szint.
- Egyzónás rendelkezésre állású régiók.
Zonal:
- A zónatelepítési lehetőség minden Olyan Azure-régióban elérhető, ahol rugalmas kiszolgálót helyezhet üzembe.
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árolást é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 automatikus biztonsági mentések rendszeres időközönként az elsődleges adatbázis-kiszolgálóról lesznek végrehajtva. Ugyanakkor a tranzakciónaplók folyamatosan archiválva lesznek a tartalék replikából származó 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.
Lehetőség van a kiszolgáló újraindítására a statikus kiszolgálóparaméter-változások szinkronizálása érdekében.
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, és az állásidő csökkentése érdekében a rendszer előlépteti a készenléti állapotot az elsődlegesre, hogy a számítási feladatok tovább tudjanak maradni, míg a karbantartási feladatok a fennmaradó csomóponton lesznek alkalmazva.
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óval, 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 feladatától és tevékenységétől függően a feladatátvételi folyamat több mint 120 másodpercet is igénybe vehet, mivel a készenléti replikában végzett helyreállítás előléptethető.
A készenléti kiszolgáló általában 40 MB/s sebességgel helyreállítja a WAL-fájlokat. 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.
A rendelkezésre állási zónák konfigurálása némi késést okoz az írásokhoz és a véglegesítésekhez, de nem befolyásolja a lekérdezések olvasását. A teljesítményre gyakorolt hatása a számítási feladattól függ. Általánosságban az írásokra és véglegesítésekre gyakorolt hatása 20–30%-os.
Az elsődleges adatbázis-kiszolgáló újraindítása szintén újraindítja a készenléti replikát.
Az extra készenléti állapot konfigurálása nem támogatott.
Az ügyfél által kezdeményezett felügyeleti feladatok konfigurálása nem ütemezhető a felügyelt karbantartási időszak alatt.
Az olyan tervezett események, mint a méretezési számítástechnika és a skálázási tárterület, először a készenléti, majd az elsődleges kiszolgálón történnek. A kiszolgáló jelenleg nem végez feladatátvételt ezekhez a tervezett műveletekhez.
Ha a logikai dekódolás vagy a logikai replikáció rendelkezésre állásra konfigurált rugalmas kiszolgálóval van konfigurálva, a készenléti kiszolgálóra történő feladatátvétel esetén a logikai replikációs pontok nem lesznek átmásolva a készenléti kiszolgálóra. A logikai replikációs pontok fenntartása és a feladatátvétel utáni adatkonzisztenciának biztosítása érdekében ajánlott a PG Feladatátvevő pontok bővítmény használata. A bővítmény engedélyezéséről további információt a dokumentációban talál.
A rendelkezésre állási zónák privát (VNET) és nyilvános hozzáférés közötti konfigurálása privát végpontokkal nem támogatott. A rendelkezésre állási zónákat a 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ák csak egyetlen régión belül vannak konfigurálva. A rendelkezésre állási zónák nem konfigurálhatók régiók között.
SLA
A zonal modell 99,95%-os üzemidejű SLA-t kínál.
A zónaredundáns modell 99,99%-os üzemidejű SLA-t kínál.
Azure Database for PostgreSQL létrehozása – Rugalmas kiszolgáló, amelyen engedélyezve van a rendelkezésre állási zóna
Ha szeretné megtudni, hogyan hozhat létre rugalmas Azure Database for PostgreSQL-kiszolgálót a rendelkezésre állási zónákkal való magas rendelkezésre álláshoz, olvassa el a rövid útmutatót: Azure Database for PostgreSQL – Rugalmas kiszolgáló 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 Magas rendelkezésre állás kezelése a rugalmas kiszolgálón című témakört.
Magas rendelkezésre állású összetevők és munkafolyamat
Tranzakció befejezése
Az alkalmazástranzakció által aktivált írásokat és véglegesítéseket a rendszer először naplózza a WAL-ba az elsődleges kiszolgálón. Ezeket a rendszer ezután a Postgres streamelési protokoll használatával streameli a készenléti kiszolgálóra. Miután a naplók megmaradnak a készenléti kiszolgáló tárolójában, a rendszer nyugtázza az elsődleges kiszolgálót az írás befejezéséhez. Az alkalmazás csak ezt követően erősíti meg a tranzakció véglegesítését. Ez a további oda-visszaút nagyobb késést biztosít az alkalmazás számára. 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ó véglegesen helyreállítási módban van, amíg elő nem lépteti.
Állapot-ellenőrzés
A rugalmas kiszolgálóállapot-monitorozás rendszeresen ellenőrzi az elsődleges és a készenléti állapotot 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 adatponton alapul a hamis pozitív helyzetek elkerülése érdekében.
Feladatátvételi 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ó futtatja a helyreállítást, mielőtt előléptetik elsődlegesként, és megnyílik olvasási/írási célokra. 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, és megfelelő műveleteket hajt végre a problémák elhárítá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:
| Állapot | Leírás |
|---|---|
| Inicializálása | Ú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. |
| Feladatátvétel | Az adatbázis-kiszolgáló folyamatban van a készenléti állapotba történő feladatátvétel során. |
| 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. |
Feljegyzés
A magas rendelkezésre állást a kiszolgáló létrehozásakor vagy később is engedélyezheti. Ha a létrehozás utáni szakaszban engedélyezi vagy letiltja a magas rendelkezésre állást, ajánlott alacsony elsődleges kiszolgálói tevékenység esetén is üzemelni.
Állandó állapotú műveletek
A PostgreSQL-ügyfélalkalmazások a DB-kiszolgáló nevével csatlakoznak az elsődleges kiszolgálóhoz. Az alkalmazásolvasások közvetlenül az elsődleges kiszolgálóról lesznek kiszolgálva. Ugyanakkor a véglegesítések és írások csak akkor lesznek megerősítve az alkalmazás számára, 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.
- Az ügyfelek a rugalmas kiszolgálóhoz csatlakoznak, és írási műveleteket hajtanak végre.
- A rendszer replikálja a módosításokat a készenléti helyre.
- Az elsődleges kap egy visszaigazolást.
- Az írások/véglegesítések nyugtázva vannak.
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. Ezért nem használhat készenléti állapotot az ilyen logikai hibák utáni helyreállításhoz. Az ilyen hibákból való helyreállításhoz időponthoz 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á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 néhány használati esetre használhatja:
Használhatja a visszaállított kiszolgálót éles környezetben, és igény szerint engedélyezheti 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.
A rugalmas kiszolgálók időponthoz kötött visszaállításának módjáról a rugalmas kiszolgáló időponthoz kötött visszaállítása című témakörben olvashat.
Feladatátvételi támogatás
Tervezett feladatátvétel
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. Ha magas rendelkezésre állásban van konfigurálva, ezek a műveletek először a készenléti replikára lesznek alkalmazva, miközben az alkalmazások továbbra is hozzáférnek az elsődleges kiszolgálóhoz. A készenléti replika frissítése után a rendszer 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, hogy az elsődleges legyen ugyanazzal az adatbázis-kiszolgálónévvel. Az ügyfélalkalmazásoknak ugyanazzal az adatbázis-kiszolgálónévvel kell újracsatlakozniuk az új elsődleges kiszolgálóhoz, és folytatniuk kell a műveleteket. A rendszer 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 rendszer először a készenléti állapotra alkalmazza a módosításokat, majd az elsődlegest. A szolgáltatás jelenleg nem kerül át a készenléti állapotba, ezért amíg a méretezési műveletet az elsődleges kiszolgálón hajtják végre, az alkalmazások rövid állásidőt tapasztalnak.
Ezzel a funkcióval csökkentett állásidővel is feladatátvételt végezhet a készenléti kiszolgálóra. Előfordulhat például, hogy az elsődleges egy másik rendelkezésre állási zónában van, mint az alkalmazás, nem tervezett feladatátvétel után. Az elsődleges kiszolgálót vissza szeretné helyezni az előző zónába az alkalmazással való közös elhelyezéshez.
A funkció végrehajtásakor a készenléti kiszolgáló először készen áll arra, hogy biztosan felzárkozza a legutóbbi tranzakciókhoz, így az alkalmazás továbbra is olvasási/írási műveleteket hajthat végre. A készenléti állapot ekkor előléptetve megszakad, és az elsődleges kapcsolat megszakad. 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. A tervezett feladatátvétel lépései a következők:
| Lépés | Leírás | Alkalmazás állásideje várható? |
|---|---|---|
| 0 | Várja meg, amíg a készenléti kiszolgáló felzárkózott 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 újracsatlakoztathatja és folytathatja az olvasást/írást az új elsődlegessel. | 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 állásideje a 3. lépésnél kezdődik, és folytathatja a műveletet az 5. lépés után. 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.
Tipp.
Rugalmas kiszolgálóval igény szerint ütemezheti az Azure által kezdeményezett karbantartási tevékenységeket, ha kiválaszt egy 60 perces időszakot egy olyan napon, amikor az adatbázisokban a 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 lefoglalt egyablakos rendszert választ ki a kiszolgálóhoz. 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 feladatátvétel
A nem tervezett állásidők olyan előre nem látható fennakadá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 készenléti replika aktiválódik, és az ügyfelek folytathatják a műveleteket. Ha nincs magas rendelkezésre állással (HA) konfigurálva, akkor ha az újraindítási kísérlet meghiúsul, a rendszer automatikusan üzembe helyezi az új adatbázis-kiszolgálót. Bár a nem tervezett állásidőt nem lehet elkerülni, a rugalmas kiszolgáló segít az állásidő csökkentésében azáltal, 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.
Feladatátvételi tesztek (kényszerített feladatátvétel)
Kényszerített feladatátvétel esetén szimulálhat egy nem tervezett üzemkimaradási forgatókönyvet az éles számítási feladat futtatásakor, és megfigyelheti az alkalmazás állásidejé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. Ha a készenléti állapot befejezi a helyreállítási folyamatot az utolsó véglegesített adatokig, az elsődleges kiszolgáló lesz előléptetve. 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.
A kényszerített feladatátvétel lépései a következők:
| Lépés | Leírás | Alkalmazás állásideje várható? |
|---|---|---|
| 0 | 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 | Miután a kiszolgáló elkészült, a DNS-rekord ugyanazzal a gazdagépnévvel frissül, de a készenléti állapot IP-címét 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 várhatóan az 1. lépés után kezdődik, és a 6. lépés befejezéséig megmarad. A többi lépés a háttérben történik, 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 a teljes feladatátvételi folyamat helyett.
Megfontolandó szempontok a kényszerített feladatátvétel végrehajtása során
A teljes teljes üzemidő hosszabbnak tekinthető, mint az alkalmazás által tapasztalt tényleges állásidő.
Fontos
Mindig figyelje meg az állásidőt az alkalmazás szempontjából!
Ne végezzen azonnali, vissza-vissza feladatátvételt. Várjon legalább 15–20 percet a feladatátvételek között, így az új készenléti kiszolgáló teljesen kiépült.
Az állásidő csökkentése érdekében javasoljuk, hogy egy alacsony tevékenységű időszakban végezzen kényszerített feladatátvételt.
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ásának elsődleges mechanizmusa 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 tartalmaz, 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 feladatátvételkor a pg_stat_* tevékenységstatisztikákat, például a vizsgálatok számát, az olvasási rekordokat és a frissítéseket rögzítő táblák 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 célja az új elsődleges működési állapotának pontos tükrözése, de azt is jelenti, hogy a korábbi tevékenységi metrikák elvesznek, amelyek tájékoztathatják az autovacuum-folyamatot és más működési hatékonyságot.
Ezt a különbséget figyelembe véve a PostgreSQL feladatátvételt követő ajánlott eljárás a futtatás ANALYZE. 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ónaletölté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 egy új rugalmas kiszolgálót helyez üzembe egy másik, nem érinti 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 Rugalmas Azure Database for PostgreSQL-kiszolgálón történő biztonsági mentés és visszaállítás című témakörben talál.
Zónaredundáns: A rugalmas kiszolgáló 60–120 másodpercen belül automatikusan feladatátvételt kap a készenléti kiszolgálóra nulla adatvesztéssel.
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 helyi redundáns tárolást biztosít három adatmásolattal, zónaredundáns biztonsági mentéssel (olyan régiókban, ahol támogatott), valamint 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. Ebben a konfigurációban 99,9%-os üzemidejű SLA érhető el. Tervezett vagy nem tervezett feladatátvételi események során, ha a kiszolgáló leáll, a szolgáltatás a következő automatizált eljárással tartja fenn a kiszolgálók rendelkezésre állását:
- Kiépült egy új számítási Linux rendszerű virtuális gép.
- Az adatfájlokat tartalmazó tároló az új virtuális gépre van leképezve.
- 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
Régiószintű katasztrófa esetén az Azure egy másik régió használatával biztosít védelmet 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ása során figyelembe kell vennie 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 katasztrófa esetén. 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és csak a kiszolgáló létrehozásakor konfigurálható. Ha a kiszolgáló georedundáns biztonsági mentéssel van konfigurálva, 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 replikák
A régiók közötti olvasási replikák üzembe helyezhetők, hogy megvédjék az adatbázisokat a régiószintű hibáktól. Az olvasási replikák a PostgreSQL fizikai replikációs technológiájával aszinkron módon frissülnek, és az elsődleges replika késését okozhatják. Az olvasási replikák általános célú és memóriaoptimalizált számítási szinteken támogatottak.
További információ az olvasási replika funkcióiról és szempontjairól: Olvasási replikák.
Üzemkimaradás észlelése, értesítés és felügyelet
Ha a kiszolgáló georedundáns biztonsági mentéssel van konfigurálva, georedundáns visszaállítást végezhet a párosított régióban. A rendszer új kiszolgálót épít ki és állít helyre a régióba másolt utolsó elérhető adatokra.
Régióközi olvasási replikákat is használhat. Régióhiba esetén vészhelyreállítási műveletet hajthat végre az olvasási replika önálló írásvédett kiszolgálóvá való előléptetésével. Az RPO várhatóan legfeljebb 5 percet vesz igénybe (adatvesztés lehetséges), kivéve súlyos regionális hiba esetén, 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.