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

Feladatátvételi csoportok áttekintése & ajánlott eljárások (Azure SQL Database)

  • Cikk

A következőre vonatkozik: Azure SQL Database

A feladatátvételi csoportok funkcióval kezelheti a logikai kiszolgálón lévő egyes vagy az összes adatbázis replikálását és feladatátvételét egy másik régióban lévő logikai kiszolgálóra. Ez a cikk áttekintést nyújt a feladatátvételi csoport funkcióról, és ajánlott eljárásokat és javaslatokat tartalmaz az Azure SQL Database-hez való használatához.

A funkció használatának megkezdéséhez tekintse át a Feladatátvételi csoport konfigurálása című cikket.

Feljegyzés

Ez a cikk az Azure SQL Database feladatátvételi csoportjait ismerteti. Felügyelt Azure SQL-példány esetén tekintse meg a felügyelt Azure SQL-példány feladatátvételi csoportjait.

Az Azure SQL Database vészhelyreállításáról az alábbi videóban olvashat bővebben:

Áttekintés

A feladatátvételi csoportok funkcióval kezelheti az adatbázisok replikálását és feladatátvételét egy másik Azure-régióba. A logikai kiszolgáló összes felhasználói adatbázisát vagy egy részhalmazát kiválaszthatja egy másik logikai kiszolgálóra replikálni. Ez egy deklaratív absztrakció az aktív georeplikációs funkción felül, amely a georeplikált adatbázisok nagy léptékű üzembe helyezésének és felügyeletének egyszerűsítésére szolgál.

A geo feladatátvételi RPO és az RTO esetében tekintse meg az üzletmenet-folytonosság áttekintését.

Végpont átirányítása

A feladatátvételi csoportok írásvédett és írásvédett figyelő végpontokat biztosítanak, amelyek a geo feladatátvétel során változatlanok maradnak. A geo feladatátvétel után nem kell módosítania az alkalmazás kapcsolati sztring, mert a kapcsolatok automatikusan az aktuális elsődlegesre lesznek irányítva. A geo feladatátvétel a csoport összes másodlagos adatbázisát az elsődleges szerepkörre váltja. A geo feladatátvétel befejezése után a DNS-rekord automatikusan frissül, hogy átirányítsa a végpontokat az új régióba.

Írásvédett számítási feladatok kiszervezése

Az elsődleges adatbázisok forgalmának csökkentése érdekében a feladatátvételi csoport másodlagos adatbázisait is használhatja az írásvédett számítási feladatok kiszervezéséhez. Az írásvédett figyelővel irányíthatja az írásvédett forgalmat egy olvasható másodlagos adatbázisba.

Alkalmazás helyreállítása

A teljes üzletmenet-folytonosság érdekében a regionális adatbázis-redundancia hozzáadása csak része a megoldásnak. Egy alkalmazás (szolgáltatás) teljes körű helyreállítása katasztrofális hiba után a szolgáltatást alkotó összes összetevő és a függő szolgáltatások helyreállítását igényli. Ilyen összetevők például az ügyfélszoftver (például egy egyéni JavaScripttel rendelkező böngésző), a webes előtér, a tárolás és a DNS. Kritikus fontosságú, hogy minden összetevő ellenálló legyen ugyanazokkal a hibákkel szemben, és az alkalmazás helyreállítási időkorlátján (RTO) belül elérhetővé váljon. Ezért azonosítania kell az összes függő szolgáltatást, és ismernie kell az általuk biztosított garanciákat és képességeket. Ezután meg kell tennie a megfelelő lépéseket annak biztosítására, hogy a szolgáltatás működjön azon szolgáltatások feladatátvétele során, amelyektől függ.

Feladatátvételi szabályzat

A feladatátvételi csoportok két feladatátvételi házirendet támogatnak:

  • Ügyfél által felügyelt (ajánlott) – Az ügyfelek feladatátvételt végezhetnek egy csoporton, ha olyan váratlan leállást észlelnek, amely hatással van a feladatátvételi csoport egy vagy több adatbázisára. Parancssori eszközök, például a PowerShell, az Azure CLI vagy a Rest API használatakor a felügyelt ügyfél feladatátvételi szabályzatának értéke .manual
  • Microsoft által felügyelt – Egy elsődleges régiót érintő széles körű kimaradás esetén a Microsoft feladatátvételt kezdeményez az összes érintett feladatátvételi csoport számára, amelyek feladatátvételi szabályzata a Microsoft általi felügyeletre van konfigurálva. A Microsoft által felügyelt feladatátvétel nem indítható el az egyes feladatátvételi csoportok vagy egy régió feladatátvételi csoportjainak egy részhalmaza esetében. Parancssori eszközök, például a PowerShell, az Azure CLI vagy a Rest API használatakor a Microsoft által felügyelt feladatátvételi szabályzat értéke.automatic

Minden feladatátvételi szabályzat egyedi használati esetekkel és megfelelő elvárásokkal rendelkezik a feladatátvételi hatókörrel és az adatvesztéssel kapcsolatban, ahogy az alábbi táblázat összefoglalja:

Feladatátvételi szabályzat Feladatátvételi hatókör Használati eset Lehetséges adatvesztés
Ügyfél által kezelt
(Ajánlott)		 Feladatátvételi csoport(ok) A feladatátvételi csoport(ok) egy vagy több adatbázisát kimaradás érinti, és elérhetetlenné válik. Dönthet úgy, hogy feladatátvételt szeretne végrehajtani. Igen
Microsoft által kezelt A régió összes feladatátvételi csoportja Az adatközpontok, rendelkezésre állási zónák vagy régiók széles körű leállása az adatbázisok elérhetetlenségét okozza, és a Microsoft Azure SQL szolgáltatás csapata úgy dönt, hogy kényszerített feladatátvételt indít el.
Ezt a lehetőséget csak akkor használja, ha a vészhelyreállítási felelősséget a Microsoftnak szeretné delegálni, és az alkalmazás legalább egy óra állásidőt (RTO) tolerál.		 Igen

Ügyfél által kezelt

Ritkán a beépített rendelkezésre állás vagy magas rendelkezésre állás nem elegendő a kimaradás csökkentéséhez, és előfordulhat, hogy a feladatátvételi csoport adatbázisai nem lesznek elérhetők az adatbázisokat használó alkalmazások szolgáltatásiszint-szerződése (SLA) számára elfogadható ideig. Az adatbázisok csak néhány adatbázist érintő honosított probléma miatt nem érhetők el, vagy az adatközpont, a rendelkezésre állási zóna vagy a régió szintjén lehetnek. Az üzletmenet-folytonosság visszaállításához bármelyik esetben kezdeményezhet kényszerített feladatátvételt.

A feladatátvételi szabályzat ügyfél által felügyeltre történő beállítása erősen ajánlott, mivel így szabályozhatja, hogy mikor kezdeményezhet feladatátvételt, és visszaállíthatja az üzletmenet folytonosságát. Feladatátvételt akkor kezdeményezhet, ha váratlan leállást észlel, amely hatással van a feladatátvételi csoport egy vagy több adatbázisára.

Microsoft által kezelt

A Microsoft által felügyelt feladatátvételi szabályzattal a vészhelyreállítási felelősség delegálva lesz az Azure SQL szolgáltatásba. Ahhoz, hogy az Azure SQL szolgáltatás kényszerített feladatátvételt kezdeményezhesse, a következő feltételeknek kell teljesülnie:

  • Az adatközpont, a rendelkezésre állási zóna vagy a régiószintű kimaradás természeti katasztrófaesemény, konfigurációs változások, szoftverhibák vagy hardverösszetevő-hibák, valamint a régió számos adatbázisa által okozott kimaradásra hatással van.
  • A türelmi időszak lejárt. Mivel a kimaradás mértékének ellenőrzése és enyhítése az emberi műveletektől függ, a türelmi időszak nem állítható be egy óra alatt.

Ha teljesülnek ezek a feltételek, az Azure SQL szolgáltatás kényszerített feladatátvételt kezdeményez a régió azon feladatátvételi csoportjai számára, amelyek feladatátvételi szabályzatát a Microsoft kezeli.

A feladatátvételi szabályzatot csak akkor állítsa a Microsoft által kezeltre, ha:

  • A vészhelyreállítási felelősséget az Azure SQL szolgáltatásra szeretné delegálni.
  • Az alkalmazás toleráns, hogy az adatbázis legalább egy órán át nem érhető el.
  • A kényszerített feladatátvételek aktiválása a türelmi időszak lejárta után egy ideig elfogadható, mivel a kényszerített feladatátvétel tényleges ideje jelentősen változhat.
  • Elfogadható, hogy a feladatátvételi csoportban lévő összes adatbázis feladatátvételt kap, függetlenül a zónaredundancia-konfigurációjuktól vagy a rendelkezésre állási állapotuktól. Bár a zónaredundanciára konfigurált adatbázisok rugalmasak a zónaszintű hibákkal szemben, és előfordulhat, hogy a kimaradás nem érinti őket, akkor is feladatátvételt hajtanak végre, ha egy Microsoft által felügyelt feladatátvételi szabályzattal rendelkező feladatátvételi csoport részét képezik.
  • Elfogadható, ha a feladatátvételi csoportban lévő adatbázisok kényszerített feladatátvétele nem veszi figyelembe az alkalmazás más Azure-szolgáltatásoktól vagy az alkalmazás által használt összetevőktől való függőségét, ami teljesítménycsökkenést vagy az alkalmazás elérhetetlenségét okozhatja.
  • Elfogadható, ha ismeretlen mennyiségű adatvesztést okoz, mivel a kényszerített feladatátvétel pontos ideje nem szabályozható, és figyelmen kívül hagyja a másodlagos adatbázisok szinkronizálási állapotát.
  • A feladatátvételi csoport összes elsődleges és másodlagos adatbázisa ugyanazzal a szolgáltatási szinttel, számítási szinttel (kiépített vagy kiszolgáló nélküli) & számítási mérettel (DTU-k vagy virtuális magok) rendelkezik. Ha a feladatátvételi csoport összes adatbázisának szolgáltatásiszint-célkitűzése (SLO) nem egyezik meg, akkor a feladatátvételi szabályzat végül frissül a Microsoft felügyeltről az Azure SQL szolgáltatás által felügyelt ügyfélre.

Amikor a Microsoft elindít egy feladatátvételt, a rendszer hozzáad egy bejegyzést a feladatátvételi Azure SQL feladatátvételi csoporthoz az Azure Monitor tevékenységnaplójában. A bejegyzés tartalmazza az Erőforrás alatti feladatátvételi csoport nevét, és az eseményt egyetlen kötőjel (-) jelzi, hogy a feladatátvételt a Microsoft kezdeményezte. Ezek az információk az új elsődleges kiszolgáló vagy -példány Tevékenységnapló lapján is megtalálhatók az Azure Portalon.

Terminológia és képességek

  • Feladatátvételi csoport (FOG)

    A feladatátvételi csoport az azure-beli egyetlen logikai kiszolgáló által felügyelt adatbázisok nevesített csoportja, amely egységként feladatátvételt hajthat végre egy másik Azure-régióban, ha az elsődleges régióban kimaradás miatt az összes vagy néhány elsődleges adatbázis elérhetetlenné válik.

    Fontos

    A feladatátvételi csoport nevének globálisan egyedinek kell lennie a .database.windows.net tartományon belül.

  • Kiszolgálók

    A logikai kiszolgálón lévő felhasználói adatbázisok egy része vagy egésze feladatátvételi csoportba helyezhető. A kiszolgáló emellett több feladatátvételi csoportot is támogat egyetlen kiszolgálón.

  • Elsődleges

    A feladatátvételi csoportban az elsődleges adatbázisokat üzemeltető logikai kiszolgáló.

  • Másodlagos

    A feladatátvételi csoportban a másodlagos adatbázisokat üzemeltető logikai kiszolgáló. A másodlagos nem lehet ugyanabban az Azure-régióban, mint az elsődleges.

  • Feladatátvétel (nincs adatvesztés)

    A feladatátvétel teljes adatszinkronizálást végez az elsődleges és a másodlagos adatbázisok között, mielőtt a másodlagos átvált az elsődleges szerepkörre. Ez nem garantálja az adatvesztést. Feladatátvétel csak akkor lehetséges, ha az elsődleges elérhető. A feladatátvétel a következő esetekben használatos:

    • Vészhelyreállítási (DR) próbák végrehajtása éles környezetben, ha az adatvesztés nem elfogadható
    • A számítási feladat áthelyezése másik régióba
    • A kimaradás enyhítése (feladat-visszavétel) után adja vissza a számítási feladatot az elsődleges régióba

  • Kényszerített feladatátvétel (lehetséges adatvesztés)

    A kényszerített feladatátvétel azonnal átváltja a másodlagost az elsődleges szerepkörre anélkül, hogy megvárná a legutóbbi módosítások propagálását az elsődlegesről. Ez a művelet potenciális adatvesztést okozhat. A kényszerített feladatátvétel helyreállítási módszerként használatos a kimaradások során, ha az elsődleges nem érhető el. A kimaradás mérséklésekor a régi elsődleges automatikusan újracsatlakozik, és új másodlagossá válik. Feladatátvételt hajthat végre a feladat-visszavételhez, és visszaadhatja a replikákat az eredeti elsődleges és másodlagos szerepköreiknek.

  • Türelmi időszak adatvesztéssel

    Mivel az adatok aszinkron replikációval replikálódnak a másodlagosra, a Microsoft által felügyelt feladatátvételi szabályzatokkal rendelkező csoportok kényszerített feladatátvétele adatvesztést okozhat. Testre szabhatja a feladatátvételi szabályzatot, hogy tükrözze az alkalmazás adatvesztéssel szembeni tűrőképességét. Konfigurálásával GracePeriodWithDataLossHoursszabályozhatja, hogy az Azure SQL szolgáltatás mennyi ideig várjon a kényszerített feladatátvétel kezdeményezése előtt, ami adatvesztést okozhat.

  • Önálló adatbázisok hozzáadása feladatátvételi csoporthoz

    Több önálló adatbázist is elhelyezhet ugyanazon a logikai kiszolgálón ugyanabba a feladatátvételi csoportba. Ha egyetlen adatbázist ad hozzá a feladatátvételi csoporthoz, az automatikusan létrehoz egy másodlagos adatbázist ugyanazzal a kiadással és számítási méretekkel a feladatátvételi csoport létrehozásakor megadott másodlagos kiszolgálón. Ha olyan adatbázist ad hozzá, amely már rendelkezik másodlagos adatbázissal a másodlagos kiszolgálón, a georeplikációs kapcsolatot a csoport örökli. Ha olyan adatbázist vesz fel, amely már rendelkezik másodlagos adatbázissal egy olyan kiszolgálón, amely nem része a feladatátvételi csoportnak, egy új másodlagos adatbázis jön létre a másodlagos kiszolgálón.

    Fontos

    • Győződjön meg arról, hogy a másodlagos logikai kiszolgáló nem rendelkezik ugyanazzal a névvel rendelkező adatbázissal, kivéve, ha az egy meglévő másodlagos adatbázis.
    • Ha egy adatbázis memórián belüli OLTP-objektumokat tartalmaz, az elsődleges adatbázisnak és a másodlagos georeplika-adatbázisnak egyező szolgáltatási szinttel kell rendelkeznie, mivel a memóriában lévő OLTP-objektumok a memóriában találhatók. A georeplika-adatbázis alacsonyabb szolgáltatási szintje memóriakihasználtsághoz vezethet. Ha ez történik, előfordulhat, hogy a georeplika nem tudja helyreállítani az adatbázist, ami a másodlagos adatbázis és a memóriában lévő OLTP-objektumok rendelkezésre állását okozza a geo-másodlagoson. Ez viszont a feladatátvétel sikertelenségéhez is vezethet. Ennek elkerülése érdekében győződjön meg arról, hogy a geo-másodlagos adatbázis szolgáltatási szintje megegyezik az elsődleges adatbázis szolgáltatási szintjére. A szolgáltatásszint-frissítések adatméret-műveletek lehetnek, és eltarthat egy ideig.

  • Adatbázisok hozzáadása rugalmas készletben a feladatátvételi csoporthoz

    Egy rugalmas készleten belül az összes vagy több adatbázist ugyanabba a feladatátvételi csoportba helyezheti. Ha az elsődleges adatbázis rugalmas készletben található, a másodlagos adatbázis automatikusan létrejön a rugalmas készletben ugyanazzal a névvel (másodlagos készlet). Győződjön meg arról, hogy a másodlagos kiszolgáló ugyanolyan nevű rugalmas készletet tartalmaz, és elegendő szabad kapacitással rendelkezik a feladatátvételi csoport által létrehozott másodlagos adatbázisok üzemeltetéséhez. Ha olyan adatbázist ad hozzá a készlethez, amely már rendelkezik másodlagos adatbázissal a másodlagos készletben, a georeplikációs kapcsolatot a csoport örökli. Ha olyan adatbázist vesz fel, amely már rendelkezik másodlagos adatbázissal egy olyan kiszolgálón, amely nem része a feladatátvételi csoportnak, egy új másodlagos adatbázis jön létre a másodlagos készletben.

  • Feladatátvételi csoport írható és olvasható figyelője

    Egy DNS CNAME rekord, amely az aktuális elsődlegesre mutat. A feladatátvételi csoport létrehozásakor automatikusan létrejön, és lehetővé teszi, hogy az olvasási-írási számítási feladat transzparensen újra csatlakozzon az elsődlegeshez, amikor az elsődleges változás a feladatátvételt követően változik. Amikor a feladatátvételi csoportot egy kiszolgálón hozza létre, a figyelő URL-címének DNS CNAME rekordja a következőképpen alakul.<fog-name>.database.windows.net A feladatátvétel után a RENDSZER automatikusan frissíti a DNS-rekordot, hogy átirányítsa a figyelőt az új elsődlegesre.

  • Feladatátvételi csoport írásvédett figyelője

    Egy DNS CNAME rekord, amely az aktuális másodlagosra mutat. A feladatátvételi csoport létrehozásakor automatikusan létrejön, és lehetővé teszi, hogy az írásvédett SQL-számítási feladat transzparens módon csatlakozzon a másodlagoshoz, amikor a másodlagos módosítás a feladatátvétel után megváltozik. Amikor a feladatátvételi csoportot egy kiszolgálón hozza létre, a figyelő URL-címének DNS CNAME rekordja a következőképpen alakul.<fog-name>.secondary.database.windows.net Alapértelmezés szerint az írásvédett figyelő feladatátvétele le van tiltva, mivel biztosítja, hogy az elsődleges teljesítmény ne legyen hatással a másodlagos kapcsolat nélküli állapotra. Ez azonban azt is jelenti, hogy az írásvédett munkamenetek nem fognak tudni csatlakozni, amíg a másodlagos munkamenet helyre nem áll. Ha nem tudja tolerálni az állásidőt az írásvédett munkamenetek esetében, és az elsődlegest írásvédett és írásvédett forgalomhoz is használhatja az elsődleges teljesítménycsökkenés rovására, a tulajdonság konfigurálásával engedélyezheti a feladatátvételt az AllowReadOnlyFailoverToPrimary írásvédett figyelő számára. Ebben az esetben a rendszer automatikusan átirányítja az írásvédett forgalmat az elsődlegesre, ha a másodlagos nem érhető el.

    Feljegyzés

    A AllowReadOnlyFailoverToPrimary tulajdonság csak akkor érvényes, ha a Microsoft által felügyelt feladatátvételi szabályzat engedélyezve van, és a rendszer kényszerített feladatátvételt aktivált. Ebben az esetben, ha a tulajdonság Értéke Igaz, az új elsődleges az írási és írásvédett munkameneteket is kiszolgálja.

  • Több feladatátvételi csoport

    Több feladatátvételi csoportot is konfigurálhat ugyanahhoz a kiszolgálópárhoz a geo feladatátvétel hatókörének szabályozásához. Minden csoport egymástól függetlenül meghiúsul. Ha a bérlőnkénti adatbázis-alkalmazás több régióban van üzembe helyezve, és rugalmas készleteket használ, akkor ezt a képességet használhatja az egyes készletek elsődleges és másodlagos adatbázisainak keverésére. Így csökkentheti a kimaradás hatását csak néhány bérlői adatbázisra.

Feladatátvételi csoport architektúrája

Az Azure SQL Database feladatátvételi csoportja tartalmazhat egy vagy több adatbázist, amelyeket általában ugyanaz az alkalmazás használ. Egy feladatátvételi csoportot kell konfigurálni az elsődleges kiszolgálón, amely egy másik Azure-régió másodlagos kiszolgálóhoz csatlakoztatja. A feladatátvételi csoport az elsődleges kiszolgálón lévő összes adatbázist vagy adatbázist is tartalmazhat. Az alábbi ábra egy georedundáns felhőalkalmazás tipikus konfigurációját mutatja be több adatbázist használó feladatátvételi csoportban:

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

A szolgáltatás üzletmenet-folytonosságot szem előtt tartva történő tervezésekor kövesse az ebben a cikkben ismertetett általános irányelveket és ajánlott eljárásokat. Feladatátvételi csoport konfigurálásakor győződjön meg arról, hogy a másodlagos hitelesítés és hálózati hozzáférés megfelelően működik a geo feladatátvétel után, amikor a geo-másodlagos lesz az új elsődleges. További részletekért tekintse meg az SQL Database vészhelyreállítás utáni biztonságát. További információ: Felhőmegoldások tervezése vészhelyreállításhoz.

Párosított régiók használata

Amikor a feladatátvételi csoportot az elsődleges és a másodlagos kiszolgáló között hozza létre, párosított régiókat használjon, mivel a párosított régiókban a feladatátvételi csoportok teljesítménye jobb a nem fizetett régiókhoz képest.

A biztonságos üzembehelyezési eljárásokat követve az Azure SQL Database általában nem frissíti egyszerre a párosított régiókat. Azonban nem lehet előrejelezni, hogy melyik régiót frissítik először, így az üzembe helyezés sorrendje nem garantált. Előfordulhat, hogy az elsődleges kiszolgálót először frissítik, és néha másodikra frissítik.

Ha olyan adatbázisokhoz van konfigurálva georeplikációs vagy feladatátvételi csoportok , amelyek nem összhangban vannak az Azure-régió párosításával, használjon különböző karbantartási időszakokat az elsődleges és a másodlagos adatbázisokhoz. Kiválaszthatja például a másodlagos adatbázis hétköznapi karbantartási időszakát, az elsődleges adatbázis hétvégi karbantartási időszakát.

Kezdeti vetés

Amikor adatbázisokat vagy rugalmas készleteket ad hozzá egy feladatátvételi csoporthoz, az adatreplikálás megkezdése előtt van egy kezdeti üzembe helyezési fázis. A kezdeti vetés fázisa a leghosszabb és legdrágább művelet. A kezdeti vetés befejeződése után az adatok szinkronizálódnak, majd csak az azt követő adatmódosítások replikálódnak. A kezdeti vetés befejezéséhez szükséges idő az adatok méretétől, a replikált adatbázisok számától, az elsődleges adatbázisok terhelésétől, valamint az elsődleges és a másodlagos adatbázis közötti hálózati kapcsolat sebességétől függ. Normál körülmények között az SQL Database esetében a vetés sebessége óránként akár 500 GB is lehet. A vetés az összes adatbázis esetében párhuzamosan történik.

Több feladatátvételi csoport használata több adatbázis feladatátvételéhez

Egy vagy több feladatátvételi csoport hozható létre két különböző régióban lévő kiszolgáló között (elsődleges és másodlagos kiszolgálók). Minden csoport tartalmazhat egy vagy több, egységként helyreállított adatbázist abban az esetben, ha az elsődleges régióban kimaradás miatt az összes vagy néhány elsődleges adatbázis elérhetetlenné válik. Feladatátvételi csoport létrehozása olyan geo-másodlagos adatbázisokat hoz létre, amelynek szolgáltatási célja megegyezik az elsődlegesével. Ha meglévő georeplikációs kapcsolatot ad hozzá egy feladatátvételi csoporthoz, győződjön meg arról, hogy a georeplikáció ugyanazzal a szolgáltatási szinttel és számítási mérettel van konfigurálva, mint az elsődleges.

Írás-olvasás figyelő használata (elsődleges)

Írható és olvasható számítási feladatok esetén a kapcsolati sztringben használja a következő kiszolgálónevet: <fog-name>.database.windows.net. Csatlakozás ionok automatikusan az elsődlegesre lesznek irányítva. Ez a név nem változik a feladatátvétel után. Vegye figyelembe, hogy a feladatátvétel magában foglalja a DNS-rekord frissítését, így az ügyfélkapcsolatok csak az ügyfél DNS-gyorsítótárának frissítése után lesznek átirányítva az új elsődlegesre. Az elsődleges és másodlagos figyelő DNS-rekordjának élettartama (TTL) 30 másodperc.

Írásvédett figyelő használata (másodlagos)

Ha logikailag izolált írásvédett számítási feladatokkal rendelkezik, amelyek tolerálják az adatkéséseket, futtathatja őket a földrajzi másodlagos helyen. Írásvédett számítási feladatok esetén a kapcsolati sztringben használja a következő kiszolgálónevet: <fog-name>.secondary.database.windows.net. Csatlakozás a rendszer automatikusan a geo másodlagosra irányítja a rendszer. Azt is javasoljuk, hogy az olvasási szándékot a kapcsolati sztring használjaApplicationIntent=ReadOnly.

A Prémium, üzletileg kritikus és Rugalmas skálázású szolgáltatási szinteken az SQL Database támogatja az írásvédett replikák használatát az írásvédett lekérdezési számítási feladatok kiszervezéséhez a ApplicationIntent=ReadOnly kapcsolati sztring paraméter használatával. Ha geo-másodlagosat konfigurált, ezzel a képességgel csatlakozhat egy írásvédett replikához az elsődleges helyen vagy a földrajzilag másodlagos helyen:

Ha csak olvasható replikához szeretne csatlakozni a másodlagos helyen, használja ApplicationIntent=ReadOnly és <fog-name>.secondary.database.windows.net.

Lehetséges teljesítménycsökkenés feladatátvétel után

Egy tipikus Azure-alkalmazás több Azure-szolgáltatást használ, és több összetevőből áll. Egy csoport feladatátvétele egyedül az Azure SQL-adatbázis állapota alapján aktiválódik. Előfordulhat, hogy az elsődleges régióban más Azure-szolgáltatásokat nem érint a kimaradás, és az összetevőik továbbra is elérhetők lehetnek ebben a régióban. Ha az elsődleges adatbázisok a másodlagos (DR) régióra váltanak, a függő összetevők közötti késleltetés mértéke nőhet. A nagyobb késleltetésnek az alkalmazás teljesítményére gyakorolt hatásának elkerülése érdekében gondoskodjon az alkalmazás összes összetevőjének redundanciájáról a DR régióban, kövesse ezeket a hálózati biztonsági irányelveket, és szervezze meg a megfelelő alkalmazás-összetevők földrajzi feladatátvételét az adatbázissal együtt.

Lehetséges adatvesztés kényszerített feladatátvétel után

Ha kimaradás történik az elsődleges régióban, előfordulhat, hogy a legutóbbi tranzakciók replikálása még nem történt meg a földrajzi másodlagosra, és adatvesztés következhet be, ha kényszerített feladatátvételt hajtanak végre.

Fontos

A rugalmas készletek 800 vagy kevesebb DTU-val vagy 8 vagy kevesebb virtuális maggal, valamint több mint 250 adatbázissal problémákba ütközhetnek, beleértve a hosszabb tervezett geo feladatátvételeket és a csökkentett teljesítményt. Ezen problémák bekövetkezése valószínűbb nagy írási igényű számítási feladatok esetében, ha a georeplikák földrajzilag nagy távolságra helyezkednek el egymástól, vagy ha az egyes adatbázisokhoz több másodlagos georeplikát is használnak. Az ilyen problémák egyik tünete az idő múlásával növekedő georeplikációs késés, amely szolgáltatáskimaradás esetén kiterjedtebb adatvesztéshez vezethet. Ez a késleltetés a sys.dm_geo_replication_link_status használatával figyelhető meg. Ha ezek a problémák előfordulnak, a kockázatcsökkentés részeként a készlet több DTU-val vagy virtuális maggal vertikálisan felskálázható, vagy a készletben lévő georeplikált adatbázisok száma csökkenthető.

Feladat-visszavétel

Ha a feladatátvételi csoportok Microsoft által felügyelt feladatátvételi szabályzattal vannak konfigurálva, akkor a rendszer a megadott türelmi időszaknak megfelelő vészforgatókönyvben kezdeményezi a geo-másodlagos kiszolgálóra történő kényszerített feladatátvételt. A régi elsődleges feladat-visszavételt manuálisan kell kezdeményezni.

Engedélyek és korlátozások

Tekintse át a feladatátvételi csoport konfigurálási útmutatóját az engedélyek és korlátozások listájához.

Feladatátvételi csoportok programozott kezelése

A feladatátvételi csoportok programozott módon is kezelhetők az Azure PowerShell, az Azure CLI és a REST API használatával. További információért lásd: Feladatátvételi csoport konfigurálása.

Kapcsolódó tartalom