Megbízhatóság az Azure Database for PostgreSQL-ben

Az Azure Database for PostgreSQL egy teljes körűen felügyelt adatbázis-szolgáltatás, amely részletes vezérlést és rugalmasságot biztosít az adatbázis-kezelési funkciók és a konfigurációs beállítások felett. A szolgáltatás magas rendelkezésre állást és vészhelyreállítási képességeket biztosít a követelményeknek megfelelően.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan teheti rugalmassá az Azure Database for PostgreSQL-t számos lehetséges kimaradás és probléma esetén, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradásait, a régiókimaradásokat és a szolgáltatáskarbantartást. Azt is ismerteti, hogyan használható biztonsági másolatok más típusú problémákból való helyreállításra, és kiemeli az Azure Database for PostgreSQL szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Az Azure Database for PostgreSQL üzembe helyezéséről a megoldás megbízhatósági követelményeinek támogatásához, valamint az architektúra egyéb aspektusaira gyakorolt megbízhatóságról az Azure Database for PostgreSQL architektúrájának ajánlott eljárásai az Azure Well-Architected-keretrendszerben című témakörben olvashat.

A megbízhatósági architektúra áttekintése

Ez a szakasz a szolgáltatás megbízhatóság szempontjából leginkább releváns működésének néhány fontos aspektusát ismerteti. A szakasz bemutatja a logikai architektúrát, amely tartalmazza a telepített és használt erőforrásokat és funkciókat. Emellett a fizikai architektúrát is ismerteti, amely részletesen bemutatja, hogyan működik a szolgáltatás a borítók alatt.

Logikai architektúra

Az Azure Database for PostgreSQL használatakor üzembe helyez egy kiszolgálót, amely az adatbázis-kiszolgáló támogatásához szükséges számítási és tárolási erőforrásokat jelöli. Egy vagy több adatbázist helyez üzembe a kiszolgálón.

A kiszolgálók több számítási szinten is üzembe helyezhetők: Burstable, General Purpose és Memory Optimized, amelyek mindegyike különböző számítási feladatokhoz van optimalizálva. Egyes Azure-régiókban kiszolgálókat helyezhet üzembe az Azure Confidential Computing használatával.

Az általános szolgáltatásarchitektúráról és az üzembehelyezési modellekről további információkért lásd: Mi az Azure Database for PostgreSQL?

Fizikai architektúra

• Számítási és tárolási elkülönítés: Az Azure Database for PostgreSQL számítási és tárolási elkülönítési architektúrát használ a magas rendelkezésre állás támogatásához. Az adatbázismotor Linux rendszerű virtuális gépen fut, míg az adatfájlokat az Azure Storage tárolja, amely az adatbázisfájlok három helyileg redundáns szinkron példányát tartja fenn az adatok tartósságának biztosítása érdekében.

• Magas rendelkezésre állás: Igény szerint engedélyezheti a magas rendelkezésre állású konfigurációt a kiszolgálón. Ha engedélyezi a magas rendelkezésre állású konfigurációt, a szolgáltatás egy meleg készenléti kiszolgálót helyez üzembe és tart fenn. Az elsődleges kiszolgálón végzett adatváltozások szinkron módon replikálódnak a készenléti kiszolgálóra, hogy az elsődleges kiszolgáló meghibásodása során ne legyen adatvesztés.

  Az architektúra elválasztja a számítási réteget a tárolási rétegtől, így a szolgáltatás megfelelően kezelheti a különböző típusú hibákat. A nagyobb rugalmasság érdekében eloszthatja a kiszolgálókat a rendelkezésre állási zónák között.

  

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

  Feladatátvétel végrehajtásával válthat a kiszolgálók között. A feladatátvételnek két típusa van: a kényszerített feladatátvételek, amelyeket az elsődleges kiszolgáló meghibásodása esetén használnak, valamint a tervezett feladatátvételek, amelyeket bizonyos karbantartási műveletek során, illetve más olyan helyzetekben használnak, ahol a feladatátvétel során minimálisra kell csökkenteni az alkalmazások állásidejét.

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

  További információ: Magas rendelkezésre állás az Azure Database for PostgreSQL-ben.

• Mentések: Az Azure Database for PostgreSQL automatikusan létrehoz kiszolgálói biztonsági mentéseket. További információ: Biztonsági mentés és visszaállítás.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Az alkalmazásoknak kezelnie kell az átmeneti csatlakozási hibákat, amelyek karbantartás, skálázási műveletek vagy hálózatkimaradások során fordulhatnak elő. Kövesse az alábbi javaslatokat:

• Ha az alkalmazás átmeneti hibákba ütközik, exponenciális visszakapcsolással próbálkozzon újra a művelettel. Növelje az újrapróbálkozások közötti késést, és korlátozza a kísérletek számát. Ha a művelet a maximális újrapróbálkozások után is meghiúsul, kezelje hibaként.
• Ahol lehetséges, használjon ügyfélkódtárakat (más néven illesztőprogramokat), amelyek automatikusan kezelik az újrapróbálkozásokat.
• Az írási műveletek során előforduló átmeneti hibák gondos megfontolást igényelnek. Fontolja meg az írási műveletek idempotenssé tételét, hogy azok többször is biztonságosan végrehajthatók legyenek.

További információ: Átmeneti csatlakozási hibák kezelése az Azure Database for PostgreSQL-ben.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

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.

A magas rendelkezésre állási konfiguráció ellenére kiválaszthatja a rendelkezésre állási zóna támogatási típusát. A magas rendelkezésre állás engedélyezése egy készenléti kiszolgálót helyez üzembe az elsődleges kiszolgáló mellett. 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. Bármelyik magas rendelkezésre állású üzemi modellt használja a kiszolgáló, az adatok szinkron módon le lesznek kötelezve az elsődleges és a készenléti kiszolgálókra is. Ha az elsődleges kiszolgálón fennakadás lép fel, a kiszolgáló automatikusan átesik a készenléti kiszolgálóra.

Az adatfájlokat és az írási naplókat (WALs) prémium szintű felügyelt lemezeken tárolják az egyes rendelkezésre állási zónákban, helyileg redundáns tárolással (LRS), amely automatikusan három adatpéldányt tárol az egyes zónákban.

Az Azure Database for PostgreSQL két rendelkezésre állási zónakonfigurációtípust támogat magas rendelkezésre állás esetén:

• Zónaredundáns magas rendelkezésre állás: A zónaredundancia a zóna rugalmasságának legmagasabb szintjét biztosítja, ha egy elsődleges kiszolgálót helyez üzembe egy rendelkezésre állási zónában, egy készenléti kiszolgálót pedig egy másik rendelkezésre állási zónában. A készenléti kiszolgáló az elsődlegeshez hasonló számítási, tárolási és hálózati konfigurációt használ. 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.

  Kiválaszthatja az elsődleges és a készenléti kiszolgálók rendelkezésre állási zónáit, vagy engedélyezheti a Microsoftnak, hogy kiválassza őket.

  Az éles kiszolgálók számára a zónaredundáns üzembe helyezést javasoljuk.

  

  Az írási műveletek kis mértékben növelhetik a véglegesítés késését, mivel a szolgáltatás szinkron módon replikálja az adatokat a készenléti kiszolgálóra. A hatás a számítási feladatok, a kiválasztott termékváltozat és a régió szerint változik.

• Zonal (azonos zónájú) magas rendelkezésre állás: Az elsődleges és a készenléti kiszolgálók ugyanazt a rendelkezésre állási zónát használják. Ha megszakad az elsődleges kiszolgáló, de a zóna továbbra is kifogástalan állapotban van, a kiszolgáló automatikusan átesik a készenléti kiszolgálóra. A zonális üzembe helyezés magas rendelkezésre állást biztosít egyetlen rendelkezésre állási zónán belül. Védelmet nyújt a csomópontszintű hibák ellen, és segít csökkenteni az alkalmazások állásidejét a tervezett és nem tervezett leállási események során. Ez azonban nem véd az adott zónában történő kimaradás ellen.

  

  A zonal (azonos zónájú) magas rendelkezésre állás csak a következő helyzetekben érhető el:

  • A régió nem támogatja a rendelkezésre állási zónákat. A régió gyakorlatilag egyetlen zónaként működik, így az egyetlen magas rendelkezésre állású konfiguráció, amelyet kiválaszthat, ugyanaz a zóna.
  • Ha egy régió nem rendelkezik elegendő kapacitással egy zónaredundáns üzembe helyezéshez, a szolgáltatás kezdetben mindkét kiszolgálót ugyanabba a rendelkezésre állási zónába helyezheti, és automatikusan áttelepítheti őket külön zónákba, amikor a kapacitás elérhetővé válik. Ez a lehetőség akkor érhető el, ha az Azure Portalt vagy az Azure CLI-t használja egy kiszolgáló üzembe helyezéséhez. További információ: Az üzleti szempontból kritikus (magas rendelkezésre állású) beállítások konfigurálása.

  Mivel a kiszolgálók ugyanabban a zónában találhatók, csökkentheti az írási késést az ugyanazon a zónán belül üzembe helyezendő alkalmazások esetében.

Ha magas rendelkezésre állás nélkül konfigurálja a kiszolgálót, az egyetlen kiszolgálón fut. Ha a kiszolgáló vagy a zóna leáll, a kiszolgáló nem érhető el. További információ: Rendelkezésre állási zónák nélküli konfigurációk.

Követelmények

• Régiótámogatás: Az Azure Database for PostgreSQL a rendelkezésre állási zónák konfigurációinak támogatása az Azure-régiók között eltérő. A régiók teljes listáját, a rendelkezésre állási zónák támogatásának típusait és az adott régióra vonatkozó konkrét szempontokat az Azure-régiók című témakörben találja.

• Számítási szint: Az alábbi táblázat felsorolja a rendelkezésre állási zónák egyes típusainak támogatási szintjeinek számítási rétegbeli támogatását:

  Tarifacsomag	Zónaredundáns	Zonal (azonos zónában)
  Időszakosan növelhető	Nem támogatott	Támogatott
  általános célú	Támogatott	Támogatott
  Memóriára optimalizált	Támogatott	Támogatott

• Szolgáltatási szint: A zónaredundancia általános célú vagy memóriaoptimalizált szinteket igényel.

  A zonális (azonos zónás) telepítések minden tarifacsomagban támogatottak.

Megfontolások

Régió kapacitása: Ha egy régió nem rendelkezik elegendő kapacitással egy zónaredundáns üzembe helyezéshez, a szolgáltatás kezdetben mindkét kiszolgálót ugyanabba a rendelkezésre állási zónába helyezheti, és automatikusan áttelepítheti őket külön zónákba, amikor a kapacitás elérhetővé válik. Ez a lehetőség akkor érhető el, ha az Azure Portalt vagy az Azure CLI-t használja egy kiszolgáló üzembe helyezéséhez. További információ: Az üzleti szempontból kritikus (magas rendelkezésre állású) beállítások konfigurálása.

Cost

Ha engedélyezi a magas rendelkezésre állást, a készenléti kiszolgáló létrehozása és számlázása az elsődlegesével azonos sebességgel történik. A rendelkezésre állási zóna konfigurációja nem befolyásolja a költségeket. A rendelkezésre állási zónákon belüli vagy a rendelkezésre állási zónák közötti adatreplikálás nem jár díjjal. A biztonsági mentési tárterület mennyiségétől függően előfordulhat, hogy a biztonsági mentési tárterületért is fizetnie kell. Részletes díjszabási információkért tekintse meg az Azure Database for PostgreSQL díjszabását.

A rendelkezésre állási zóna támogatásának konfigurálása

A kiszolgáló rendelkezésre állási zónájának támogatásának konfigurálásához konfigurálja a magas rendelkezésre állási beállításokat.

• Zónaredundáns kiszolgáló létrehozása: Ha tudni szeretné, hogyan hozhat létre magas rendelkezésre állású és zónaredundanciát engedélyező kiszolgálót, olvassa el a rövid útmutatót: Azure Database for PostgreSQL létrehozása az Azure Portalon.

• Meglévő kiszolgálók rendelkezésreállási zónájának konfigurációjának módosítása: A magas rendelkezésre állási beállítások módosításával módosíthatja a meglévő kiszolgálók rendelkezésre állási zónájának konfigurációját. Részletes lépéseket a meglévő kiszolgálók magas rendelkezésre állásának engedélyezése című témakörben talál.

  A létrehozásuk után sem az elsődleges, sem a készenléti kiszolgálóhoz használt zóna nem módosítható. Újra létre kell hoznia a kiszolgálót.

  Jótanács

  Érdemes megvárni, amíg a kiszolgálói tevékenység alacsony lesz, mielőtt módosítja a magas rendelkezésre állási konfigurációt.

• Magas rendelkezésre állás letiltása: A magas rendelkezésre állás letiltása eltávolítja a készenléti kiszolgálót, így a kiszolgáló nem rugalmas a rendelkezésre állási zónában lévő kimaradásokkal szemben. További információ: Magas rendelkezésre állás letiltása.

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgálók magas rendelkezésre állási és rendelkezésre állási zóna támogatással vannak konfigurálva, és az összes rendelkezésre állási zóna működőképes.

• Zónák közötti művelet: A PostgreSQL-ügyfélalkalmazások az adatbázis-kiszolgáló nevével csatlakoznak az elsődleges kiszolgálóhoz. Az Azure Database for PostgreSQL aktív/passzív konfigurációt használ, amelyben az elsődleges kiszolgáló kezeli az adatbázis-kapcsolatokat és lekérdezéseket az elsődleges rendelkezésre állási zónában. A készenléti kiszolgáló nem szolgálja ki az ügyfélforgalmat a normál műveletek során.

• Zónaközi adatreplikálás: Az adatok módosításai szinkron módon replikálódnak az elsődleges és a készenléti kiszolgálók között. A tranzakciók nem tekinthetők befejezettnek mindaddig, amíg az elsődleges és a készenléti kiszolgáló nem nyugtázza az írást.

  Az alkalmazás tranzakció által kiváltott írás az első naplót commitálja a WAL-ba 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 nyugtázási folyamat nem várja meg, amíg a naplók a készenléti kiszolgálóra lesznek alkalmazva.

  A replikáció hatása a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függően eltérő:

  • Zónaredundáns: Mivel a kiszolgálók külön zónákban vannak, ez a megközelítés nulla adatvesztést biztosít zónahiba esetén. Ezt a helyzetet úgy is szokták nevezni, hogy zónahibák esetén nulla helyreállításipont-célkitűzést (RPO) érünk el.

    A zónák közötti replikáció azonban kis mértékű extra késést eredményezhet. A késés hatása az alkalmazástól függ, és a legtöbb alkalmazás esetében elhanyagolható.

  • Zonal: Mivel mindkét kiszolgáló ugyanabban a zónában van, a rendszer nem replikálja a forgalmat a zónák között.

  Megjegyzés:

  A rendszer valós időben replikálja a naplóadatokat a készenléti kiszolgálóra. Az elsődleges kiszolgálón észlelt 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 kiszolgálóra. Ezért nem használhatja a készenléti üzemmódot az ilyen típusú hibák helyreállításához, és a biztonsági másolatból időponthoz kötött visszaállítást kell végrehajtania. További információ: Biztonsági mentés és visszaállítás.

Viselkedés zónahiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgálók magas rendelkezésre állással és zóna támogatással vannak konfigurálva, és a rendelkezésre állási zónában kiesés történik.

• Észlelés és válasz: Az Azure 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.

  Zónahiba esetén a viselkedés a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függően eltérő:

  • Zónaredundáns: Az Azure Database for PostgreSQL automatikusan észleli a rendelkezésre állási zónák hibáit. A lehetséges magas rendelkezésre állási állapottípusok megtekintéséhez tekintse meg a magas rendelkezésre állási állapottípusokat. Ha egy zóna meghibásodik, az Azure kényszerített feladatátvételt kezdeményez a készenléti kiszolgálóra anélkül, hogy önnek kellene elvégeznie a szükséges lépéseket.

  • Zonal: Ha a zónakiszolgálót üzemeltető rendelkezésre állási zóna elérhetetlenné válik, az elsődleges és a készenléti kiszolgáló sem érhető el. Ebben a forgatókönyvben a szolgáltatás nem biztosít automatikus feladatátvételt. Ön a felelős a zónakimaradás észleléséért és helyreállítási műveletek végrehajtásáért, például a zónaredundáns biztonsági másolatok egy másik rendelkezésre állási zónában vagy régióban lévő különálló kiszolgálóra történő visszaállításáért.

• Értesítés: 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. A monitorozási funkció az Azure Resource Healthre épül, és képes észlelni és figyelmeztetni az adatbázis feladatátvételi készültségét vagy általános rendelkezésre állását esetlegesen befolyásoló problémákat. Értékelje a legfontosabb metrikákat, például a kapcsolat állapotát, a feladatátvételi állapotot és az adatreplikációs állapotot a proaktív hibaelhárítás érdekében, és segít fenntartani az adatbázis üzemidejét és teljesítményét.

  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.

• Aktív kérések: Ha egy rendelkezésre állási zóna elérhetetlenné válik, az érintett zónában lévő kiszolgálókra irányuló folyamatban lévő kérések leállhatnak. Az alkalmazásoknak újra meg kell próbálkoznia ezeket a kéréseket. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

• Várható adatvesztés: Az adatvesztés mértéke a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

  • Zónaredundáns: A zóna feladatátvétele során nulla adatvesztés várható a különböző zónákban lévő elsődleges és készenléti kiszolgálók közötti szinkron replikáció következtében.

  • Zonal: Az érintett zónában lévő kiszolgálókon lévő adatok nem érhetők el, amíg a zóna helyre nem áll.

• Várható állásidő: Az állásidő mértéke a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

  • Zónaredundáns: A feladatátvétel általában 60–120 másodpercen belül fejeződik be. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

  • Zonal: Az érintett zónában lévő kiszolgálók mindaddig nem érhetők el, amíg a rendelkezésre állási zóna helyre nem áll.

• Újraelosztás: A forgalom átirányítási viselkedése a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

  • Zónaredundáns: A feladatátvételt követően a korábbi készenléti kiszolgáló lesz az új fő kiszolgáló, és megkezdi az új kapcsolatok elfogadását. Az Azure automatikusan létrehoz egy új készenléti kiszolgálót az eredeti elsődleges zónában a helyreállítás után. A teljes részletekért lásd Kényszerített feladatátvétel.

  • Zonal: Ha egy zóna nem érhető el, a kiszolgáló nem érhető el. Ha rendelkezik egy különálló kiszolgálóval, amelyet egy másik rendelkezésre állási zónában vagy régióban hozott létre, Ön felelős a forgalomnak az adott kiszolgálóra történő átirányításáért.

Zóna helyreállítása

A zóna helyreállítási viselkedése a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

• Zónaredundáns: A rendelkezésre állási zóna helyreállításakor az Azure Database for PostgreSQL automatikusan újraépíti a készenléti kiszolgálót a helyreállított zónában, és szinkronizálja az aktuális elsődlegessel. A helyreállított zóna ezután készenléti helyként szolgál. A szolgáltatás nem helyezi vissza automatikusan az elsődleges szerepkört az eredeti zónába a szükségtelen fennakadások elkerülése érdekében. Ha vissza szeretné állítani az elsődleges rendszert az eredeti zónába, manuálisan is kezdeményezhet egy tervezett feladatátvételt.

• Zonal: Miután a zóna kifogástalan állapotban van, a zónában lévő kiszolgálók ismét elérhetők. Ön felel a számítási feladatokhoz szükséges zóna-helyreállítási eljárásokért és adatszinkronizálásért.

Zónahibák tesztelése

A zónahibák tesztelésének lehetőségei a példány által használt rendelkezésre állási zóna konfigurációjától függenek.

• Zónaredundáns: Kényszerített átállás kezdeményezésével tesztelheti az alkalmazás rezilienciáját az átállás ellen. A kényszerített feladatátvétel lehetővé teszi, hogy szimuláljon egy nem tervezett leállási forgatókönyvet a számítási feladat futtatásakor, és megfigyelheti az alkalmazás állásidejét. Azt javasoljuk, hogy szimulációkat futtasson nem éles környezetben vagy csendes időben. További információért lásd: Kényszerített feladatátvétel kezdeményezése.

• Zonal: Bár nem tudja szimulálni a teljes zónakimaradást, szimulálhatja, hogy a kiszolgáló nem érhető el, hasonlóan ahhoz, ami a zónakimaradás során történik. További információ: Kiszolgáló számításának leállítása.

Rugalmasság régiószintű hibákhoz

Az Azure Database for PostgreSQL támogatja a régiók közötti olvasási replikákat, amelyekkel az adatbázis szinkronizált másolatát egy másik régióban tarthatja fenn a gyorsabb helyreállítás érdekében.

A támogatott régiókban georedundáns biztonsági másolatokat is használhat a régiók közötti helyreállításhoz. A biztonsági mentések azonban általában több állásidőt és adatvesztést foglalnak magukban, mint a replikáció. További információ: Biztonsági mentés és visszaállítás.

Régiók közötti olvasási replikák

Olvasási replikákat helyezhet üzembe, hogy megvédje az adatbázisokat a régiószintű hibáktól. Minden olvasási replika egy külön Azure Database for PostgreSQL-kiszolgáló. Amikor egy olvasási replikát egy második Azure-régióban helyez el, az adatbázis-kiszolgáló rugalmasságot biztosíthat egy régiószintű problémához. Legfeljebb öt olvasási replikát helyezhet üzembe, amelyek opcionálisan különböző Azure-régiókban is lehetnek. A PostgreSQL fizikai replikációs technológiája aszinkron módon frissíti az olvasási replikákat, és lekéshetik az elsődleges példányt. A régiók közötti olvasási replikák opcionálisan csak olvasható számítási feladatokat is kiszolgálhatnak a globálisan elosztott alkalmazások késésének csökkentése vagy az elsődleges kiszolgáló olvasási forgalmának kiszervezése érdekében. További információ a read replica funkcióiról és szempontjairól: Read replicas.

A virtuális végpontok olvasás-írás és írásvédett végpontokat biztosítanak, és automatikusan átirányítják a forgalmat a replika előléptetésekor, ami segít csökkenteni az állásidőt a feladatátvételi események során. Határozottan javasoljuk, hogy az alkalmazások rugalmasságának javítása érdekében használjon virtuális végpontokat régiók közötti olvasási replikákkal. További információ: Virtuális végpontok olvasási replikákhoz az Azure Database for PostgreSQL-ben.

Ha az elsődleges régió meghibásodik, előléptetést indíthat el, hogy a másodlagos replika legyen az elsődleges. Az átállásnak különböző típusai vannak, amelyeket az olvasási replikák használatától függően aktiválhat. Ha olvasási replikákat használ a régióhibákkal szembeni rugalmasság biztosítására, általában az elsődleges szerverré előléptetés megközelítést alkalmazza, amely frissíti a virtuális végpontot. A régiókimaradás során kényszerített előléptetést kell végrehajtania, amely adatvesztést okozhat a nem duplikált adatok esetében. Olyan tervezett forgatókönyvekben, ahol az elsődleges régió kifogástalan állapotban van, dönthet úgy, hogy egy tervezett előléptetést hajt végre az adatvesztés elkerülése érdekében. További információ: Olvasási replikák előléptetése az Azure Database for PostgreSQL-ben.

Megjegyzés:

Ez a szakasz összefoglal néhány fontos információt arról, hogy az olvasási replikák hogyan támogathatják a régiószintű hibákra való rugalmasságot. Olvasási replikákkal is javíthatja a teljesítményt, és támogathatja a nagy léptékű földrajzilag elosztott felhasználói bázisokat. További információ: Replikák olvasása.

Követelmények

• Régiótámogatás: Régiók közötti olvasási replikákat bármely olyan régióban létrehozhat, amely támogatja az Azure Database for PostgreSQL-t. Ön nem korlátozódik az Azure párosított régióira.

• Számítási szintek: Az általános célú és memóriaoptimalizált számítási szintek támogatják az olvasási replikákat. A Burstable szintje nem támogatja az olvasási replikákat.

Megfontolások

• Konfigurációs különbségek: Előfordulhat, hogy az olvasási replikák nem öröklik az összes konfigurációs beállítást az elsődleges kiszolgálótól. Tervezze meg a feladatátvétel utáni szükséges beállítások konfigurálását. Az elsődleges kiszolgálónak és replikáknak szimmetrikusnak kell lenniük, ami azt jelenti, hogy bizonyos beállításokhoz ugyanazokat a szinteket, tárhelyméreteket és értékeket kell használniuk. A régióhibák során a szimmetrikus kiszolgálóra vonatkozó követelményt el lehet tekinteni a kényszerített előléptetések esetében, de a váratlan problémák elkerülése érdekében célszerű szimmetrikus konfigurációval rendelkezni, ahol lehetséges. További információ: Konfigurációkezelés.

• Replikációs késés figyelése: Az aszinkron replikációs folyamat replikációs késést igényel, amely számos tényezőtől függően változhat. Ha a replikáció késése nagyon magas, a kiszolgáló problémákat tapasztalhat. Fontos a replikáció késésének monitorozása, hogy azok eszkalálása előtt enyhíthesse a problémákat. További információkért lásd: Replikáció figyelése.

• Magas rendelkezésre állás: Az olvasási replikák nem lehetnek magas rendelkezésre állásúak, és előléptetésükkor sem lesznek azok. A klón másolat előléptetése után ön felelős a magas rendelkezésre állás konfigurálásáért.

Az előléptetési folyamatra vonatkozó további szempontok megismeréséhez lásd: Az olvasási replikák előléptetése az Azure Database for PostgreSQL-ben – Szempontok.

Cost

Az olvasási replikák számítási és tárolási költségeket, valamint régiók közötti adatátviteli díjakat vonnak maga után a replikációhoz. Részletes díjszabási információkért tekintse meg az Azure Database for PostgreSQL díjszabását és a sávszélesség díjszabását.

Többrégiós támogatás konfigurálása

• Olvasási replika létrehozása: Az olvasási replika létrehozásának módjáról az Olvasási replika létrehozása című témakörben olvashat. A replikák az elsődleges kiszolgáló létrehozása után konfigurálhatók, amíg az elsődleges kiszolgáló fut és elérhető.

  Virtuális végpont létrehozásához lásd: Virtuális végpontok létrehozása.

• Olvasási replika törlése: Az olvasási replika törléséről az olvasási replika törlése című témakörben olvashat.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgáló egy másik régióban és virtuális végponton lévő olvasási replikával van konfigurálva, és minden régió működőképes:

• Forgalomirányítás régiók között: Normál műveletek esetén a virtuális végpont az olvasási-írási végpont forgalmát az elsődleges kiszolgálóra irányítja az elsődleges régióban. Ha a virtuális végpont írásvédett végpontját is használja, az a konfigurált replikára irányítja a forgalmat.

• Régiók közötti adatreplikálás: A régiók közötti olvasási replikák aszinkron replikációt használnak az elsődleges kiszolgáló teljesítményére gyakorolt hatás minimalizálása érdekében. A replikáció késésének mértéke számos tényezőtől függ, beleértve az írási terhelést, valamint az elsődleges kiszolgáló és a replikák közötti késést. A replikáció késése általában legalább néhány perc, de sokkal hosszabb is lehet. További információkért lásd: Replikáció figyelése.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgáló egy másik régióban és egy virtuális végponton lévő olvasási replikával van konfigurálva, és az elsődleges régióban kimaradás történik:

• Észlelés és válasz: Ön felelős az elsődleges régió leállásának észleléséért, és az olvasási replika manuális előléptetéséért, hogy az új elsődleges kiszolgálóvá váljon. A régiókimaradás során kényszerített előléptetést kell végrehajtania, amely a nem duplikált adatok elvesztését eredményezi.

  Fontos

  Ön a felelős az előléptetés elindításáért. Az Azure nem emeli elő automatikusan az olvasási replikákat, még akkor sem, ha egy régióban hiba lép fel.

  Az előléptetés indításának részletes lépéseit az Olvasási replika átállítása elsődlegesre című témakörben találja.

• Értesítés: A Microsoft nem értesíti automatikusan, ha egy régió le van állítva. Az Azure Service Health használatával azonban megismerheti a szolgáltatás általános állapotát, beleértve a régióhibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

• Aktív kérések: Az elsődleges régióval létesített összes aktív kapcsolat megszakad. Az alkalmazásoknak az előléptetési folyamat befejeződése után újra meg kell próbálkoznia a kapcsolatok létesítésével az előléptetett replikával.

• Várható adatvesztés: A régiókimaradás során kényszerített előléptetést kell végrehajtania, amely a nem duplikált adatok végleges elvesztését eredményezi.

  Az adatvesztés mértéke a replikáció késésétől függ a kimaradás időpontjában. A replikáció késése általában legalább néhány perc, de sokkal hosszabb is lehet. További információkért lásd: Replikáció figyelése.

• Várható állásidő: A kényszerített előléptetés általában az aktiválástól számított 1–3 percen belül befejeződik. Előfordulhat, hogy az alkalmazásoknak újra csatlakozniuk kell a megfelelő végponthoz. A virtuális végpontok a kényszerített előléptetési folyamat részeként frissülnek. Az alkalmazásoknak tiszteletben kell tartaniuk a végpont DNS-rekordjainak élettartamát (TTL), hogy az előléptetés befejezése után gyorsan újracsatlakozhassanak a megfelelő replikához.

• Forgalom átirányítása: A kiszolgáló virtuális végpontja automatikusan átirányítja az alkalmazás forgalmát az új elsődleges replikára.

  Megjegyzés:

  Az olvasási replika elsődleges kiszolgálóként való előléptetése után nincs engedélyezve a magas rendelkezésre állású konfiguráció. Manuálisan kell engedélyeznie a magas rendelkezésre állású konfigurációt, vagy hozzá kell adnia a saját automatizálási folyamataihoz.

Régió helyreállítása

Virtuális végpontok használatakor az elsődleges régió helyreállítása után a rendszer automatikusan olvasási replikaként konfigurálja a régi elsődleges kiszolgálót. Egy másik előléptetést is végrehajthat, hogy az elsődleges műveleteket visszajuttathassa az előnyben részesített elsődleges régióba.

Régióhibák tesztelése

A folyamatok érvényességének biztosítása érdekében rendszeresen tesztelje az olvasóreplika-promóciós eljárásokat annak érdekében, hogy a képességek megfeleljenek az RTO és RPO követelményeknek.

Az olvasási replikát bármikor előléptetheti elsődleges kiszolgálóvá, még akkor is, ha minden régió kifogástalan állapotban van. Teszteléshez:

• Kényszerített előléptetési tesztelést is végrehajthat. Javasoljuk, hogy ezeket a teszteket nem éles környezetben végezze el, mert az adatvesztéshez vezethet. A kényszerített előléptetési tesztelés segít szimulálni a régiókimaradás során megjelenő viselkedést.
• Olyan tervezett karbantartási vagy tesztelési forgatókönyvek esetén, ahol el szeretné kerülni az adatvesztést, használjon inkább egy tervezett előléptetést. Vegye figyelembe, hogy a tervezett előléptetés más folyamatot követ, mint a régiókimaradás során történő előléptetés.

Részletes útmutatásért tekintse meg az Olvasási replika átállítása elsődlegesre című témakört.

A vészhelyreállítási stratégia részeként rendszeresen futtasson teljes helyreállítási próbákat. Ezeknek a részletezéseknek tartalmazniuk kell az adatérvényesítést, az alkalmazásfunkció-tesztelést és a dokumentált visszaállítási eljárásokat.

Biztonsági mentés és visszaállítás

Az Azure Database for PostgreSQL automatikusan végez biztonsági mentéseket, amelyek időponthoz kötött helyreállítási képességeket biztosítanak, és segítenek megvédeni Önt az adatok véletlen sérülése és törlése ellen. A biztonsági mentéseket teljes mértékben a Microsoft felügyeli, nem szakítja meg a kiszolgáló elérhetőségét, és a teljes biztonsági mentéseket és a tranzakciónaplók biztonsági mentéseit is tartalmazza.

• Biztonsági mentési tár: Ha a kiszolgáló zónaredundáns magas rendelkezésre állással van konfigurálva, a biztonsági másolatok zónaredundáns tárolóban (ZRS) vannak tárolva. A magas rendelkezésre állás nélkül konfigurált kiszolgálók vagy a zóna (egyzónás) magas rendelkezésre állása esetén a biztonsági másolatok helyileg redundáns tárolóban (LRS) vannak tárolva.

  A párokkal rendelkező Azure-régiókban konfigurálhatja a georedundáns (GRS) biztonsági mentési tárolót a kiszolgáló létrehozásakor, hogy a biztonsági másolatokat replikálja az Azure párosított régióba a régióhibák elleni további védelem érdekében. A biztonsági mentések aszinkron módon replikálódnak.

  Az alapértelmezett biztonsági mentési megőrzési idő 7 nap, a megőrzést 35 napra meghosszabbíthatja. Az Azure Backupot a manuális biztonsági mentések hosszú távú tárolására is használhatja akár 10 évig. Minden biztonsági mentés titkosítva van.

• Visszaad: Az időponthoz kötött helyreállítás lehetővé teszi az adatbázis visszaállítását a biztonsági mentés megőrzési időszakának bármely pillanatára. A visszaállítási folyamat új adatbázis-kiszolgálót hoz létre egy új, felhasználó által megadott kiszolgálónévvel, amelyet aztán használhat as-is vagy adatokat másolhat.

  Georedundáns biztonsági mentés visszaállításakor új kiszolgálót hoz létre a párosított régióban.

  Ez a funkció hasznos lehet véletlen adatmódosítások, alkalmazáshibák vagy tesztelési forgatókönyvek utáni helyreállításhoz.

A legtöbb megoldás esetében nem szabad kizárólag biztonsági másolatokra támaszkodnia. Ehelyett használja az útmutatóban ismertetett egyéb képességeket a rugalmassági követelmények támogatására. A biztonsági másolatok azonban védelmet nyújtanak bizonyos kockázatok ellen, amelyeket más megközelítések nem. További információ: Mi a redundancia, a replikáció és a biztonsági mentés?

További információ: Biztonsági mentés és visszaállítás az Azure Database for PostgreSQL-ben.

A szolgáltatás karbantartásával szembeni rugalmasság

Az Azure Database for PostgreSQL automatikusan kezeli a kritikus karbantartási feladatokat, beleértve a mögöttes hardver, az operációs rendszer és az adatbázismotor javítását. A szolgáltatás biztonsági frissítéseket, szoftverfrissítéseket és alverziófrissítéseket tartalmaz a tervezett karbantartás részeként.

Annak érdekében, hogy a kiszolgáló elérhető maradjon a karbantartási időszakok során, kövesse az alábbi javaslatokat:

• Magas rendelkezésre állás engedélyezése: A karbantartás során előfordulhat, hogy a kiszolgálót újra kell indítani a frissítési folyamat részeként. Ha engedélyezve van a magas rendelkezésre állás, a karbantartási műveletek általában működés közbeni frissítéseket használnak az állásidő minimalizá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 replikán 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. Ez a szekvenálás arra vonatkozik, hogy a kiszolgáló zónaredundáns vagy zónaszintű magas rendelkezésre állást használ-e.

  A magas rendelkezésre állással nem rendelkező kiszolgálók esetében a karbantartási műveletek során rövid állásidőre számíthat. Ha a magas rendelkezésre állás engedélyezve van, a karbantartási műveletek általában minimális vagy nem állásidővel fejeződnek be.

• Egyéni karbantartási időszakok konfigurálása: Konfigurálhatja a karbantartási ütemezést rendszerszintű felügyeletre, vagy egyéni karbantartási időszakot is meghatározhat, hogy minimálisra csökkentse az üzleti műveletekre gyakorolt hatást. Ütemezze a karbantartást alacsony tevékenységű időszakokban az üzleti hatás minimalizálása érdekében. További információ: Karbantartás ütemezése.

• Újrapróbálkozásos logika implementálása: Győződjön meg arról, hogy az alkalmazások képesek kezelni a karbantartás újraindítása során esetlegesen fellépő rövid kapcsolatkimaradásokat. Ha az alkalmazásokat rugalmassá szeretné tenni az ilyen típusú problémákhoz, tekintse meg az átmeneti hibák rugalmasságával kapcsolatos útmutatót .

Szolgáltatásiszint-szerződés

Az Azure-szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell a rendelkezésre állási elvárás eléréséhez. További információ: SLA-k az online szolgáltatásokhoz.

Az Azure Database for PostgreSQL a kiszolgáló konfigurációja alapján különböző rendelkezésre állási SLA-kat biztosít:

• A zónaredundáns magas rendelkezésre állással konfigurált kiszolgálók 99,99%üzemidős SLA-t kínálnak.
• A zónaszintű magas rendelkezésre állással konfigurált kiszolgálók 99,95%üzemidős SLA-t kínálnak.
• A magas rendelkezésre állás nélkül konfigurált kiszolgálók 99,9-%üzemidős SLA-t kínálnak.

Kapcsolódó tartalom

• Azure-megbízhatóság
• Ajánlott architektúrakezelési eljárások az Azure Database for PostgreSQL-hez
• Az Azure Database for PostgreSQL üzletmenet-folytonosságának áttekintése
• Geo-vészhelyreállítás az Azure Database for PostgreSQL-ben
• Azure Database for PostgreSQL rugalmassági megoldásgyorsító – Terraform-szkriptek a cikkben ismertetett rugalmassági és helyreállíthatósági alapelvek implementálásához.