Az üzletmenet-folytonosság áttekintése önálló Azure Database for PostgreSQL-kiszolgálóval

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Azure Database for PostgreSQL – Önálló kiszolgáló

Fontos

Azure Database for PostgreSQL – Az önálló kiszolgáló a kivezetési útvonalon van. Határozottan javasoljuk, hogy frissítsen az Azure Database for PostgreSQL rugalmas kiszolgálóra. A rugalmas Azure Database for PostgreSQL-kiszolgálóra való migrálással kapcsolatos további információkért lásd: Mi történik az önálló Azure Database for PostgreSQL-kiszolgálóval?

Ez az áttekintés azOkat a képességeket ismerteti, amelyeket az Azure Database for PostgreSQL biztosít az üzletmenet folytonosságához és a vészhelyreállításhoz. Megtudhatja, hogyan állíthatók helyre olyan zavaró események, amelyek adatvesztést okozhatnak, vagy amelyek az adatbázis és az alkalmazás elérhetetlenné válását okozhatják. Megtudhatja, hogy mi a teendő, ha egy felhasználó vagy alkalmazás hibája hatással van az adatintegritásra, egy Azure-régió leáll, vagy az alkalmazás karbantartást igényel.

Az üzletmenet-folytonosság biztosításához használható funkciók

Az üzletmenet-folytonossági terv kidolgozása során tisztában kell lennie azzal, hogy az alkalmazás a zavaró esemény után maximálisan elfogadható ideig áll helyre – ez a helyreállítási idő célkitűzése (RTO). Azt is meg kell értenie, hogy az alkalmazás mennyi legutóbbi adatfrissítést (időintervallumot) képes elviselni, ha a zavaró esemény utáni helyreállítás során veszít – ez a helyreállítási pont célkitűzése (RPO).

Az Azure Database for PostgreSQL olyan üzletmenet-folytonossági funkciókat kínál, mint a georedundáns visszaállítást lehetővé tévő georedundáns biztonsági másolatok, és a különböző régiókban üzembe helyezhető olvasási replikák. Ezek mindegyike más jellemzőkkel bír a helyreállítási idő és a potenciális adatvesztés tekintetében. A Georedundáns visszaállítás funkcióval egy új kiszolgáló jön létre egy másik régióból replikált biztonsági mentési adatokkal. A visszaállításhoz és helyreállításhoz szükséges teljes idő az adatbázis méretétől és a helyreállítani kívánt naplók mennyiségétől függ. A kiszolgáló teljes üzembe helyezése néhány perctől több óráig is eltarthat. Olvasási replikáknál az elsődleges tranzakciónaplók aszinkron módon lesznek streamelve a replikára. Ha az elsődleges adatbázis zónaszintű vagy régiószintű hiba miatt leáll, a replikára való feladatátvétel rövidebb RTO-t és kevesebb adatvesztést eredményez.

Feljegyzés

Az elsődleges és a replika közötti késés a helyek közötti késéstől, az továbbítandó adatok mennyiségétől és ami a legfontosabb az elsődleges kiszolgáló írási számítási feladataitól függ. A nehéz írási számítási feladatok jelentős késést okozhatnak.

Az olvasási replikákhoz használt replikáció aszinkron jellege miatt nem tekinthetők magas rendelkezésre állású (HA) megoldásnak, mivel a magasabb késés magasabb RTO-t és RPO-t jelenthet. Az olvasási replikák csak olyan számítási feladatok esetében működhetnek alternatívaként, amelyeknél a késés a számítási feladat csúcsideje és nem csúcsideje alatt kisebb marad. Ellenkező esetben az olvasási replikák valódi olvasási skálázásra szolgálnak kész nagy számítási feladatokhoz és (vészhelyreállítási) DR-forgatókönyvekhez.

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 Basic Á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 Nem támogatott 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.

Kiszolgáló helyreállítása felhasználói vagy alkalmazáshiba után

A szolgáltatás biztonsági másolatai segítségével helyreállíthatja a kiszolgálót a különböző zavaró eseményekből. A felhasználók véletlenül törölhetnek bizonyos adatokat, véletlenül elvethetnek egy fontos táblát, vagy akár egy teljes adatbázist is elvethetnek. Előfordulhat, hogy egy alkalmazás véletlenül felülírja a jó adatokat az alkalmazás hibája miatt, és így tovább.

Az időponthoz kötött visszaállítással létrehozhatja a kiszolgáló másolatát egy ismert időpontra. Ennek az időpontnak a kiszolgálóhoz konfigurált biztonsági mentési megőrzési időszakon belül kell lennie. Miután visszaállította az adatokat az új kiszolgálóra, lecserélheti az eredeti kiszolgálót az újonnan visszaállított kiszolgálóra, vagy átmásolhatja a szükséges adatokat a visszaállított kiszolgálóról az eredeti kiszolgálóra.

Javasoljuk, hogy az Azure-erőforrás-zárolás használatával megelőzze a kiszolgáló véletlen törlését. Ha véletlenül törölte a kiszolgálót, lehetséges, hogy vissza tudja állítani, ha a törlés az elmúlt 5 napon belül történt. További információ: Elvetett Azure Database for PostgreSQL-kiszolgáló visszaállítása.

Helyreállítás egy Azure-adatközpont kimaradása után

Bár ritka, mégis előfordulhat, hogy valamelyik Azure-adatközpont leáll. Ha kimaradás történik, az olyan üzleti fennakadásokat okoz, amelyek csak néhány percig tarthatnak, de órákig tarthatnak.

Az egyik lehetőség az, hogy megvárja, amíg a kiszolgáló újra online állapotba kerül, amikor az adatközpont kimaradásának vége. Ez olyan alkalmazások esetében működik, amelyek megengedhetik maguknak, hogy a kiszolgáló bizonyos ideig offline állapotban legyen, például egy fejlesztői környezetben. Ha egy adatközpont leáll, nem tudja, hogy mennyi ideig tarthat a kimaradás, ezért ez a lehetőség csak akkor működik, ha egy ideig nincs szüksége a kiszolgálóra.

Georedundáns visszaállítás

A georedundáns visszaállítási funkció georedundáns biztonsági másolatok használatával állítja vissza a kiszolgálót. A biztonsági másolatok a kiszolgáló párosított régiójában vannak tárolva. Ezekből a biztonsági másolatokból bármely más régióba visszaállítható. A georedukció létrehoz egy új kiszolgálót a biztonsági másolatokból származó adatokkal. További információ a georedukcióról a biztonsági mentési és visszaállítási fogalmakról szóló cikkben.

Fontos

A georedundáns visszaállítás csak akkor lehetséges, ha a kiszolgálót georedundáns biztonsági mentési tárhellyel állította ki. Ha helyileg redundánsról georedundáns biztonsági mentésre szeretne váltani egy meglévő kiszolgáló esetében, akkor a meglévő kiszolgáló pg_dump használatával kell memóriaképet készítenie, és vissza kell állítania egy georedundáns biztonsági mentésekkel konfigurált újonnan létrehozott kiszolgálóra.

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

Régiók közötti olvasási replikákkal javíthatja az üzletmenet-folytonosságot és a vészhelyreállítás tervezését. 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ó az olvasási replikákról, az elérhető régiókról és a feladatátvételről az olvasási replikák alapfogalmairól szóló cikkben.

GYIK

Hol tárolja az Azure Database for PostgreSQL az ügyféladatokat?

Alapértelmezés szerint az Azure Database for PostgreSQL nem helyezi át vagy tárolja az ügyféladatokat az üzembe helyezett régióból. Az ügyfelek azonban dönthetnek úgy, hogy engedélyezik a georedundáns biztonsági mentéseket, vagy régiók közötti olvasási replikát hoznak létre az adatok egy másik régióban való tárolásához.

Következő lépések