Vészhelyreállítási útmutató – Azure SQL Database

A következőkre vonatkozik:Azure SQL Database

• Azure SQL-adatbázis
• Azure SQL Managed Instance

Az Azure SQL Database iparágvezető magas rendelkezésre állási garanciát biztosít legalább 99,99%, hogy számos olyan alkalmazást támogatjon, beleértve a kritikus fontosságú alkalmazásokat is, amelyeknek mindig rendelkezésre kell állniuk. Az Azure SQL Database emellett kulcsfontosságú üzletmenet-folytonossági képességekkel is rendelkezik, amelyeket regionális kimaradás esetén gyors vészhelyreállításhoz végezhet el. Ez a cikk értékes információkat tartalmaz az alkalmazás üzembe helyezése előtt.

Bár folyamatosan törekszünk a magas rendelkezésre állás biztosítására, vannak olyan időszakok, amikor az Azure SQL Database szolgáltatás olyan kimaradásokat okoz, amelyek az adatbázis elérhetetlenségét okozzák, és így hatással vannak az alkalmazásra. Ha szolgáltatásfigyelésünk széles körű csatlakozási hibákat, hibákat vagy teljesítményproblémákat okozó problémákat észlel, a szolgáltatás automatikusan leállást deklarál, hogy folyamatosan tájékoztassa Önt.

Szolgáltatáskimaradás

Azure SQL Database-szolgáltatáskimaradás esetén a szolgáltatáskimaradással kapcsolatos további részleteket a következő helyeken talál:

• Az Azure Portal szalagcíme

  Ha az előfizetése érintettként van azonosítva, szolgáltatáskimaradási riasztást kap az Azure Portal értesítései között:

  

• Súgó + támogatás vagy támogatás + hibaelhárítás

  Ha támogatási jegyet hoz létre a Súgó + támogatás vagy a Támogatás + hibaelhárítás szolgáltatásból, az erőforrásokat érintő problémákra vonatkozó információk találhatók. A kimaradás részleteinek megtekintése lehetőséget választva további információkat és a hatás összegzését tekintheti meg. Az Új támogatási kérelem lapon is megjelenik egy riasztás.

  

• Szolgáltatásállapot

  Az Azure Portal Service Health oldala az Azure-adatközpontok állapotával kapcsolatos információkat tartalmazza globálisan. Keressen rá a "szolgáltatás állapota" kifejezésre az Azure Portal keresősávján, majd tekintse meg a szolgáltatásproblémákat az Aktív események kategóriában. Az egyes erőforrások állapotát bármely erőforrás Erőforrás állapota lapján, a Súgó menüben tekintheti meg. Az alábbi minta képernyőkép a Service Health oldalról, amely egy délkelet-ázsiai aktív szolgáltatásproblémával kapcsolatos információval rendelkezik:

  

• E-mailes értesítés

  Ha beállította a riasztásokat, a rendszer e-mail-értesítést küld azure-noreply@microsoft.com , ha egy szolgáltatáskimaradás hatással van az előfizetésére és az erőforrására. Az e-mail törzse általában a következővel kezdődik: "A tevékenységnapló riasztása ... az Azure-előfizetés szolgáltatásproblémája váltotta ki...". A szolgáltatásállapot-riasztásokkal kapcsolatos további információkért lásd : Tevékenységnapló-riasztások fogadása az Azure-szolgáltatásértesítéseken az Azure Portal használatával.

• Rendelkezésre állási metrika

  Az Azure SQL Database rendelkezésre állási metrikáit az Azure Portalon figyelheti és konfigurálhatja.

Mikor kell vészhelyreállítást kezdeményezni egy üzemkimaradás során?

Ha egy szolgáltatáskimaradás hatással van az alkalmazás erőforrásaira, fontolja meg a következő műveletek elvégzését:

• Az Azure-csapatok szorgalmasan dolgoznak azon, hogy a lehető leggyorsabban visszaállítsák a szolgáltatás rendelkezésre állását, de a kiváltó októl függően néha órákat is igénybe vehet. Ha az alkalmazás képes elviselni a jelentős állásidőt, egyszerűen kivárhatja a helyreállítás befejezését. Ebben az esetben nincs szükség műveletre az Ön részéről. Az egyes erőforrások állapotának megtekintése bármely erőforrás Erőforrás állapota lapján, a Súgó menüben. A frissítésekről és a kimaradással kapcsolatos legfrissebb információkért tekintse meg az Erőforrás állapota lapot. A régió helyreállítása után az alkalmazás rendelkezésre állása helyreáll.

• Egy másik Azure-régióba történő helyreállításhoz szükség lehet az alkalmazáskapcsolati sztringek módosítására vagy a DNS-átirányítás használatára, és ez tartós adatvesztést okozhat. Ezért a vészhelyreállítást csak akkor szabad végrehajtani, ha a kimaradás időtartama megközelíti az alkalmazás helyreállítási időkorlátját (RTO). Amikor az alkalmazás éles környezetbe kerül telepítésre, rendszeresen ellenőriznie kell az alkalmazás állapotát, és meg kell győződnie arról, hogy a helyreállítás csak akkor indokolt, ha az alkalmazásszintről hosszan tartó csatlakozási hiba fordul elő az adatbázishoz. Attól függően, hogy az alkalmazás tűri-e az állásidőt és az esetleges üzleti felelősséget, eldöntheti, hogy megvárja-e, amíg a szolgáltatás helyreáll vagy elindítja a vészhelyreállítást.

Kimaradás utáni helyreállítási útmutató

Ha az Azure SQL Database szolgáltatáskimaradása egy régióban hosszabb ideje nem lett enyhítve, és hatással van az alkalmazás szolgáltatásiszint-szerződésére (SLA), kövesse az alábbi lépéseket:

Feladatátvétel (adatvesztés nélkül) földrajzilag replikált másodlagos kiszolgálóra

Ha az aktív georeplikáció vagy a feladatátvételi csoportok engedélyezve vannak, ellenőrizze, hogy az elsődleges és másodlagos adatbázis erőforrás-állapota online az Azure Portalon. Ha igen, akkor az elsődleges és a másodlagos adatbázis adatsíkja is kifogástalan. Kezdeményezze az aktív georeplikációs vagy feladatátvételi csoportok átvételét a másodlagos régióba az Azure portal, a T-SQL, a PowerShell vagy az Azure CLI használatával.

Megjegyzés:

A feladatátvételhez a szerepkörök váltása előtt teljes adatszinkronizálás szükséges, és nem okoz adatvesztést. A szolgáltatáskimaradás típusától függően nincs garancia arra, hogy az adatvesztés nélküli feladatátvétel sikeres lesz, de érdemes első helyreállítási lehetőségként próbálkozni.

A feladatátvétel indításához használja az alábbi hivatkozásokat:

Technológia	Metódus	Steps
Aktív georeplikáció	PowerShell	Másodlagos georeplikációs feladatátvétel a PowerShell-lel
	T-SQL	Átállás a georeplikációs másodlagos rendszerre T-SQL segítségével
Átállási csoportok	Azure CLI (Az Azure parancssori felülete)	Átváltás másodlagos kiszolgálóra az Azure CLI segítségével
	Azure Portal	Feladatátvétel másodlagos kiszolgálóra az Azure Portalon keresztül
	PowerShell	Átállás a másodlagos kiszolgálóra a PowerShell használatával

Kényszerített feladatátvétel (lehetséges adatvesztés) georeplikált másodlagos kiszolgálóra

Ha a feladatátvétel nem fejeződik be, és hibákat tapasztal, vagy ha az elsődleges adatbázis állapota nemonline, gondosan fontolja meg a kényszerített feladatátvételt, amely potenciálisan adatvesztést okozhat a másodlagos régióban.

Kényszerített feladatátvétel indításához használja az alábbi hivatkozásokat:

Technológia	Metódus	Steps
Aktív georeplikáció	Azure CLI (Az Azure parancssori felülete)	Kényszerített feladatátvétel másodlagos georeplikálásra az Azure CLI-vel
	Azure Portal	Kényszerített feladatátvétel másodlagos georeplikálásra az Azure Portalon keresztül
	PowerShell	Kényszerített feladatátvétel a georeplikáció másodlagos példányára a PowerShell használatával
	T-SQL	Kényszerített átváltás georeplikációs másodlagosra T-SQL-en keresztül
Átállási csoportok	Azure Portal	Kényszerített feladatátvétel másodlagos kiszolgálóra az Azure Portalon keresztül , de válassza a Kényszerített feladatátvétel lehetőséget.
	Azure CLI (Az Azure parancssori felülete)	Kényszerített feladatátvétel másodlagos kiszolgálóra az Azure CLI segítségével, de használja --allow-data-loss
	PowerShell	Másodlagos kiszolgálóra történő kényszerített feladatátvétel a PowerShell segítségével, de használja -AllowDataLoss

Földrajzi visszaállítás

Ha még nem engedélyezte az aktív georeplikációt vagy a feladatátvételi csoportokat, akkor végső megoldásként geo-visszaállítással helyreállhatja az üzemkiesésből. A geo-restore georeplikált biztonsági másolatokat használ forrásként. Bármely Azure-régió bármely logikai kiszolgálóján visszaállíthatja az adatbázist a legutóbbi georeplikált biztonsági másolatokból. Georestore kérését akkor is benyújthatja, ha egy kimaradás miatt az adatbázis vagy a teljes régió elérhetetlenné vált.

Az Azure CLI-n, az Azure portalon, a PowerShellen vagy a REST API-n keresztül történő geo-helyreállítással kapcsolatos további információkért lásd az Azure SQL Database geo-helyreállítását.

Az adatbázis konfigurálása a helyreállítás után

Ha geo-feladatátvételt vagy geo-helyreállítást használ a kimaradás utáni helyreállításhoz, győződjön meg arról, hogy az új adatbázishoz való csatlakozás megfelelően van konfigurálva, hogy a normális alkalmazás működése újraindulhasson. Ez a feladatlista a helyreállított adatbázis éles üzemre való felkészítéséhez szükséges feladatokat sorolja fel.

Fontos

Javasoljuk, hogy végezzen rendszeres próbákat a vészhelyreállítási stratégiáról az alkalmazástűrés ellenőrzése érdekében, valamint a helyreállítási eljárás minden működési aspektusát. Előfordulhat, hogy az alkalmazásinfrastruktúra többi rétege újrakonfigurálást igényel. A rugalmas architektúra lépéseiről további információt az Azure SQL Database magas rendelkezésre állású és vészhelyreállítási ellenőrzőlistájában talál.

Kapcsolati sztringek frissítése

• Ha aktív georeplikációt vagy georedukálást használ, győződjön meg arról, hogy az új adatbázisokhoz való kapcsolódás megfelelően van konfigurálva, hogy a normál alkalmazásfüggvény újrainduljon. Mivel a helyreállított adatbázis egy másik kiszolgálón található, frissítenie kell az alkalmazás kapcsolati sztringjét, hogy arra a kiszolgálóra mutasson. A kapcsolati sztringek módosításával kapcsolatos további információkért tekintse meg a kapcsolattár megfelelő fejlesztési nyelvét.
• Ha feladatátvételi csoportokat használ a kimaradásból való helyreállításhoz, és írás-olvasás és csak olvasható figyelőket használ az alkalmazás kapcsolati sztringjeiben, akkor nincs szükség további műveletre, mivel a kapcsolatok automatikusan az új elsődleges példány felé irányulnak.

Tűzfalszabályok konfigurálása

Győződjön meg arról, hogy a másodlagos kiszolgálón és az adatbázisban konfigurált tűzfalszabályok megegyeznek az elsődleges kiszolgálón és az elsődleges adatbázisban konfiguráltakkal. További információ : A tűzfalbeállítások konfigurálása.

Bejelentkezések és adatbázis-felhasználók konfigurálása

Hozza létre azokat a bejelentkezéseket, amelyeknek szerepelniük kell az master adatbázisban az új elsődleges kiszolgálón, és győződjön meg arról, hogy ezek a bejelentkezések megfelelő engedélyekkel rendelkeznek az master adatbázisban, ha vannak ilyenek. További információkért tekintse meg a vészhelyreállítás utáni biztonságot.

Telemetriai riasztások beállítása

Meg kell győződnie arról, hogy a meglévő riasztási szabály beállításai frissülnek, hogy megfeleltethetők legyenek az új elsődleges adatbázisnak és a másik kiszolgálónak. Az adatbázis-riasztási szabályokról további információt a Riasztási értesítések fogadása és a Szolgáltatás állapotának nyomon követése című témakörben talál.

Auditnaplózás engedélyezése

Ha a naplózás az elsődleges kiszolgálón van konfigurálva, a másodlagos kiszolgálón azonos legyen. További információ: Naplózás.

Kapcsolódó tartalom

További információkért tekintse át az alábbiakat:

• Folytonossági forgatókönyvek.
• Automatikus biztonsági mentések
• Adatbázis visszaállítása a szolgáltatás által kezdeményezett biztonsági másolatokból.
• A gyorsabb helyreállítási lehetőségek részleteit az aktív georeplikáció és feladatátvételi csoportok című leírásokban találja.
• Tekintse át a vészhelyreállítási útmutatót , valamint a magas rendelkezésre állási és vészhelyreállítási ellenőrzőlistát.