Az Azure SQL Database magas rendelkezésre állási és vészhelyreállítási ellenőrzőlistája

  • Cikk

A következőre vonatkozik: Azure SQL Database

Az Azure SQL Database szolgáltatás automatikusan biztosítja, hogy az összes adatbázis online, kifogástalan állapotban legyen, és folyamatosan törekszik a közzétett SLA elérésére.

Ez az útmutató részletes áttekintést nyújt a rendelkezésre állás maximalizálása, a helyreállítás biztosítása és az Azure-kimaradásokra való felkészülés érdekében tett proaktív lépésekről. Ez az útmutató az Azure SQL Database összes vásárlási modellére és szolgáltatási szintjére vonatkozik.

Rendelkezésre állási ellenőrzőlisták

A rendelkezésre állás maximalizálása érdekében az alábbi konfigurációk ajánlottak:

  • Az átmeneti hibák kezeléséhez használja az újrapróbálkozási logikát az alkalmazásban.
  • A karbantartási időszakok használatával kiszámíthatóvá és kevésbé zavaróvá teheti a jelentős karbantartási eseményeket.
  • Az alkalmazáshibák rugalmasságának tesztelése feladatátvétel manuális aktiválásával a rugalmasság működés közbeni megtekintéséhez.

Magas rendelkezésre állási ellenőrzőlista

A magas rendelkezésre állás eléréséhez az alábbi konfiguráció ajánlott:

  • Engedélyezze a zónaredundanciát , ha elérhető az adatbázis vagy a rugalmas készlet számára a zónahibák rugalmasságának biztosítása érdekében.

Vészhelyreállítási ellenőrzőlista

Bár az Azure SQL Database automatikusan fenntartja a rendelkezésre állást, vannak olyan esetek, amikor még a magas rendelkezésre állás (zónaredundancia) sem garantálja a rugalmasságot, mivel a kimaradás egy teljes régióra kiterjed. Előfordulhat, hogy egy regionális Azure SQL Database-üzemkimaradás esetén vészhelyreállítást kell kezdeményeznie.

A vészhelyreállításra való legjobb felkészüléshez kövesse az alábbi ajánlásokat:

  • Adatbáziscsoportok feladatátvételi csoportjainak engedélyezése.
    • Használja az írásvédett és írásvédett figyelővégpontokat az alkalmazásban kapcsolati sztring, hogy az alkalmazások automatikusan csatlakozzanak attól a kiszolgálóhoz és adatbázishoz, amelyik elsődleges.
    • Állítsa be a feladatátvételi szabályzatot az ügyfél által felügyeltre.
  • A feladatátvételi csoportok helyett engedélyezheti az aktív georeplikálást , hogy egy olvasható másodlagos adatbázissal rendelkezzen egy másik Azure-régióban.
  • Győződjön meg arról, hogy a geo-másodlagos adatbázis ugyanazzal a szolgáltatási szinttel, számítási szinttel (kiépített vagy kiszolgáló nélküli) és számítási mérettel (DTU-kkal vagy virtuális magokkal) jön létre, mint az elsődleges adatbázis.
  • Vertikális felskálázáskor először skálázza fel a geo-másodlagost, majd skálázza fel az elsődlegest.
  • Vertikális leskálázáskor fordítsa meg a sorrendet: először az elsődleges, majd másodlagos példányt skálázza le.
  • A vészhelyreállítás természete szerint úgy lett kialakítva, hogy az adatok aszinkron replikációját használja az elsődleges és a másodlagos régió között. A nagyobb véglegesítési késéssel szemben az adatok rendelkezésre állásának rangsorolásához érdemes lehet közvetlenül a tranzakció véglegesítése után meghívni a sp_wait_for_database_copy_sync tárolt eljárást. A hívás sp_wait_for_database_copy_sync addig blokkolja a hívási szálat, amíg az utolsó véglegesített tranzakciót nem továbbítják és meg nem keményítik a másodlagos adatbázis tranzakciónaplójában.
  • Az elsődleges adatbázis sys.dm_geo_replication_link_status dinamikus felügyeleti nézetének (DMV) oszlopával monitorozza a replication_lag_sec helyreállítási pont célkitűzése (RPO) késését. A DMV másodpercek alatt jeleníti meg az elsődlegesen lekötött és a másodlagos tranzakciónaplóra rögzített tranzakciók közötti késést. Tegyük fel például, hogy a késés adott időpontban egy másodperc, ha az elsődlegesre hatással van egy kimaradás, és egy geo-feladatátvételt kezdeményeznek abban az időpontban, az utolsó másodpercben lekötött tranzakciók elvesznek.
  • Ha a feladatátvételi csoportok vagy az aktív georeplikálás engedélyezése nem lehetséges, fontolja meg a biztonsági mentési tár redundancia beállítását georedundáns biztonsági mentési tárolóra a georedundáns visszaállítási képesség használatához.
  • Gyakran tervezze meg és hajtsa végre a vészhelyreállítási próbákat , hogy ön jobban felkészüljön valós kimaradás esetén.

Másodlagos előkészítése kimaradás esetén

Egy másik adatrégióba való sikeres helyreállításhoz aktív georeplikációs, feladatátvételi csoportokkal vagy georedundáns visszaállítással egy másodlagos Azure SQL Database logikai kiszolgálót kell előkészítenie egy másik régióban. Szükség esetén ez a másodlagos kiszolgáló válhat az új elsődleges kiszolgálóvá. A zökkenőmentes helyreállítás érdekében jól meghatározott lépéseket is dokumentálni és tesztelni kell. Ezek az előkészítési lépések a következők:

  • Georedundáns visszaállításhoz azonosítsa a másik régióban lévő kiszolgálót, hogy az új elsődleges kiszolgáló legyen. Ez általában egy kiszolgáló a párosított régióban annak a régiónak, amelyben az elsődleges adatbázis található. Ha ugyanabban a régióban használ kiszolgálót, azzal kiküszöböli a georedundáns visszaállítási műveletek során felmerülő többletforgalmat.
  • Határozza meg, hogyan fogja átirányítani a felhasználókat az új elsődleges kiszolgálóra. A felhasználók átirányítása az alkalmazás kapcsolati sztring vagy DNS-bejegyzések manuális módosításával valósítható meg. Ha feladatátvételi csoportokat konfigurált, és az írásvédett és írásvédett figyelőt használja az alkalmazás kapcsolati sztring, nincs szükség további műveletre – a rendszer automatikusan átirányítja a kapcsolatokat az új elsődlegesre a feladatátvétel után.
  • Azonosítsa és opcionálisan definiálja azokat a tűzfalszabályokat, amelyek szükségesek ahhoz, hogy a felhasználók hozzáférhessenek az új elsődleges adatbázishoz.
  • Azonosítsa és igény szerint hozza létre azokat a bejelentkezéseket, amelyeknek szerepelniük kell az master új elsődleges kiszolgálón található adatbázisban, és ha vannak ilyenek, győződjön meg arról, hogy ezek a bejelentkezések rendelkeznek megfelelő engedélyekkel az master adatbázisban. További információkért tekintse meg az Azure SQL Database biztonsági funkcióit a vészhelyreállítás után.
  • Azonosítsa azokat a riasztási szabályokat, amelyeket frissíteni kell az új elsődlegesre való leképezéshez.
  • Dokumentálja a naplózási konfigurációt az aktuális elsődlegesen.

Kapcsolódó tartalom