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

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ási é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 lehet Azure Database for PostgreSQL rugalmassá tenni a különböző lehetséges kimaradásokkal és problémákkal szemben, 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 a Azure Database for PostgreSQL szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Ha tudni szeretné, hogyan helyezhet üzembe Azure Database for PostgreSQL a megoldás megbízhatósági követelményeinek támogatásához, és hogyan befolyásolja a megbízhatóság az architektúra egyéb aspektusait, tekintse meg az architektúrával kapcsolatos ajánlott eljárásokat Azure Database for PostgreSQL az Azure Well-Architected-keretrendszerben.

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

A Azure Database for PostgreSQL használatakor üzembe helyez egy kiszolgálót, amely a kiszolgálón üzembe helyezendő adatbázisok támogatásához szükséges számítási és tárolási erőforrásokat jelöli.

A kiszolgálókat több számítási szinten is üzembe helyezheti: Burstable, General Purpose és Memory Optimized. Minden szint 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 üzembe helyezési modellekről további információt Azure Database for PostgreSQL áttekintésében talál.

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 linuxos virtuális gépen fut, míg Azure Storage tárolja az adatfájlokat, és három helyileg redundáns szinkron másolatot tárol az adatbázisfájlokról az adatok tartósságának biztosítása érdekében.

• Magas rendelkezésre állás: 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ó szinkron módon replikálja az adatváltozásokat 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 képes kezelni 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.

  

  Diagram a Azure Database for PostgreSQL magas rendelkezésre állású architektúrájáról. Két kiszolgáló egymás mellett van. A bal oldalon egy elsődleges kiszolgáló címkével ellátott mező látható, benne pedig egy virtuális gép és egy lemez. A jobb oldalon található egy egyező, készenléti kiszolgáló címkével ellátott mező, amely egy virtuális gépet és egy lemezt is tartalmaz. Egy vízszintes nyíl a bal oldali elsődleges kiszolgálóról a jobb oldali készenléti kiszolgálóra mutat, a nyíl pedig streamelési replikációra van címkézve, amely egyirányú kapcsolatot jelez, ahol az adatok az elsődleges kiszolgálóról a készenléti kiszolgálóra áramlanak.

  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 létezik: 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 minimalizálnia kell az alkalmazás állásidejét.

  Amikor olyan műveleteket hajt végre, mint a leállítás, az indítás és az újraindítás, azok egyszerre fordulnak elő az elsődleges és a készenléti adatbázis-kiszolgálókon is. A tervezett események, például a számítási skálázás és a tárterület skálázása először a készenléti gépen, majd az elsődleges kiszolgálón történik. 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.

Válassza ki a rendelkezésre állási zóna támogatási típusát a magas rendelkezésre állású konfigurációval. Ha engedélyezi a magas rendelkezésre állást, a szolgáltatás üzembe helyez egy készenléti kiszolgálót az elsődleges kiszolgáló mellett. Ez a magas rendelkezésre állású 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ú üzembehelyezési modellt is használja a kiszolgáló, szinkron módon véglegesíti az adatokat az elsődleges és a készenléti kiszolgálókon 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.

Minden rendelkezésre állási zóna adatfájlokat és írási naplókat (WALs) tárol a helyileg redundáns tárolással (LRS) rendelkező prémium szintű felügyelt lemezeken, amelyek automatikusan három adatpéldányt tárolnak 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ődleges kiszolgálóhoz 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.

  

  A rendelkezésre állási zónák között elosztott, zónaredundáns Azure Database for PostgreSQL konfigurációját bemutató ábra. A lista tetején három zóna látható: az 1. rendelkezésre állási zóna, a 2. rendelkezésre állási zóna és a 3. rendelkezésre állási zóna. Az 1. rendelkezésre állási zónában egy elsődleges kiszolgáló címkével ellátott mező található, a mezőben pedig egy virtuális gép és egy lemez látható, amely azt mutatja, hogy az elsődleges kiszolgáló számításból és tárolásból áll. A 2. rendelkezésre állási zónában található egy megfelelő, készenléti kiszolgáló címkével ellátott mező, amely egy virtuális gépet és egy lemezt is tartalmaz. A két kiszolgálódoboz között egy „streaming replikáció” feliratú, jobbra mutató nyíl látható, amely azt mutatja, hogy az adatváltozások a bal oldali elsődleges kiszolgálóról a jobb oldali készenléti kiszolgálóra áramlanak. Az elrendezés a zónák közötti rugalmasságot kommunikálja: az elsődleges és a készenléti zónák két rendelkezésre állási zónára vannak elválasztva, míg a 3. rendelkezésre állási zóna továbbra sem használható.

  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.

  

  Egy zonális Azure Database for PostgreSQL beállítását bemutató ábra egyetlen rendelkezésre állási zónában. Három zóna látható: az 1. rendelkezésre állási zóna, a 2. rendelkezésre állási zóna és a 3. rendelkezésre állási zóna. Az 1-es rendelkezésre állási zónában két doboz van egymás mellett. A bal oldali mező az elsődleges kiszolgáló címkével van ellátva, a dobozon belül pedig egy virtuális gép és egy lemez található. A jobb oldali mező készenléti kiszolgálóként van megjelölve, a dobozon belül pedig egy virtuális gép és egy lemez található. A két kiszolgálódoboz között egy „streaming replikáció” feliratú, jobbra mutató nyíl látható, amely azt mutatja, hogy az adatváltozások a bal oldali elsődleges kiszolgálóról a jobb oldali készenléti kiszolgálóra áramlanak. Mindkét kiszolgáló ugyanabban a rendelkezésre állási zónában található. A 2. rendelkezésre állási zóna és a 3. rendelkezésre állási zóna nincs használatban.

  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 a 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, majd 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.

  A kiszolgálók ugyanabban a zónában való elhelyezése csökkentheti az írási késést az ugyanazon a zónán belül üzembe helyezett alkalmazásoknál.

  Ha a kiszolgálók ugyanabban a zónában vannak, az ugyanazon a zónán belül üzembe helyezendő alkalmazások írási késése csökkenthető.

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: Azure Database for PostgreSQL különböző módon támogatja a rendelkezésre állási zónák konfigurációit Azure régiókban. A régiók teljes listáját, a rendelkezésre állási zónák támogatásának típusait és az egyes régiókra vonatkozó konkrét szempontokat lásd Azure régiókat.

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

  Számítási szint	zóna redundáns	Zonal (azonos zónában)
  Időszakosan növelhető	Nem támogatott	Nem támogatott
  általános célú	Támogatott	Támogatott
  Memóriára optimalizált	Támogatott	Támogatott

• Szolgáltatási szint: Mindkét magas rendelkezésre állási típushoz általános célú vagy memóriaoptimalizált szint szükséges.

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

A magas rendelkezésre állás engedélyezésekor létrejön egy készenléti kiszolgáló, és a számlázás az elsődleges kiszolgálóéval azonos mértékben 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-kiszolgáló létrehozása.

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

  Az elsődleges vagy 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

  Javasoljuk, hogy várjon, amíg a kiszolgálói tevékenység alacsony lesz, mielőtt módosítja a magas rendelkezésre állású 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 magas rendelkezésre állású és rendelkezésre állási zónával rendelkező kiszolgálókat konfigurál, é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. Azure Database for PostgreSQL aktív-passzív konfigurációt használ, ahol az elsődleges rendelkezésre állási zónában lévő elsődleges kiszolgáló kezeli az összes adatbázis-kapcsolatot és lekérdezést. 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 elsődleges kiszolgáló szinkron módon replikálja a módosításokat a készenléti kiszolgálóra. 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.

  Amikor egy alkalmazás adatokat ír és véglegesíti, a PostgreSQL először rögzíti a változást a WAL-ban az elsődleges kiszolgálón. Az elsődleges kiszolgáló a PostgreSQL streamelési protokoll használatával streameli ezeket a naplókat a készenléti kiszolgálóra. Miután a készenléti kiszolgáló tartósan tárolja a WAL-t, az elsődleges kiszolgáló megerősíti az írást. 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. A legtöbb alkalmazás esetében a további késés 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. Az ilyen típusú hibák helyreállításához nem használhatja a készenléti kiszolgálót, és a biztonsági másolatból egy adott időpontra történő 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 magas rendelkezésre állású és rendelkezésre állási zónával rendelkező kiszolgálókat konfigurál, és a rendelkezésre állási zóna kimarad.

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

  Ha egy rendelkezésre állási zóna meghibásodik, 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ású állapottípusok megtekintéséhez tekintse meg a magas rendelkezésre állás (HA) állapotfigyelését. 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 magas rendelkezésre állású 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, hogy proaktív hibaelhárítást végezzen, és segítsen fenntartani az adatbázis üzemidejét és teljesítményét.

  A HA állapotállapotainak konfigurálásáról és értelmezéséről részletes útmutatót a magas rendelkezésre állású (HA) á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 van egy különálló kiszolgálója, amelyet előzetesen egy másik rendelkezésre állási zónában vagy régióban hozott létre, Ön felelős a forgalom erre a 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 szükségtelen fennakadás elkerülése érdekében a szolgáltatás nem helyezi vissza automatikusan az elsődleges szerepkört az eredeti zónába. 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 gyártási 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 szimulálhat teljes zónakimaradást, szimulálhatja, hogy a kiszolgáló nem érhető el a zónakimaradáshoz hasonló módon. 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.

Diagram, amelynek tetején egy alkalmazás látható. Közvetlenül alatta található egy írás-olvasási végpont címkével ellátott mező. Egy lefelé mutató nyíl található az alkalmazástól a végpontig, amely azt mutatja, hogy az alkalmazás először erre a végpontra küldi az adatbázis-forgalmat. A diagram alsó fele két nagy területre oszlik. A bal oldalon található az elsődleges régió. Ebben a régióban van egy elsődleges kiszolgáló címkével ellátott mező, a mezőben pedig a szolgáltatásnév Azure Database for PostgreSQL kiszolgáló. A jobb oldalon a másodlagos régió található. Ebben a régióban található egy megfelelő kiszolgálódoboz, amelyen a „read replica promoted primary server” felirat látható, valamint az „Azure Database for PostgreSQL server” címke is szerepel. Egy nyíl fut az olvasási-írási végponttól az elsődleges kiszolgálóig. A bal oldali elsődleges kiszolgálóról a jobb oldali másodlagos régióban lévő kiszolgálóra egy szaggatott vízszintes nyíl fut, amely azt mutatja, hogy az adatváltozások az elsődlegesről a replikára másolódnak.

Ha az elsődleges régió meghibásodik, előléptetést indíthat el, hogy a másodlagos replika legyen az elsődleges. Attól függően, hogyan használja az olvasási replikákat, különböző failover-típusok lehetnek megfelelőek. 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.

Diagram egy alkalmazásról, amely a legfelső helyen küld adatokat egy olvasási-írási végponton keresztül. A diagram alsó fele két nagy területre oszlik. A bal oldalon található az elsődleges régió. Ebben a régióban van egy elsődleges kiszolgáló címkével ellátott mező, a mezőben pedig a szolgáltatásnév Azure Database for PostgreSQL kiszolgáló. Van egy x az elsődleges régión, ami azt jelzi, hogy már nem aktív. A jobb oldalon a másodlagos régió található. Ebben a régióban található egy megfelelő kiszolgálódoboz, amelyen a „read replica promoted primary server” felirat látható, valamint az „Azure Database for PostgreSQL server” címke is szerepel. Egy nyíl fut az olvasási-írási végponttól a másodlagos régióig. Az elsődleges régióból a másodlagos régióba futó aszinkron replikáció szaggatott vízszintes nyíllal van lefedve, amely azt jelzi, hogy a replikáció már nem aktív.

Megjegyzés:

Ez a szakasz összefoglal néhány fontos információt arról, hogy az olvasási replikák hogyan támogatjá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. Nem korlátozódik az Azure-beli párosított régiókra.

• 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 szükséges beállítások konfigurálását a feladatátvétel után. 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 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 folyamat egyéb megfontolandó tényezőiért tekintse meg a szempontokat.

Cost

Az olvasási replikák számítási és tárolási költségekkel járnak, valamint régiók közötti adatátviteli díjakat 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. Az elsődleges kiszolgáló létrehozása után konfigurálhatja a replikákat, 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ához 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 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 előléptetési folyamat megszakítja az elsődleges régióhoz tartozó összes aktív kapcsolatot. Az előléptetési folyamat befejeződése után az alkalmazásoknak újra meg kell próbálkoznia az előléptetett replikával való kapcsolatok létesítésével.

• 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 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 a read replica előléptetési eljárásokat, és győződjön meg arról, hogy ezek a képességek megfelelnek a helyreállításiidő-célkitűzésre (RTO) és a helyreállításipont-célkitűzésre (RPO) vonatkozó 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 gyártási 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. A tervezett előléptetés azonban más folyamatot követ, mint a régiókimaradás során történő előléptetés, így előfordulhat, hogy nem tükrözi a valódi régiókimaradások viselkedését.

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

Azure Database for PostgreSQL automatikusan biztonsági másolatot készít az adatokról. Ezek a biztonsági másolatok időszerű helyreállítási képességeket biztosítanak, és segítenek védelmet nyújtani az adatok véletlen sérülése és törlése ellen. Microsoft teljes mértékben felügyeli a biztonsági mentéseket. Nem szakítják meg a kiszolgáló rendelkezésre állását, és a teljes biztonsági mentést és a tranzakciónapló biztonsági mentését is tartalmazzák.

• Biztonsági mentési tár: Ha a kiszolgálót rendelkezésre állási zónákkal rendelkező régióban helyezi üzembe, a szolgáltatás zónaredundáns tárolóban (ZRS) tárolja a biztonsági mentéseket, függetlenül a kiszolgáló magas rendelkezésre állási konfigurációtól. A rendelkezésre állási zónák nélküli régiókban üzembe helyezett kiszolgálók esetében a szolgáltatás helyileg redundáns tárolóban (LRS) tárolja a biztonsági mentéseket.

  A párokkal rendelkező Azure régiókban úgy konfigurálhatja a georedundáns biztonsági mentési tárolót a kiszolgáló létrehozásakor, hogy a biztonsági másolatokat a Azure párosított régióba replikálja a régióhibák elleni fokozott védelem érdekében. A szolgáltatás aszinkron módon replikálja a biztonsági mentéseket.

  Az alapértelmezett biztonsági mentési megőrzési időszak hét nap, de a megőrzést akár 35 napra is 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. Használhatja az új kiszolgálót as-is, vagy adatokat másolhat belőle.

  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

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ónak újra kell indulnia a frissítési folyamat részeként. Ha engedélyezi a magas rendelkezésre állást, a karbantartási műveletek általában gördülő 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 csomópontot elsődlegessé léptetik elő, hogy a munkaterhelések az elsődlegessé tett csomóponton folytatódhassanak, miközben a karbantartási feladatokat a másik csomóponton végzik el. 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 az üzleti műveletekre gyakorolt hatás minimalizálása érdekében. Ü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.

Azure Database for PostgreSQL a kiszolgáló konfigurációjától függően 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
• Terraform-szkriptek a rugalmassági és helyreállíthatósági alapelvek implementálásához