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

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

  • Cikk

A következőre vonatkozik: Azure SQL Database

Az Azure SQL Database iparágvezető, legalább 99,99%-os magas rendelkezésre állási garanciát nyújt számos olyan alkalmazás támogatásához, 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ással hajthat végre. 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éseiben:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • 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, információ áll rendelkezésre az erőforrásokat érintő problémákról. 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.

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 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:

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • 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.

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 megvá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 való helyreállításhoz szükség lehet az alkalmazás kapcsolati sztring módosítására vagy a DNS-átirányítás használatára, ami 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örnyezetben van üzembe helyezve, rendszeresen figyelnie kell az alkalmazás állapotát, és ellenőriznie kell, hogy a helyreállítás csak akkor indokolt, ha az alkalmazásszintről az adatbázishoz való hosszan tartó kapcsolati hiba áll fenn. 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.

Szolgáltatáskimaradási 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) georeplikált másodlagos kiszolgálóra

Ha az aktív georeplikációs vagy feladatátvételi csoportok engedélyezve vannak, ellenőrizze, hogy az elsődleges és másodlagos adatbázis erőforrás-állapota online-e az Azure Portalon. Ha igen, akkor az elsődleges és a másodlagos adatbázis adatsíkja is kifogástalan. Kezdeményezheti az aktív georeplikációs vagy feladatátvételi csoportok feladatá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.

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

Technológia Metódus Steps
Active geo-replication PowerShell Másodlagos georeplikációs feladatátvétel a PowerShell-lel
T-SQL Feladatátvétel másodlagos georeplikációs feladatra a T-SQL-en keresztül
Feladatátvételi csoportok Azure CLI Feladatátvétel másodlagos kiszolgálóra az Azure CLI-vel
Azure Portal Feladatátvétel másodlagos kiszolgálóra az Azure Portalon keresztül
PowerShell Feladatátvétel 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
Active geo-replication Azure CLI 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 másodlagos georeplikációs feladatátvételre a PowerShell használatával
T-SQL Kényszerített feladatátvétel másodlagos georeplikációs feladatátvételre a T-SQL-en keresztül
feladatátvételi 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 Kényszerített feladatátvétel másodlagos kiszolgálóra az Azure CLI-vel , de használja --allow-data-loss
PowerShell Kényszerített feladatátvétel másodlagos kiszolgálóra a PowerShell-lel , de használja -AllowDataLoss

Geo-restore

Ha nem engedélyezte az aktív georeplikációs vagy feladatátvételi csoportokat, akkor végső megoldásként georeduktív visszaállítással helyreállíthatja a leállást. A georeduktúra 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. Georedundáns visszaállítást akkor is kérhet, 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ő georedukálással kapcsolatos további információkért lásd az Azure SQL Database georeduktúra-visszaállítását.

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

Ha geo-feladatátvételt vagy georedukálá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ál alkalmazásfüggvény újrainduljon. 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 sztring 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 sztring, hogy az adott kiszolgálóra mutasson. A kapcsolati sztring módosításáról további információt a kapcsolatkódtár megfelelő fejlesztési nyelvén talál.
  • Ha feladatátvételi csoportokat használ a leállások utáni helyreállításhoz, és írásvédett és írásvédett figyelőket használ az alkalmazás kapcsolati sztring, akkor nincs szükség további műveletre, mivel a kapcsolatok automatikusan az új elsődleges helyre lesznek irányítva.

Tűzfalszabályok konfigurálása

Győződjön meg arról, hogy a 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űzfal Gépház (Azure SQL Database) 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 az Azure SQL Database biztonsági funkcióit a vészhelyreállítás után.

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.

Naplózás engedélyezése

Ha naplózásra van szükség az adatbázis eléréséhez, engedélyeznie kell a naplózást az adatbázis helyreállítása után. További információ: Azure SQL-naplózás az Azure SQL Database-hez.

További lépések

  • Az Azure SQL Database SLA-jának áttekintése
  • Az Azure SQL Database automatikus biztonsági mentéseinek megismeréséhez tekintse meg az SQL Database automatikus biztonsági mentéseit
  • Az üzletmenet-folytonossági tervezési és helyreállítási forgatókönyvek megismeréséhez tekintse meg a folytonossági forgatókönyveket
  • Az automatikus biztonsági mentések helyreállítási célú használatáról további információt a szolgáltatás által kezdeményezett biztonsági másolatok adatbázisának visszaállításával kapcsolatban talál .
  • További információ az aktív georeplikációs szolgáltatásról
  • További információ a feladatátvételi csoportokról
  • További információ a georeduktúra visszaállításáról
  • További információ a zónaredundáns adatbázisokról