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

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

A Azure SQL Managed Instance szolgáltatás automatikusan biztosítja az összes adatbázis online, kifogástalan állapotát, és folyamatosan törekszik a 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 a Azure üzemkimaradások előkészítéséhez szükséges proaktív lépésekről. Ez az útmutató a Azure SQL Managed Instance összes 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 abban az esetben, ha elérhető, hogy a zónahibáknál a felügyelt SQL-példány rugalmasabb legyen.

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

Bár Azure SQL Managed Instance 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. A regionális Azure SQL Managed Instance kimaradás esetén szükség lehet vészhelyreállítás indítására.

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 egy példány esetén.
    • Használja az írás-olvasási és csak olvasási figyelővégpontokat az alkalmazás connection stringben, így az alkalmazások automatikusan csatlakoznak az elsődleges példányhoz.
    • Állítsa be a feladatátvételi szabályzatot ügyfél által felügyelt értékre.
  • Győződjön meg arról, hogy a geo-másodlagos példány ugyanazzal a szolgáltatási szinttel, hardvergenerációval és számítási mérettel jön létre, mint az elsődleges példány.
  • 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.
  • 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 van kialakítva, hogy az elsődleges és a másodlagos régió közötti aszinkron adatreplikálást használjon. 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 sp_wait_for_database_copy_sync hívása letiltja a hívási folyamatot, amíg az utolsó véglegesített tranzakciót nem továbbították és rögzítették 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 a helyreállítási pont célkitűzés (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 egy adott időpillanatban a késés egy másodperc, és ha az elsődleges rendszert kimaradás érinti, valamint abban az időpontban földrajzi feladatátvételt kezdeményeznek, akkor az utolsó másodpercben végrehajtott tranzakciók elvesznek.
  • Ha a feladatátvételi csoportok engedélyezése nem lehetséges, fontolja meg a mentési tár redundanciáját azzal beállítani, hogy georedundáns mentési tárolót használjon a geo-helyreállítási lehetőségkihasználására.
  • 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.

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

Ha feladatátviteli csoportokkal vagy geo-visszaállítással szeretne sikeresen helyreállítani egy másik adatrégióba, elő kell készítenie egy másodlagos Azure SQL Managed Instance-ot egy másik régióban. Szükség esetén ez a másodlagos példány válhat az új elsődleges példánysá. 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:

  • A földrajzi helyreállításhoz azonosítson egy másik régióban lévő példányt, hogy az új elsődleges példány 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-olvasási és írásvédett figyelőt használja az alkalmazás kapcsolati sztringjeiben, nincs szükség további műveletre – a rendszer automatikusan az új elsődleges adatbázisra irányítja a kapcsolatokat a feladatátvétel után.
  • Azonosítsa, és opcionálisan definiálja az NSG és az útvonaltábla konfigurációját, amely ahhoz szükséges, hogy a felhasználók hozzáférjenek az új elsődleges adatbázishoz az új elsődleges erőforráson.
  • 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.
  • Dokumentálja az aktuális elsődleges SQL Server Audit konfigurációját, majd azonosítsa a másodlagos példányon ugyanazt.

Kapcsolódó tartalom

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

  • Last updated on