Megosztás:

Magas rendelkezésre állás és vészhelyreállítási ellenőrzőlista – Felügyelt Azure SQL-példány

A következőkre vonatkozik:Azure SQL-felügyelt példány

Az Azure SQL Managed Instance 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ó a felügyelt Azure SQL-példány ö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 a felügyelt Azure SQL-példány automatikusan fenntartja a rendelkezésre állást, vannak olyan példányok, amelyek még magas rendelkezésre állással (zónaredundanciával) sem garantálják a rugalmasságot, mivel a kimaradás egy teljes régióra kiterjed. Előfordulhat, hogy egy régióbeli Azure SQL Megszakítás miatt 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:

  • feladatátvételi csoportok engedélyezése egy példány esetén.
    • Használja az olvasási és írási, valamint az írásvédett figyelővégpontokat az alkalmazás kapcsolati sztringjében, hogy az alkalmazások automatikusan az elsődleges példányhoz csatlakozzanak.
    • Á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 sys.dm_geo_replication_link_status dinamikus felügyeleti nézet (DMV) replication_lag_sec 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átvételi csoportokkal vagy georestore-ral szeretne sikeresen helyreállítani egy másik adatrégióba, elő kell készítenie egy másodlagos Azure SQL Felügyelt Példányt 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 a naplózási konfigurációs az aktuális elsődleges példányon, és azonos legyen a másodlagos példányon.

Kapcsolódó tartalom

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

  • Last updated on