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

Vészhelyreállítási útmutató – Felügyelt Azure SQL-példány

A következőkre vonatkozik:Azure SQL Managed Instance

A felügyelt Azure SQL-példány iparágvezető magas rendelkezésre állási garanciát nyújt 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. A felügyelt Azure SQL-példány emellett kulcsfontosságú üzletmenet-folytonossági képességeket is kínál, 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ásra, vannak olyan esetek, amikor az Azure SQL Managed Instance 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

Felügyelt Azure SQL-példány szolgáltatáskimaradása esetén a szolgáltatáskimaradással kapcsolatos további részleteket az alábbi 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:

    Képernyőkép az Azure Portalról egy Azure SQL Managed Instance szolgáltatással kapcsolatos problémáról szóló értesítésről.

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

    Képernyőkép a Súgó+Támogatás lapról, amelyen egy aktív szolgáltatásállapot-probléma értesítése látható.

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

    Képernyőkép az Azure Portal Szolgáltatásállapot lapjáról egy délkelet-ázsiai szolgáltatásproblémáról, amelyen a probléma és az érintett erőforrások térképe látható.

  • 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, csak 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 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 egy régióban az Azure SQL Managed Instance szolgáltatáskimaradása hosszabb ideje nem enyhíthető, és hatással van az alkalmazás szolgáltatásiszint-szerződésére (SLA), kövesse az alábbi lépéseket:

Átállás (nincs adatvesztés) földrajzilag replikált másodlagos példányra

Ha a feladatátvételi csoportok engedélyezve vannak, ellenőrizze, hogy az elsődleges és másodlagos példány erőforrás-állapota online-e az Azure Portalon. Ha igen, akkor az elsődleges és a másodlagos példány adatsíkja is egészséges.

Indítsa el a feladatátvételi csoportok átváltását a másodlagos régióba a következő 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.

Kényszerített átállás georeplikált másodlagos példányra (lehetséges adatvesztés)

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 a következőt:

  • Azure Portal de válassza a Kényszerített feladatátvétel lehetőséget.
  • PowerShell, de használja --allow-data-loss.
  • Azure CLI , de használja -AllowDataLoss.

Földrajzi visszaállítás

Ha még nem engedélyezte a feladatátvételi csoportokat, akkor végső megoldásként a geo-helyreállítást használhatja a leállásból való helyreálláshoz. A geo-restore georeplikált biztonsági másolatokat használ forrásként. Az adatbázist bármely Azure-régió bármely példányán visszaállíthatja a legutóbbi georeplikált biztonsági másolatokból. Georedundáns visszaállítást akkor is kérhet, ha egy üzemkimaradás miatt a példány vagy a teljes régió elérhetetlenné vált.

Az Azure CLI, az Azure portál, a PowerShell vagy a REST API használatával történő geo-visszaállításról további információkért lásd: Geo-restore.

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 leállások utáni helyreállításhoz, győződjön meg arról, hogy az új példányhoz való kapcsolódás megfelelően van konfigurálva, hogy a normál alkalmazás működése folytatódhasson. 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 a magas rendelkezésre állás és a vészhelyreállítás ellenőrzőlistáján talál.

Kapcsolati sztringek frissítése

  • Geo-visszaállítás használata esetén győződjön meg arról, hogy az új példányhoz történő kapcsolódás megfelelően van konfigurálva, hogy a normál alkalmazásműködés újraindulhasson. Mivel a helyreállított adatbázis egy másik példányon 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 példányhoz konfigurált NSG- és útvonaltábla-szabályok megegyeznek az elsődleges példányon konfiguráltakkal. További információért tekintse át a szolgáltatás által támogatott alhálózat konfigurációját .

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 a másodlagos példányon, és győződjön meg arról, hogy ezek a bejelentkezések rendelkeznek megfelelő engedélyekkel az master adatbázisban, ha vannak ilyenek.

Telemetriai riasztások beállítása

Győződjön meg arról, hogy a meglévő riasztási szabály beállításai frissítve vannak az új elsődleges példányhoz való hozzárendelésre. 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 példányon van konfigurálva, a másodlagos példányon azonos legyen. További információ: Azure SQL Auditing for Azure SQL Managed Instance.

Kapcsolódó tartalom

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

  • Last updated on