Megosztás a következőn keresztül:

Az üzletmenet folytonosságának áttekintése az Önálló Azure Database for MySQL-kiszolgálóval

  • Cikk

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Ez a cikk azOkat a képességeket ismerteti, amelyeket az Azure Database for MySQL 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 önálló Azure Database for MySQL-kiszolgáló olyan üzletmenet-folytonossági és vészhelyreállítási funkciókat biztosít, amelyek georedundáns biztonsági mentéseket tartalmaznak georedundáns biztonsági mentések kezdeményezésével, valamint olvasási replikák üzembe helyezésével egy másik régióban. 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ás végrehajtásával létrehozhatja a kiszolgáló másolatát egy megfelelő időpont alapján. 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.

Fontos

A törölt kiszolgálók csak a törlést követő öt napon belül állíthatók vissza, amely után a biztonsági másolatok törlődnek. Az adatbázis biztonsági mentése csak a kiszolgálót üzemeltető Azure-előfizetésből érhető el és állítható vissza. Az elvetett kiszolgáló visszaállításához tekintse meg a dokumentált lépéseket. A kiszolgáló erőforrásainak védelme érdekében, az üzembe helyezés után, a véletlen törlés vagy a váratlan módosítások ellen a rendszergazdák felügyeleti zárolásokat használhatnak.

Helyreállítás azure-beli regionális adatközpont-kimaradásból

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 az 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. Ezek a biztonsági másolatok akkor is elérhetők, ha a kiszolgáló által üzemeltetett régió offline állapotban van. Ezekből a biztonsági másolatokból bármely más régióba visszaállíthatja a biztonsági mentéseket, és visszaállíthatja a kiszolgálót az internetre. 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óhoz, akkor a meglévő kiszolgáló mysqldumpjá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 a MySQL bináris naplóreplikációs technológiájával aszinkron módon frissülnek. 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 MySQL az ügyféladatokat?

Alapértelmezés szerint az Azure Database for MySQL 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