Az Azure SQL Database üzletmenet-folytonossági funkcióinak áttekintése
A következőre vonatkozik:
Azure SQL Database
Ez a cikk áttekintést nyújt az Azure SQL Database ü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 az adatbázis é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 Database üzletmenet-folytonossága azokra a mechanizmusokra, szabályzatokra és eljárásokra vonatkozik, amelyek lehetővé teszik, hogy a vállalat a rendelkezésre állás, a magas rendelkezésre állás és a vészhelyreállítás biztosításával továbbra is zavartalanul működjön.
Az SQL Database a legtöbb esetben olyan zavaró eseményeket kezel, amelyek felhőkörnyezetben fordulhatnak elő, és az alkalmazásokat és az üzleti folyamatokat folyamatosan futtatja. 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.
Elérhetőség
Az Azure SQL Database 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 Database szolgáltatás 99,99%-os iparági vezető rendelkezésre állási SLA-val biztosítja a rendelkezésre állást egy polcon kívüli szolgáltatásként.
High Availability
Ha magas rendelkezésre állást szeretne elérni az Azure-felhőkörnyezetben, engedélyezze a zónaredundanciát , hogy az adatbázis vagy a rugalmas készlet rendelkezésre állási zónákkal biztosítsa, hogy az adatbázis vagy a rugalmas készlet rugalmas legyen a zónahibákkal szemben. 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 az adatbázis vagy a rugalmas készlet rugalmasan alkalmazkodik a zóna hardver- és szoftverhibáihoz, é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 Database szolgáltatás 99,995%-os magasabb rendelkezésre állási SLA-t tud biztosítani.
Vészhelyreállítás
A régiók közötti nagyobb rendelkezésre állás és redundancia érdekében engedélyezheti a vészhelyreállítási képességeket az adatbázis gyors helyreállításához egy katasztrofális regionális hiba miatt. Az Azure SQL Database vészhelyreállítási lehetőségei a következők:
- Az aktív georeplikációs funkcióval folyamatosan szinkronizálható, olvasható másodlagos adatbázist hozhat létre az elsődleges adatbázis bármely régiójában.
- A feladatátvételi csoportok amellett, hogy folyamatos szinkronizálást biztosítanak az elsődleges és a másodlagos adatbázis között, lehetővé teszik a logikai kiszolgálón lévő egyes adatbázisok replikációjának és feladatátvételének kezelését egy másik régióban lévő másodlagos logikai kiszolgálóra. A feladatátvételi csoportok írásvédett és írásvédett figyelővégpontokat biztosítanak, amelyek változatlanok maradnak, így az alkalmazás kapcsolati sztring frissítése a feladatátvétel után nem szükséges.
- A georedundáns visszaállítás lehetővé teszi a regionális kimaradások utáni helyreállítást georeplikált biztonsági másolatokból, ha nem fér hozzá az adatbázishoz az elsődleges régióban egy új adatbázis létrehozásával bármely Azure-régió meglévő kiszolgálóján.
Az alábbi táblázat az aktív georeplikációs és feladatátvételi csoportokat hasonlítja össze, az Azure SQL Database két vészhelyreállítási lehetőségét:
| Aktív georeplikációs | Feladatátvételi csoportok | |
|---|---|---|
| Folyamatos adatszinkronizálás elsődleges és másodlagos között | Igen | Igen |
| Több adatbázis egyidejű feladatátvétele | Nem | Igen |
| Csatlakozás ion sztring nem változik a feladatátvétel után | Nem | Igen |
| Támogatja az olvasási skálázást | Igen | Igen |
| Több replika | Igen | Nem |
| Az elsődleges régióval megegyező régióban lehet | Igen | Nem |
Üzletmenet-folytonosságot biztosító funkciók
Adatbázis szempontjából négy fő lehetséges fennakadási forgatókönyv létezik. Az alábbi táblázat az SQL Database üzletmenet-folytonossági funkcióit sorolja fel, amelyekkel enyhítheti az üzletmenet esetleges zavarait:
| Ü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 az SQL Database rendelkezésre állási architektúrát is tartalmaz, amely garantálja az automatikus helyreállítást ezekből a hibákból akár 99,99%-os 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 az adatbázis-szolgáltatás általában nem észleli őket. | A vállalat adatvesztés elleni védelme érdekében az SQL Database automatikusan heti rendszerességgel készít teljes adatbázis-biztonsági mentéseket, 12 vagy 24 óránként különbségi adatbázis biztonsági mentést, a tranzakciónaplók biztonsági mentését pedig 5–10 percenként. Alapértelmezés szerint a biztonsági másolatok georedundáns tárolóban vannak tárolva hét napig az összes szolgáltatási szint esetében. Az alapszintű kivételével minden szolgáltatási szint támogatja az időponthoz kötött visszaállítás (PITR) konfigurálható biztonsági mentési megőrzési időtartamát legfeljebb 35 napig. A törölt adatbázisokat visszaállíthatja arra a pontra, ahol a kiszolgálót nem törölték, vagy ha hosszú távú megőrzést (LTR) konfigurált. |
| 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özpontok vagy a rendelkezésre állási zónák szintkimaradásának csökkentése érdekében engedélyezze a zónaredundanciát az adatbázis vagy a rugalmas készlet számára az Azure rendelkezésre állási zónák használatára, valamint az Azure-régión belüli több fizikai zónára kiterjedő redundancia biztosításához. A zónaredundancia engedélyezése biztosítja, hogy az adatbázis vagy a rugalmas készlet rugalmas legyen az akár 99,995%-os magas rendelkezésre állású SLA-val rendelkező zónahibákkal szemben. |
| Ritka regionális kimaradás , amely hatással van az összes rendelkezésre állási zónára és az azt alkotó adatközpontokra, valószínűleg katasztrofális természeti katasztrófa miatt. | A régiószintű kimaradás mérsékléséhez engedélyezze a vészhelyreállítást a következő lehetőségek egyikével: – Folyamatos adatszinkronizálási lehetőségek, például feladatátvételi csoportok (ajánlott) vagy aktív georeplikálás , amelyek lehetővé teszik replikák létrehozását egy másodlagos régióban feladatátvételhez. – A biztonsági mentési tár redundanciának beállítása georedundáns biztonsági mentési tárolóra a georedundáns visszaállítás használatához. |
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. Az alkalmazás teljes helyreállításához szükséges időt helyreállítási idő célkitűzésnek (RTO) nevezzük. Ismerje meg a legutóbbi adatfrissítések (időintervallum) maximális időtartamát is, 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.
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 engedélyezése) |
Általában kevesebb, mint 30 másodperc | 0 |
| Vészhelyreállítás (feladatátvételi csoportok vagy aktív georeplikálás engedélyezése) |
Általában kevesebb, mint 60 másodperc | Egyenlő vagy nagyobb, mint 0 (a nem replikált zavaró esemény előtti adatváltozásoktól függ) |
| Vészhelyreállítás (georeduktúra használata) |
Általában percek vagy órák | Általában percek vagy órák |
Üzletmenet-folytonossági ellenőrzőlisták
A rendelkezésre állás maximalizálására és a nagyobb üzletmenet-folytonosság elérésére vonatkozó előíró javaslatokért tekintse meg az alábbiakat:
- Rendelkezésre állási ellenőrzőlista
- Magas rendelkezésre állási ellenőrzőlista
- Vészhelyreállítási ellenőrzőlista
Felkészülés régiókimaradásra
Függetlenül attól, hogy milyen üzletmenet-folytonossági funkciókat használ, elő kell készítenie a másodlagos adatbázist egy másik régióban. Ha nem készül fel megfelelően, az alkalmazások online állapotba helyezése feladatátvétel vagy helyreállítás után további időt vesz igénybe, és valószínűleg hibaelhárítást is igényel, ami késleltetheti az RTO-t. Kövesse az ellenőrzőlistát a másodlagos régiókimaradás előkészítéséhez.
Adatbázis visszaá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 egy új adatbázis létrehozását ugyanazon a kiszolgálón, amely a sérült esemény előtti adatok állapotát jelöli. A legtöbb adatbázis esetében a visszaállítási műveletek kevesebb mint 12 órát vesznek igénybe. Egy nagyon nagy vagy nagyon aktív adatbázis helyreállítása hosszabb időt is igénybe vehet. További információ: adatbázis-helyreállítási idő.
Ha az időponthoz kötött visszaállítás maximálisan támogatott biztonsági mentési megőrzési időszaka 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 meghosszabbíthatja azt. További információ: Hosszú távú biztonsági mentési megőrzés.
Alkalmazások frissítése minimális állásidővel
Előfordulhat, hogy egy alkalmazást karbantartás, például alkalmazásfrissítés miatt offline állapotba kell helyezni. Az alkalmazásfrissítések kezelése azt ismerteti, hogyan használhat aktív georeplikációt a felhőalkalmazás működés közbeni frissítéseinek engedélyezéséhez, hogy a frissítések során minimálisra csökkentse az állásidőt, és helyreállítási útvonalat biztosítson, ha valami hiba történik.
Költségmegtakarítás készenléti replikával
Ha a másodlagos replikát csak vészhelyreállításhoz (DR) használják, és nem rendelkezik olvasási vagy írási számítási feladatokkal, az új aktív georeplikációs kapcsolat konfigurálásakor az adatbázis készenléti állapotba állításával csökkentheti a licencelési költségeket.
További információért tekintse át a licencmentes készenléti replikát .
További lépések
Az alkalmazástervezési szempontokat lásd : Alkalmazás tervezése felhőbeli vészhelyreállításhoz és rugalmas készlet vészhelyreállítási stratégiáihoz.
Tekintse át az Azure SQL Database vészhelyreállítási útmutatóját, valamint az Azure SQL Database magas rendelkezésre állási és vészhelyreállítási ellenőrzőlistát.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: