Megosztás:

Magas rendelkezésre állás és vészhelyreállítási ellenőrzőlista – Azure SQL Database

A következőkre vonatkozik:Azure SQL Database

Az Azure SQL Database szolgáltatás automatikusan biztosítja, hogy az összes adatbázis online állapotban legyen, 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őlista

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

Magas rendelkezésre állású 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 az adatbázis vagy rugalmas készlet számára, ahol ez elérhető, hogy biztosítsa a zónális meghibásodások elleni ellenállóképességet.

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 leállás esetén katasztrófaelhárí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:

  • feladatátvételi csoportok engedélyezése adatbáziscsoportokhoz.
    • Használja az olvasási és írási, valamint az olvasásra korlátozott figyelővégpontokat az alkalmazás kapcsolati sztringjében, hogy az alkalmazások automatikusan csatlakozzanak az aktuális elsődleges kiszolgálóhoz és adatbázishoz.
    • Állítsa be a feladatátvételi szabályzatot a ügyfél által felügyelt.
  • Alternatívaként a feladatátvételi csoportok helyett engedélyezheti az aktív georeplikációt, hogy legyen egy olvasható másodlagos adatbázisa 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-k vagy virtuális magok) jön létre az elsődleges adatbázisként.
  • Felskálázáskor először a geo-másodlagost, majd az elsődlegest skálázza fel.
  • Lefelé skálázáskor fordítsa meg a sorrendet: először skálázza le az elsődlegeset, majd skálázza le a másodlagost.
  • 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(z) sp_wait_for_database_copy_sync hívása blokkolja a hívási szál végrehajtását, amíg az utolsó véglegesített tranzakció át nem kerül és véglegesen rögzítve van a másodlagos adatbázis tranzakciónaplójában.
  • Az elsődleges adatbázisban a replication_lag_sec dinamikus felügyeleti nézet (DMV) oszlopának használatával figyelje az RPO (helyreállítási pont célkitűzése) 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 egy másodperc egy adott időpontban. Ha az elsődleges rendszerre hatással van egy kimaradás, és ebben az időpontban geo-feladatátvitel kezdeményeződik, akkor az utolsó másodpercben rögzített tranzakciók elvesznek.
  • Ha nem lehetséges a feladatátvételi csoportok vagy az aktív georeplikálás engedélyezése, akkor fontolja meg, hogy a biztonsági mentési tár redundancia beállítását georedundáns biztonsági mentési tárra állítsa, hogy az Azure SQL Database geo-helyreállítást használni tudja.
  • Gyakran tervezhet és hajthat végre vészhelyreállítási próbákat, így jobban felkészülhet egy tényleges üzemkimaradás esetén.

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

Ha aktív georeplikáció, feladatátvételi csoportok vagy georestore segítségével szeretne sikeresen helyreállítást végezni egy másik adatrégióban, elő kell készítenie egy másodlagos Azure SQL Database logikai kiszolgálót egy másik adatré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ítson egy kiszolgálót egy másik régióban, hogy az új elsődleges kiszolgáló legyen. Ha az elsődleges régió párosított régióval rendelkezik, gyakori, hogy a párosított régiót másodlagos régióként használja. Ezzel általában csökkenti a replikációs és georedukciós műveletek késését.
  • 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áskapcsolati sztringek 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ás- és olvasási figyelőt használja az alkalmazás kapcsolati sztringjeiben, nincs szükség további műveletre – a kapcsolatokat automatikusan az új elsődlegesre irányítja a feladatátvétel után.
  • Azonosítsa és opcionálisan definiálja 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 új elsődleges kiszolgálón található master adatbázisban, és ha vannak ilyenek, győződjön meg arról, hogy ezek a bejelentkezések rendelkeznek a megfelelő engedélyekkel az master adatbázisban. További információért látogasson el ide: Az Azure SQL Database biztonságának konfigurálása és kezelése geovisszaállításhoz vagy feladatátvételhez.
  • Azonosítsa azokat a riasztási szabályokat, amelyeket frissíteni kell az új elsődlegeshez való illesztésre.
  • Dokumentálja a auditelési konfigurációt az aktuális elsődleges kiszolgálón, és tegye azonosá a másodlagos kiszolgálón.

Kapcsolódó tartalom

  • Last updated on