Áttekintés az Azure Database for PostgreSQL - Flexible Server szolgáltatással biztosított üzletmenet-folytonosságról
A következőkre vonatkozik:
Azure Database for PostgreSQL – Rugalmas kiszolgáló
A rugalmas Azure Database for PostgreSQL-kiszolgálón az üzletmenet folytonossága azokra a mechanizmusokra, szabályzatokra és eljárásokra utal, amelyek lehetővé teszik, hogy a vállalat továbbra is zavartalanul működjön, különösen a számítási infrastruktúrája számára. A legtöbb esetben a rugalmas Azure Database for PostgreSQL-kiszolgáló kezeli a felhőkörnyezetben előforduló zavaró eseményeket, és folyamatosan futtatja az alkalmazásokat és az üzleti folyamatokat. Vannak azonban olyan események, amelyek nem kezelhetők automatikusan, például:
- A felhasználó véletlenül töröl vagy frissít egy sort egy táblában.
- A földrengés áramkimaradást okoz, és ideiglenesen letilt egy rendelkezésre állási zónát vagy régiót.
- Hiba vagy biztonsági probléma megoldásához adatbázis-javítás szükséges.
A rugalmas Azure Database for PostgreSQL-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 rugalmas Azure Database for PostgreSQL-kiszolgáló a robusztus rugalmasságot és rendelkezésre állást biztosító Azure-infrastruktúrára épülve olyan üzletmenet-folytonossági funkciókkal rendelkezik, amelyek egy másik hibavédelmet, a helyreállítási idő követelményeinek kezelését és az adatveszteség-kitettség csökkentését biztosítják. 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.
Az alábbi táblázat az Azure Database for PostgreSQL rugalmas kiszolgáló által kínált funkciókat mutatja be.
| Szolgáltatás | Leírás | Megfontolások |
|---|---|---|
| Automatikus biztonsági mentések | A rugalmas Azure Database for PostgreSQL-kiszolgáló automatikusan elvégzi az adatbázisfájlok napi biztonsági mentését, és folyamatosan biztonsági másolatot készít a tranzakciónaplókról. A biztonsági másolatok 7–35 napig őrizhetők meg. Az adatbázis-kiszolgálót bármikor visszaállíthatja a biztonsági mentés megőrzési időszakán belül. Az RTO függ a visszaállítandó adatok méretétől + a napló-helyreállítás elvégzéséhez szükséges időtől. Ez néhány perctől akár 12 óráig is eltarthat. További részletekért lásd a Fogalmak – Biztonsági mentés és visszaállítás című témakört. | A biztonsági mentési adatok a régión belül maradnak. |
| Zónaredundáns magas rendelkezésre állás | A rugalmas Azure Database for PostgreSQL-kiszolgáló zónaredundáns magas rendelkezésre állású (HA) konfigurációval telepíthető, ahol az elsődleges és a készenléti kiszolgálók egy régió két különböző rendelkezésre állási zónájában vannak üzembe helyezve. Ez a HA-konfiguráció védi az adatbázisokat a zónaszintű 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. Az RTO a legtöbb esetben várhatóan 120-nál kevesebb lesz. Az RPO várhatóan nulla (nincs adatvesztés). További információ: Fogalmak – Magas rendelkezésre állás. | Általános célú és memóriaoptimalizált számítási szintek támogatják. Csak olyan régiókban érhető el, ahol több zóna is elérhető. |
| Azonos zóna magas rendelkezésre állása | A rugalmas Azure Database for PostgreSQL-kiszolgáló ugyanazon zóna magas rendelkezésre állású (HA) konfigurációval telepíthető, ahol az elsődleges és a készenléti kiszolgálók ugyanabban a rendelkezésre állási zónában vannak üzembe helyezve egy régióban. Ez a HA-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. Az RTO a legtöbb esetben várhatóan 120-nál kevesebb lesz. Az RPO várhatóan nulla (nincs adatvesztés). További információ: Fogalmak – Magas rendelkezésre állás. | Általános célú és memóriaoptimalizált számítási szintek támogatják. |
| Prémium szintű felügyelt lemezek | Az adatbázisfájlok tárolása egy rendkívül tartós és megbízható, prémium szinten felügyelt tárolóban történik. Ez hárompéldányos adatredundanciát biztosít a rendelkezésreállási zónában tárolt replikákkal, automatikus adat-helyreállítási képességekkel. További információ: Felügyelt lemezek dokumentációja. | Rendelkezésre állási zónában tárolt adatok. |
| Zónaredundáns biztonsági mentés | A rugalmas Azure Database for PostgreSQL-kiszolgálók biztonsági mentései automatikusan és biztonságosan tárolódnak egy régión belüli zónaredundáns tárolóban, ha a régió támogatja a rendelkezésre állási zónákat. Zónaszintű hiba esetén, ahol a kiszolgáló ki van építve, és ha a kiszolgáló nincs zónaredundanciával konfigurálva, akkor is visszaállíthatja az adatbázist egy másik zóna legújabb visszaállítási pontjával. További információ: Alapfogalmak – Biztonsági mentés és visszaállítás. | Csak olyan régiókban alkalmazható, ahol több zóna is elérhető. |
| Georedundáns biztonsági mentés | A rugalmas Azure Database for PostgreSQL-kiszolgáló biztonsági másolatait a rendszer egy távoli régióba másolja. amely segít vészhelyreállítási helyzetben abban az esetben, ha az elsődleges kiszolgáló régiója le van állítva. | Ez a funkció jelenleg engedélyezve van a kijelölt régiókban. A visszaállításhoz szükséges adatok méretétől és a végrehajtandó helyreállítás mennyiségétől függően hosszabb RTO és magasabb RPO szükséges. |
| Replika olvasása | 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 aSzinkron módon frissülnek a PostgreSQL fizikai replikációs technológiájával, és előfordulhat, hogy az elsődleges példány nem lesz elérhető. További információ: Fogalmak – Replikák olvasása. | Általános célú és memóriaoptimalizált számítási szintek támogatják. |
Az alábbi táblázat az RTO-t és az RPO-t hasonlítja össze egy tipikus számítási feladat forgatókönyvében:
| Képesség | Kipukkanható | Általános célú | Memóriaoptimalizált |
|---|---|---|---|
| Időponthoz kötött visszaállítás biztonsági másolatból | Bármely visszaállítási pont a megőrzési időszakon belül RTO – Változó RPO < 15 perc |
Bármely visszaállítási pont a megőrzési időszakon belül RTO – Változó RPO < 15 perc |
Bármely visszaállítási pont a megőrzési időszakon belül RTO – Változó RPO < 15 perc |
| Georedukált biztonsági másolatok georedukált visszaállítása | RTO – Változó RPO < 1 h |
RTO – Változó RPO < 1 h |
RTO – Változó RPO < 1 h |
| Olvasási replikák | RTO – percek* RPO < 5 perc* |
RTO – percek* RPO < 5 perc* |
RTO – percek* RPO < 5 perc* |
* Az RTO és az RPO bizonyos esetekben sokkal magasabb lehet a különböző tényezőktől függően, például a helyek közötti késéstől, a továbbítandó adatok mennyiségétől és a legfontosabb elsődleges adatbázis-írási számítási feladatoktól függően.
Tervezett leállási események
Az alábbiakban néhány tervezett karbantartási forgatókönyvet talál. Ezek az események általában néhány percnyi állásidőt és adatvesztést okoznak.
| Forgatókönyv | Folyamat |
|---|---|
| Számítási skálázás (felhasználó által kezdeményezett) | A számítási skálázási művelet során az aktív ellenőrzőpontok befejeződhetnek, az ügyfélkapcsolatok kiüríthetők, a nem véglegesített tranzakciók megszakadnak, a tárterület le lesz választva, majd le lesz állítva. A rugalmas Azure Database for PostgreSQL-kiszolgáló egy új, azonos adatbázis-kiszolgálónévvel rendelkező példányát a rendszer a méretezési számítási konfigurációval építi ki. A tároló ezután az új kiszolgálóhoz lesz csatolva, és elindul az adatbázis, amely szükség esetén helyreállítást végez az ügyfélkapcsolatok elfogadása előtt. |
| Tárterület vertikális felskálázása (felhasználó által kezdeményezett) | A tárterület felskálázási műveletének indításakor az aktív ellenőrzőpontok befejeződhetnek, az ügyfélkapcsolatok kiüríthetők, és a nem véglegesített tranzakciók megszakadnak. Ezt követően a kiszolgáló leáll. A tárterület a kívánt méretre van skálázva, majd az új kiszolgálóhoz van csatolva. Szükség esetén helyreállítást hajtunk végre az ügyfélkapcsolatok elfogadása előtt. Vegye figyelembe, hogy a tárterület méretének leskálázása nem támogatott. |
| Új szoftvertelepítés (Azure által kezdeményezett) | Az új szolgáltatások bevezetése vagy hibajavításai automatikusan a szolgáltatás tervezett karbantartása részeként történnek, és ütemezheti, hogy mikor történjenek ezek a tevékenységek. További információt a portálon talál. |
| Alverziófrissítések (Azure által kezdeményezett) | Az Azure Database for PostgreSQL automatikusan az Azure által meghatározott alverzióra frissíti az adatbázis-kiszolgálókat. Ez a szolgáltatás tervezett karbantartásának részeként történik. Az adatbázis-kiszolgáló automatikusan újraindul az új alverzióval. További információért lásd a dokumentációt. A portált is ellenőrizheti. |
Ha a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány magas rendelkezésre állással van konfigurálva, a szolgáltatás először elvégzi a skálázást és a karbantartási műveleteket a készenléti kiszolgálón. További információ: Fogalmak – Magas rendelkezésre állás.
Nem tervezett leállás kezelése
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 Azure Database for PostgreSQL-kiszolgáló úgy segít csökkenteni az állásidőt, hogy automatikusan végrehajtja a helyreállítási műveleteket emberi beavatkozás nélkül.
Bár folyamatosan törekszünk a magas rendelkezésre állásra, vannak olyan időszakok, amikor a rugalmas Azure Database for PostgreSQL-kiszolgáló nem működik, ami az adatbázisok elérhetetlenségét okozza, és így hatással van az alkalmazásra. Ha szolgáltatásfigyelésünk széles körű csatlakozási hibákat, hibákat vagy teljesítményproblémákat okozó problémákat észlel, a szolgáltatás automatikusan leállást deklarál, hogy folyamatosan tájékoztassa Önt.
Szolgáltatáskimaradás
Rugalmas Azure Database for PostgreSQL-kiszolgálókimaradás esetén a szolgáltatáskimaradással kapcsolatos további részleteket az alábbi helyeken tekintheti meg:
- Azure Portal-szalagcím: Ha az előfizetése érintett, szolgáltatáskimaradási riasztás jelenik meg az Azure Portal értesítéseiben.
- Súgó + támogatás vagy támogatás + hibaelhárítás: Ha támogatási jegyet hoz létre a Súgó + támogatás vagy a Támogatás + hibaelhárítás szolgáltatásból, az erőforrásokat érintő problémákról lesz információ. A kimaradás részleteinek megtekintése lehetőséget választva további információkat és a hatás összegzését tekintheti meg. Az Új támogatási kérelem lapon is megjelenik egy riasztás.
- Szolgáltatás súgója: Az Azure Portal Service Health oldala az Azure-adatközpont állapotával kapcsolatos információkat tartalmaz globálisan. Keressen rá a "szolgáltatás állapota" kifejezésre az Azure Portal keresősávján, majd tekintse meg a szolgáltatásproblémákat az Aktív események kategóriában. Az egyes erőforrások állapotát bármely erőforrás Erőforrás állapota lapján, a Súgó menüben tekintheti meg. A Service Health oldal minta képernyőképe, amely egy délkelet-ázsiai aktív szolgáltatásproblémával kapcsolatos információkkal rendelkezik.
- E-mail-értesítés: Ha riasztásokat állított be, e-mailes értesítés érkezik, amikor egy szolgáltatáskimaradás hatással van az előfizetésére és az erőforrására. Az e-mailek a "azure-noreply@microsoft.com" helyről érkeznek. Az e-mail törzse a következővel kezdődik: "A tevékenységnapló riasztása ... az Azure-előfizetés szolgáltatásproblémája váltotta ki...". A szolgáltatásállapot-riasztásokkal kapcsolatos további információkért lásd : Tevékenységnapló-riasztások fogadása az Azure-szolgáltatásértesítéseken az Azure Portal használatával.
Fontos
Ahogy a neve is mutatja, a PostgreSQL ideiglenes táblatereit ideiglenes objektumokhoz, valamint más belső adatbázis-műveletekhez, például rendezéshez használják. Ezért nem javasoljuk a felhasználói sémaobjektumok ideiglenes táblatérben való létrehozását, mivel nem garantáljuk az ilyen objektumok tartósságát a kiszolgáló újraindítása, a HA-feladatátvételek stb. után.
Nem tervezett állásidő: hibaforgatókönyvek és szolgáltatás-helyreállítás
Az alábbiakban néhány nem tervezett hibaforgatókönyv és a helyreállítási folyamat látható.
| Forgatókönyv | Helyreállítási folyamat [Zónaredundáns HA nélkül konfigurált kiszolgálók] |
Helyreállítási folyamat [Zónaredundáns HA-val konfigurált kiszolgálók] |
|---|---|---|
| Adatbázis-kiszolgáló hibája | Ha az adatbázis-kiszolgáló leállt, az Azure megpróbálja újraindítani az adatbázis-kiszolgálót. Ha ez nem sikerül, az adatbázis-kiszolgáló újraindul egy másik fizikai csomóponton. A helyreállítási idő (RTO) különböző tényezőktől függ, például a hiba időpontjában végzett tevékenységtől, például a nagy tranzakciótól, valamint az adatbázis-kiszolgáló indítási folyamata során végrehajtandó helyreállítási mennyiségtől. A PostgreSQL-adatbázisokat használó alkalmazásokat úgy kell létrehozni, hogy észleljék és újrapróbálkozzák az elvetett kapcsolatokat és a sikertelen tranzakciókat. |
Ha az adatbázis-kiszolgáló hibája észlelhető, a kiszolgáló feladatátvétele a készenléti kiszolgálóra történik, ami csökkenti az állásidőt. További információkért tekintse meg a HA fogalmait ismertető oldalt. Az RTO várhatóan 60–120-as, nulla adatvesztéssel. |
| Tárolási hiba | Az alkalmazások nem látnak semmilyen hatást a tárolással kapcsolatos problémákra, például a lemezhiba vagy a fizikai blokk sérülésére. Mivel az adatokat három példányban tárolják, az adatok másolatát a túlélő tár szolgáltatja. A rendszer automatikusan kijavítja a sérült adatblokkot, és automatikusan létrehoz egy új másolatot az adatokról. | Az olyan ritka és nem helyreállítható hibák esetén, mint például a teljes tárterület elérhetetlen, a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány feladatátvétele a készenléti replikára az állásidő csökkentése érdekében. További információkért tekintse meg a HA fogalmait ismertető oldalt. |
| Logikai/felhasználói hibák | A felhasználói hibák, például a véletlenül elvetett táblák vagy a helytelenül frissített adatok helyreállítása érdekében időszerű helyreállítást (PITR) kell végrehajtania. A visszaállítási művelet végrehajtása során meg kell adnia az egyéni visszaállítási pontot, amely a hiba bekövetkezése előtti időpont. Ha az adatbázis-kiszolgáló összes adatbázisa helyett csak az adatbázisok vagy adott táblák egy részét szeretné visszaállítani, visszaállíthatja az adatbázis-kiszolgálót egy új példányban, exportálhatja a táblákat pg_dump keresztül, majd a pg_restore használatával visszaállíthatja ezeket a táblákat az adatbázisba. |
Ezek a felhasználói hibák nem védettek magas rendelkezésre állással, mivel a rendszer az összes módosítást szinkron módon replikálja a készenléti replikára. Az ilyen hibákból való helyreállításhoz időponthoz kötött visszaállítást kell végrehajtania. |
| Rendelkezésreállási zóna meghibásodása | A zónaszintű hibákból való helyreállításhoz a biztonsági mentéssel időponthoz kötött visszaállítást hajthat végre, és kiválaszthat egy egyéni visszaállítási pontot a legújabb időponttal a legújabb adatok visszaállításához. Egy új rugalmas Azure Database for PostgreSQL-kiszolgálópéldány van üzembe helyezve egy másik, nem érintett zónában. A visszaállítás időtartama az előző biztonsági mentéstől és a helyreállítandó tranzakciónaplók mennyiségétől függ. | A rugalmas Azure Database for PostgreSQL-kiszolgáló automatikusan 60–120-on belül automatikusan feladatátvételt ad át a készenléti kiszolgálónak nulla adatvesztéssel. További információkért tekintse meg a HA fogalmait ismertető oldalt. |
| Régióhiba | 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 kiépül egy új kiszolgálóra, és helyreállítja a régióba másolt utolsó rendelkezésre álló adatokat. 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. |
Ugyanaz a folyamat. |
Adatbázis konfigurálása a regionális hiba utáni helyreállítás után
- Ha georedukciós vagy georeplikát használ a kimaradás utáni helyreállításhoz, győződjön meg arról, hogy az új kiszolgálóhoz való csatlakozás megfelelően van konfigurálva, hogy a normál alkalmazásfüggvény újrainduljon. Követheti a visszaállítás utáni feladatokat.
- Ha korábban beállította a diagnosztikai beállításokat az eredeti kiszolgálón, szükség esetén ugyanezt kell tennie a célkiszolgálón is, amint az az Azure Database for PostgreSQL rugalmas kiszolgálójának Konfigurálási és hozzáférési naplói című témakörben leírtak szerint történik.
- A telemetriai riasztások beállításához meg kell győződnie arról, hogy a meglévő riasztási szabály beállításai frissülnek az új kiszolgálóra való leképezéshez. A riasztási szabályokkal kapcsolatos további információkért lásd : Az Azure Portal használatával állíthat be riasztásokat az Azure Database for PostgreSQL – Rugalmas kiszolgáló metrikáihoz.
Fontos
A törölt kiszolgálók visszaállíthatók. Ha törli a kiszolgálót, kövesse útmutatásunkat egy elvetett Azure-adatbázis visszaállítása – Azure Database for PostgreSQL – rugalmas kiszolgáló helyreállítása érdekében. Használja az Azure erőforrás-zárolást a kiszolgálók véletlen törlésének megakadályozásához.