Az Azure Database for MariaDB üzletmenet-folytonosságának áttekintése

Fontos

Az Azure Database for MariaDB a nyugdíjazási útvonalon van. Határozottan javasoljuk, hogy migráljon az Azure Database for MySQL-be. További információ az Azure Database for MySQL-be való migrálásról: Mi történik az Azure Database for MariaDB-vel?

Ez a cikk az Azure Database for MariaDB üzletmenet-folytonossági és vészhelyreállítási funkcióit ismerteti. 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ói hiba vagy alkalmazáshiba hatással van az adatintegritásra, egy Azure-régió leáll, vagy az alkalmazás karbantartást igényel.

Az üzletmenet-folytonosság funkciói

Az üzletmenet-folytonossági terv kidolgozása során ismernie kell az alábbiakat:

• Helyreállítási idő célkitűzése (RTO):A maximális elfogadható idő, amíg az alkalmazás teljesen helyreáll egy zavaró esemény után.
• Helyreállítási pont célkitűzése (RPO):Az alkalmazás által a zavaró esemény utáni helyreállítás során a legutóbbi adatfrissítések (időintervallum) maximális mennyisége.

Az Azure Database for MariaDB olyan üzletmenet-folytonossági és vészhelyreállítási funkciókat biztosít, amelyek georedundáns biztonsági mentéseket tartalmaznak, amelyekkel georedundáns visszaállítást kezdeményezhet, és olvasási replikákat helyezhet üzembe 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ással az Azure Database for MariaDB egy új kiszolgálót hoz létre egy másik régióból replikált biztonsági mentési adatok használatával. A visszaállítás és helyreállítás teljes időtartama az adatbázis méretétől és a helyreállítandó naplóadatok 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ák használatakor az elsődleges adatbázis tranzakciónaplói aszinkron módon streamelhetők egy replikába. Ha zónaszintű vagy régiószintű hiba miatt az elsődleges adatbázis leáll, a replikára való feladatátvétel rövidebb RTO-t és kevesebb adatvesztést eredményez.

Megjegyzés:

Az elsődleges adatbázis é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 ne tekintse az olvasási replikákat magas rendelkezésre állású megoldásnak. A nagyobb késés magasabb RTO-t és RPO-t jelenthet. Az olvasási replikák csak olyan számítási feladatok esetén használhatók magas rendelkezésre állású alternatívaként, ahol a késés a csúcsidőn kívül és a csúcsidőn kívül is kisebb marad. Ellenkező esetben az olvasási replikák valódi olvasási skálázásra szolgálnak az írásvédett számítási feladatokhoz és vészhelyreállítási 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:

Funkció	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 Az RTO változó Az RPO kevesebb, mint 15 perc	Bármely visszaállítási pont a megőrzési időszakon belül Az RTO változó Az RPO kevesebb, mint 15 perc	Bármely visszaállítási pont a megőrzési időszakon belül Az RTO változó Az RPO kevesebb, mint 15 perc
Georedukált biztonsági másolatok georedukált visszaállítása	Not supported	Az RTO változó Az RPO több mint 24 óra	Az RTO változó Az RPO több mint 24 óra
Olvasási replikák	Az RTO perc Az RPO kevesebb, mint 5 perc	Az RTO perc Az RPO kevesebb, mint 5 perc	Az RTO perc Az RPO kevesebb, mint 5 perc

Az RTO és az RPO bizonyos esetekben sokkal magasabb lehet, olyan tényezőktől függően, mint a helyek közötti késés, a továbbítandó adatok mennyisége és az elsődleges adatbázis írási számítási feladatai.

Kiszolgáló helyreállítása felhasználó- 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. Előfordulhat például, hogy egy felhasználó véletlenül töröl néhány adatot, véletlenül elvet egy fontos táblát, vagy akár egy teljes adatbázist is elvet. Előfordulhat, hogy egy alkalmazás egy alkalmazáshiba miatt véletlenül felülírja a rossz adatokkal rendelkező jó adatokat.

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ókat csak a törlést követő öt napon belül állíthatja vissza. Öt nap elteltével a biztonsági másolatok törlődnek. Az adatbázis biztonsági mentését csak a kiszolgálót üzemeltető Azure-előfizetésből érheti el és állíthatja 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életlen törléssel vagy a telepítés utáni váratlan módosításokkal szembeni védelme érdekében 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, az Azure-adatközpontok kimaradásokat okozhatnak. 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 véget ér. Ha az adatközpont leáll, nem tudja, hogy mennyi ideig tarthat a kimaradás. Ez a lehetőség tehát csak olyan alkalmazások esetében működik, amelyek megengedhetik maguknak, hogy a kiszolgálót egy ideig offline állapotban legyenek (például fejlesztési környezet).

Geo-restore

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ót futtató 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, majd újra online állapotba helyezheti a kiszolgálót. A biztonsági mentési és visszaállítási fogalmakról a cikkben további információt talál a georedukcióról.

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, a mysqldump használatával létre kell hoznia a meglévő kiszolgáló biztonsági másolatát. Ezután térjen vissza egy újonnan létrehozott kiszolgálóra, amely georedundáns biztonsági mentésekkel van konfigurálva.

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

Régiók közötti olvasási replikákkal növelheti az üzletmenet-folytonosság és a vészhelyreállítás tervezését. Az olvasási replikák Aszinkron módon frissülnek a MySQL bináris naplók replikációs technológiájával. 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 replikafogalmakról szóló cikkben.

GYIK

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

Az Azure Database for MariaDB alapértelmezés szerint nem helyezi át vagy tárolja az ügyféladatokat azon a régión kívül, ahol az üzembe lett helyezve. Dönthet azonban úgy is, hogy engedélyezi a georedundáns biztonsági mentéseket, vagy régiók közötti olvasási replikákat hoz létre az adatok egy másik régióban való tárolásához.

További lépések

• További információ az Azure Database for MariaDB automatikus biztonsági mentéseiről.
• Megtudhatja, hogyan állíthatja vissza az Azure Portal vagy az Azure CLI használatával.
• További információ az Azure Database for MariaDB olvasási replikáiról.