Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőkre vonatkozik:
Azure SQL Felügyelt Példány
- Azure SQL Database
- Azure SQL kezelésű példány
Ez a cikk áttekintést nyújt a felügyelt Azure SQL-példány üzletmenet-folytonossági és vészhelyreállítási képességeiről, és ismerteti azokat a lehetőségeket és javaslatokat, amelyek az adatvesztéshez vagy a példány és az alkalmazás elérhetetlenné válásához vezethetnek. Megtudhatja, hogy mi a teendő, ha egy felhasználó vagy alkalmazás hibája hatással van az adatintegritásra, az Azure rendelkezésre állási zónája vagy régiója leáll, vagy az alkalmazás karbantartást igényel.
Áttekintés
Az Azure SQL-kezelt példában az üzletmenet-folytonosság azokra a mechanizmusokra, szabályzatokra és eljárásokra utal, amelyek lehetővé teszik a vállalat számára, hogy zavar esetén is tovább működjön a rendelkezésre állás, a magas rendelkezésre állás és a katasztrófa utáni helyreállítás biztosításával.
A legtöbb esetben a felügyelt SQL-példány kezeli a felhőkörnyezetben esetlegesen előforduló zavaró eseményeket, és folyamatosan futtatja az alkalmazásokat és az üzleti folyamatokat. Vannak azonban olyan zavaró események, amelyekben a kockázatcsökkentés eltarthat egy ideig, például:
- A felhasználó véletlenül töröl vagy frissít egy sort egy táblában.
- A rosszindulatú támadó sikeresen törli az adatokat, vagy elvet egy adatbázist.
- A katasztrofális természeti katasztrófaesemény egy adatközpontot vagy rendelkezésre állási zónát vagy régiót foglal le.
- Ritka adatközpont, rendelkezésre állási zóna vagy régiószintű kimaradás konfigurációváltozás, szoftverhiba vagy hardverösszetevő hibája miatt.
A rendelkezésre állás maximalizálására és a nagyobb üzletmenet-folytonosság elérésére vonatkozó előíró javaslatokért lásd:
- rendelkezésre állási ellenőrzőlista
- Magas rendelkezésre állású ellenőrzőlista
- vészhelyreállítási ellenőrzőlista
Magas rendelkezésre állás
A felügyelt Azure SQL-példány alapvető rugalmassági és megbízhatósági ígérettel rendelkezik, amely védelmet nyújt a szoftver- vagy hardverhibák ellen. Az adatbázis biztonsági mentései automatikusan védik az adatokat a sérüléstől vagy a véletlen törléstől. Szolgáltatásként nyújtott platformként (PaaS) az Azure SQL Managed Instance szolgáltatás rendelkezésre állását egy nagyvállalati osztály rendelkezésre állási SLA-val rendelkező, polcon kívüli szolgáltatásként biztosítja.
Ha magas rendelkezésre állást szeretne elérni az Azure-felhőkörnyezetben, engedélyezze a zónaredundanciát. A zónaredundanciával a példány rendelkezésre állási zónákat használ a zónahibákkal szembeni rugalmasság biztosításához.
- Számos Azure-régió biztosít rendelkezésre állási zónákat, amelyek különálló adatközpont-csoportok egy régión belül, amelyek független energiaellátással, hűtéssel és hálózati infrastruktúrával rendelkeznek.
- A rendelkezésre állási zónák úgy vannak kialakítva, hogy regionális szolgáltatásokat, kapacitást és magas rendelkezésre állást biztosítsanak a fennmaradó zónákban, ha egy zóna kimaradást tapasztal.
A zónaredundancia engedélyezésével a példány ellenáll a zóna hardver- és szoftverhibáinak, és a helyreállítás átlátható az alkalmazások számára. Ha a magas rendelkezésre állás engedélyezve van, az Azure SQL Managed Instance szolgáltatás képes magasabb rendelkezésre állási SLA-t biztosítani.
Katasztrófa-elhárítás
A régiók közötti magasabb rendelkezésre állás és redundancia érdekében engedélyezheti a vészhelyreállítási képességeket, hogy gyorsan helyreállíthassák a példányt egy katasztrofális regionális hibából. A felügyelt Azure SQL-példány vészhelyreállítási lehetőségei a következők:
- A feladatátvételi csoportok lehetővé teszik az elsődleges és másodlagos példányok közötti folyamatos szinkronizálást. A feladatátvételi csoportok olvasási-írási és csak olvasási hallgatói végpontokat biztosítanak, amelyek változatlanok maradnak, így a feladatátvétel után nem szükséges frissíteni az alkalmazáskapcsolati karakterláncokat.
- Geo-visszaállítás lehetővé teszi, hogy a regionális kimaradáskor, amikor nem fér hozzá az adatbázisához az elsődleges régióban, georeplikált biztonsági másolatokból állítsa vissza az adatokat, egy új adatbázis létrehozásával bármely Azure-régióban lévő meglévő példányon.
RTO és RPO
Az üzletmenet-folytonossági terv kidolgozása során ismerje meg a maximális elfogadható időt, mielőtt az alkalmazás teljes mértékben helyreáll a zavaró esemény után. A vészhelyreállítással kapcsolatos üzleti követelmények számszerűsítésének két gyakori módja:
- Helyreállítási idő célkitűzése (RTO):Az alkalmazás teljes helyreállításához szükséges idő egy nem tervezett zavaró esemény után.
- Helyreállítási pont célkitűzése (RPO):A nem tervezett zavaró eseményből elviselhető adatvesztés időmennyisége.
Az alábbi táblázat az egyes üzletmenet-folytonossági lehetőségek RPO-ját és RTO-ját hasonlítja össze:
| üzletmenet-folytonossági lehetőség | RTO (állásidő) | RPO (adatvesztés) |
|---|---|---|
| Magas rendelkezésre állású (Zónaredundancia használata) |
Általában kevesebb, mint 30 másodperc | 0 |
| Vészhelyreállítási (Feladatátvételi csoportok használata ügyfél által felügyelt feladatátvételi szabályzattal) |
Általában kevesebb, mint 60 másodperc | Legalább 0 (a nem replikált zavaró esemény előtti adatváltozásoktól függ) |
| Katasztrófa utáni helyreállítás (geo-helyreállítás használata) |
12 óra | 1 óra |
Üzletmenet-folytonosságot biztosító funkciók
Például négy fő lehetséges fennakadási forgatókönyv létezik. Az alábbi táblázat a felügyelt SQL-példányok üzletmenet-folytonossági funkcióit sorolja fel, amelyeket egy lehetséges üzletmenet-megszakítási forgatókönyv enyhítésére használhat:
| Üzleti fennakadási forgatókönyv | Üzletmenet-folytonossági funkció |
|---|---|
| Az adatbáziscsomópontot érintő helyi hardver- vagy szoftverhibák. | A helyi hardver- és szoftverhibák mérséklése érdekében a felügyelt SQL-példány rendelkezésre állási architektúrát tartalmaz, amely garantálja az automatikus helyreállítást ezekből a hibákból egy nagyvállalati szintű rendelkezésre állási SLA-val. |
| Az adatok sérülését vagy törlését általában egy alkalmazáshiba vagy emberi hiba okozza. Az ilyen hibák alkalmazásspecifikusak, és általában nem észlelhetők a szolgáltatás által. | A vállalat adatvesztéssel szembeni védelme érdekében a felügyelt SQL-példányok hetente automatikusan létrehoznak teljes adatbázis-biztonsági mentéseket, 12 vagy 24 óránként különbségi adatbázis-biztonsági mentéseket, valamint 5–10 percenkénti tranzakciónapló-biztonsági mentéseket. A biztonsági másolatok alapértelmezés szerint hét napig georedundáns tárolóban vannak tárolva, és támogatják a konfigurálható biztonsági másolat megőrzési időszakot az időponthoz kötött visszaállítás érdekében, akár 35 napig. Ha a példányt nem törölte, vagy ha hosszú távú megőrzést konfigurált, visszaállíthatja a törölt adatbázist a törlés időpontjára. |
| Ritka adatközpont- vagy rendelkezésreállási zónakimaradás, amelyet valószínűleg természeti katasztrófaesemény, konfigurációváltozás, szoftverhiba vagy hardverösszetevő-hiba okoz. | Az adatközpont vagy rendelkezésre állási zóna szintű kimaradásának csökkentése érdekében engedélyezze a felügyelt SQL-példány zónaredundanciáját, hogy Azure rendelkezésre állási zónák segítségével redundanciát biztosítson egy Azure régió több fizikai zónájában. A zónaredundancia engedélyezése biztosítja, hogy a felügyelt SQL-példány rugalmas legyen a nagyobb rendelkezésre állású SLA-val rendelkező zónahibákkal szemben. |
| Ritka régiókimaradás, amely az összes rendelkezésre állási zónát és az azt alkotó adatközpontokat érinti, valószínűleg katasztrofális természeti katasztrófaesemény okozta. | A régiószintű kimaradás mérsékléséhez engedélyezze a vészhelyreállítást az alábbi lehetőségek egyikével: - Folyamatos adatszinkronizálás feladatátvételi csoportokkal a feladatátvételt kiszolgáló másodlagos régió replikáihoz. - A biztonsági mentési tároló redundanciájának beállítása georedundáns biztonsági mentési tárolóként a georedundáns visszaállításhasználatához. |
Adatbázis helyreállítása ugyanabban az Azure-régióban
Az automatikus adatbázis-biztonsági mentések használatával visszaállíthatja az adatbázist egy adott időpontra a múltban. Így helyreállíthatja az emberi hibák által okozott adatsérüléseket. Az időponthoz kötött visszaállítás (PITR) lehetővé teszi, hogy egy új adatbázist hozzon létre ugyanahhoz a példányhoz vagy egy másik példányhoz, amely a sérült esemény előtt az adatok állapotát jelöli. A visszaállítási művelet az adatművelet mérete, amely a célpéldány aktuális számítási feladataitól is függ. Egy nagyon nagy vagy nagyon aktív adatbázis helyreállítása hosszabb időt vehet igénybe. A helyreállítási időről további információt adatbázis-helyreállítási időcímű témakörben talál.
Ha az időponthoz kötött visszaállítás (PITR) maximálisan támogatott biztonsági mentési megőrzési időtartama nem elegendő az alkalmazás számára, az adatbázis(ok) hosszú távú adatmegőrzési (LTR) szabályzatának konfigurálásával bővítheti azt. További információ: Hosszú távú megőrzés.
Adatbázis helyreállítása meglévő példányra
Bár ritka, az Azure-adatközpontok üzemkimaradást okozhatnak. Ha kimaradás történik, az olyan üzleti fennakadásokat okoz, amelyek csak néhány percig vagy órákig tarthatnak.
- Az egyik lehetőség az, hogy megvárja, amíg az instanciája újra online lesz, amikor az adatközpont-kimaradás véget ér. Ez olyan alkalmazások esetében működik, amelyek megengedhetik maguknak az adatbázis offline állapotba helyezését. Például egy fejlesztési projektet vagy egy ingyenes próbaverziót, amelyen nem kell folyamatosan dolgoznia. 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 az adatbázisra.
- Ha georedundáns (GRS) vagy geo-zónaredundáns (GZRS) tárolást használ, egy másik lehetőség az adatbázis visszaállítása bármely Felügyelt SQL-példányba, bármely Azure-régióban a georedundáns adatbázismentések (georestore) használatával. A georedundáns visszaállítás egy georedundáns biztonsági mentést használ a forrásként, és az adatbázis az utolsó rendelkezésre álló időpontra történő helyreállítására is használható, még akkor is, ha az adatbázis vagy az adatközpont kimaradás miatt elérhetetlen. Az elérhető biztonsági mentés a párosított régióban található.
- Végül gyorsan helyreállhat a kimaradásból, ha egy geo-sekundert konfigurál egy feladatátvételi csoport a példányhoz, akár az ügyfél által javasolt, akár a Microsoft által felügyelt feladatátvétel használatával. Bár maga az átállás csak pár másodpercet vesz igénybe, a szolgáltatás legalább 1 órát vesz igénybe a Microsoft által kezelt geo-átállás aktiválásához, ha konfigurálva van. Erre azért van szükség, hogy a feladatátvételt a kimaradás mértéke indokolja. Emellett a feladatátvétel a párosított régiók közötti aszinkron replikáció jellege miatt a közelmúltban megváltozott adatok elvesztését is eredményezheti.
Az üzletmenet-folytonossági terv kidolgozása során tisztában kell lennie azzal, hogy az alkalmazás a zavaró esemény után mennyi ideig áll helyre teljesen. Az alkalmazás teljes helyreállításához szükséges időt helyreállítási időkorlátnak (RTO) nevezzük. Emellett ismernie kell a legutóbbi adatfrissítések maximális időtartamát (időintervallumot), amelyet az alkalmazás elviselhet a nem tervezett zavaró eseményből való helyreállításkor. A lehetséges adatvesztést helyreállítási pont célkitűzésnek (RPO) nevezzük.
A különböző helyreállítási módszerek különböző RPO- és RTO-szinteket kínálnak. Választhat egy adott helyreállítási módszert, vagy használhat módszerek kombinációját a teljes alkalmazás-helyreállítás eléréséhez.
Használjon feladatátvételi csoportokat, ha az alkalmazás megfelel az alábbi feltételek bármelyikének:
- Kritikus fontosságú.
- Rendelkezik olyan szolgáltatásiszint-szerződéssel (SLA), amely nem teszi lehetővé a 12 óra vagy annál hosszabb leállást.
- Az állásidő pénzügyi felelősséget vonhat maga után.
- Nagy az adatváltozások aránya, és 1 óra adatvesztés nem elfogadható.
- Az aktív georeplikációs többletköltség alacsonyabb, mint a lehetséges pénzügyi felelősség és az ahhoz kapcsolódó üzleti veszteség.
Az alkalmazás követelményeinek megfelelően dönthet úgy, hogy adatbázis-biztonsági mentéseket és feladatátvételi csoportokat használ.
Az alábbi szakaszok áttekintést nyújtanak az adatbázis biztonsági mentésével vagy feladatátvételi csoportokkal történő helyreállítás lépéseiről.
Üzemkimaradás előkészítése
A használt üzletmenet-folytonossági funkciótól függetlenül a következőket kell tennie:
- Azonosítsa és előkészítse a célpéldányt, beleértve a hálózati IP-tűzfalszabályokat, a bejelentkezéseket és
masteradatbázisszintű engedélyeket. - Határozza meg, hogyan lehet az ügyfeleket és ügyfélalkalmazásokat átirányítani az új példányra
- Egyéb függőségek, például naplózási beállítások és riasztások dokumentálása
Ha nem készül fel megfelelően, az alkalmazások online állapotba helyezése feladatátvétel vagy adatbázis-helyreállítás után további időt vesz igénybe, és valószínűleg a stressz idején is hibaelhárítást igényel – ez egy rossz kombináció.
Átállás földrajzilag replikált másodlagos példányra
Ha feladatátvételi csoportokat használ helyreállítási mechanizmusként, konfigurálhat egy automatikus feladatátvételi szabályzatot. A feladatátvétel kezdeményezése után a másodlagos példány lesz az új elsődleges, készen áll az új tranzakciók rögzítésére és a lekérdezésekre való válaszadásra – minimális adatvesztéssel a még nem replikált adatok esetében.
Jegyzet
Amikor az adatközpont újra online állapotba kerül, a régi elsődleges automatikusan újracsatlakozik az új elsődlegeshez, hogy másodlagos példánysá váljon. Ha vissza kell helyeznie az elsődleges rendszert az eredeti régióba, manuálisan is kezdeményezhet tervezett átállást (feladatvisszavételt).
Geovisszaállítás végrehajtása
Ha automatikus biztonsági mentéseket használ georedundáns tárolással (a példány létrehozásakor ez az alapértelmezett tárolási lehetőség), georedundáns visszaállításihasználatával helyreállíthatja az adatbázist. A helyreállítás általában 12 órán belül történik – az adatvesztés legfeljebb egy óra lehet, attól függően, hogy az utolsó napló mentése és replikálása mikor történt meg. A helyreállítás befejezéséig az adatbázis nem tud semmilyen tranzakciót rögzíteni, és nem tud válaszolni a lekérdezésekre. Fontos tudni, hogy a geo-restore funkció csak az utolsó elérhető időpontra állítja vissza az adatbázist.
Jegyzet
Ha az adatközpont újra online állapotba kerül, mielőtt átállítja az alkalmazást a helyreállított adatbázisra, megszakíthatja a helyreállítást.
Feladatátvétel utáni/rendszer-helyreállítási feladatok végrehajtása
A helyreállítási mechanizmus használata után a következő kiegészítő feladatokat kell elvégeznie annak érdekében, hogy a felhasználók és alkalmazások újra működjenek:
- Ügyfelek és ügyfélalkalmazások átirányítása az új példányra és a visszaállított adatbázisra.
- Győződjön meg arról, hogy megfelelő hálózati IP-tűzfalszabályok vannak érvényben a felhasználók számára a csatlakozáshoz.
- Győződjön meg arról, hogy megfelelő bejelentkezések és
masteradatbázisszintű engedélyek vannak érvényben (vagy használja a bentlakó felhasználókat). - Szükség szerint konfigurálja a naplózást.
- Szükség szerint konfigurálja a riasztásokat.
Jegyzet
Ha feladatátvételi csoportot használ, és a példányhoz az írás-olvasás figyelővel csatlakozik, a feladatátvétel utáni átirányítás az alkalmazás számára automatikusan és észrevétlenül megtörténik.
Licenc nélküli DR-replikák
A licencelési költségek megtakarításához konfigurálhat egy másodlagos Felügyelt Azure SQL-példányt csak vészhelyreállításhoz (DR). Ez az előny akkor érhető el, ha feladatátvételi csoportot használ két felügyelt SQL-példány között, vagy konfigurálta az SQL Server és a felügyelt Azure SQL-példány közötti hibrid kapcsolatot. Mindaddig, amíg a másodlagos példány nem rendelkezik olvasási vagy írási számítási feladatokkal, és csak passzív dr. készenléti állapotú, nem kell fizetnie a másodlagos példány által használt virtuális mag licencelési költségeiért.
Ha másodlagos példányt jelöl ki csak vészhelyreállításhoz, és nem fut olvasási vagy írási számítási feladat a példányon, a Microsoft a feladatátvételi jogosultsági juttatás keretében díjmentesen biztosítja az elsődleges példány számára licencelt virtuális magok számát. A rendszer továbbra is a másodlagos példány által használt számítási és tárolási díjakat számítja fel. A hibrid feladatátvételi jogosultságok előnyeinek pontos feltételeiért tekintse meg az SQL Server online licencelési feltételeit az "SQL Server – Feladatátvételi jogok" szakaszban.
Az előny neve a forgatókönyvtől függ:
- passzív replika hibrid feladatátvételi jogosultságai: Amikor egy kapcsolatot konfigurál az SQL Server és az Azure SQL Managed Instance között, a hibrid feladatátvételi jogosultságok előnyét használhatja a passzív másodlagos replika vCore licencelési költségeinek megtakarításához.
- Készenléti replika feladatátvételi jogai: Amikor feladatátvételi csoportot konfigurál két felügyelt példány között, a feladatátvételi jogok előnyeit kihasználhatja a másodlagos készenléti replika virtuális mag licencelési költségeinek megtakarításához.
Az alábbi ábra az egyes forgatókönyvek előnyeit mutatja be:
