Feladatátvételi csoportok áttekintése és ajánlott eljárások – Felügyelt Azure SQL-példány

  • Cikk

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

A feladatátvételi csoportok funkcióval kezelheti egy felügyelt példány összes felhasználói adatbázisának replikálását és feladatátvételét egy másik Azure-régióba. Ez a cikk áttekintést nyújt a feladatátvételi csoport funkcióról, és ajánlott eljárásokat és javaslatokat tartalmaz a felügyelt Azure SQL-példányokkal való használathoz.

A funkció használatának megkezdéséhez tekintse át a felügyelt Azure SQL-példány feladatátvételi csoportjának konfigurálását.

Áttekintés

A feladatátvételi csoportok funkcióval kezelheti a felügyelt példányban lévő felhasználói adatbázisok replikálását és feladatátvételét egy másik Azure-régióban lévő felügyelt példányra. A feladatátvételi csoportok célja a georeplikált adatbázisok nagy léptékű üzembe helyezése és felügyelete.

További információ: Magas rendelkezésre állás a felügyelt Azure SQL-példányhoz. 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 lehetővé teszi, hogy a felügyelt példányon belüli összes felhasználói adatbázis egységként átvehesse a feladatátvételt egy másik Azure-régióba abban az esetben, ha az elsődleges felügyelt példány elérhetetlenné válik egy elsődleges régió leállása miatt. Mivel a felügyelt SQL-példány feladatátvételi csoportjai tartalmazzák a példányon belüli összes felhasználói adatbázist, egy példányon csak egy feladatátvételi csoport konfigurálható.

    Fontos

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

  • Elsődleges

    A feladatátvételi csoportban az elsődleges adatbázisokat üzemeltető felügyelt példány.

  • Másodlagos

    A feladatátvételi csoportban a másodlagos adatbázisokat üzemeltető felügyelt példány. A másodlagos nem lehet ugyanabban az Azure-régióban, mint az elsődleges.

    Fontos

    • Ha egy adatbázis memórián belüli OLTP-objektumokat tartalmaz, az elsődleges és másodlagos georeplikapéldánynak egyező szolgáltatási szintekkel kell rendelkeznie, mivel a memóriában lévő OLTP-objektumok a memóriában találhatók. A georeplikapéldány alacsonyabb szolgáltatási szintje memóriakihasználtsághoz vezethet. Ha ez történik, előfordulhat, hogy a másodlagos replika 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 példány szolgáltatási szintje megegyezik az elsődleges adatbázis szolgáltatási szintjére. A szolgáltatásszint-frissítések lehetnek adatméret-műveletek, és eltarthat egy ideig.

  • 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.

  • DNS-zóna

    Egy egyedi azonosító, amely automatikusan létrejön egy új felügyelt SQL-példány létrehozásakor. A példányhoz többtartományos (SAN) tanúsítvány van kiépítve, amely hitelesíti az ügyfélkapcsolatokat az ugyanabban a DNS-zónában lévő bármely példányhoz. Az ugyanabban a feladatátvételi csoportban lévő két felügyelt példánynak meg kell osztania a DNS-zónát.

  • 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. Ha a feladatátvételi csoport egy felügyelt SQL-példányon jön létre, a figyelő URL-címének DNS CNAME rekordja a következőképpen alakul.<fog-name>.<zone_id>.database.windows.net

  • 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. Ha a feladatátvételi csoport egy felügyelt SQL-példányon jön létre, a figyelő URL-címének DNS CNAME rekordja a következőképpen alakul.<fog-name>.secondary.<zone_id>.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.

Feladatátvételi csoport architektúrája

A feladatátvételi csoportot konfigurálni kell az elsődleges példányon, és egy másik Azure-régió másodlagos példányához kell csatlakoztatni. A példányban lévő összes felhasználói adatbázis replikálva lesz a másodlagos példányra. A rendszeradatbázisok szeretik master és msdb nem replikálják.

Az alábbi ábra egy georedundáns felhőalkalmazás tipikus konfigurációját mutatja be felügyelt példány és feladatátvételi csoport használatával:

diagram of a failover group for Azure SQL Managed Instance.

Ha az alkalmazás a felügyelt SQL-példányt használja adatszintként, kövesse az üzletmenet-folytonosság tervezésekor a cikkben ismertetett általános irányelveket és ajánlott eljárásokat.

A geo-másodlagos példány létrehozása

A feladatátvételt követően az elsődleges felügyelt SQL-példányhoz való folyamatos kapcsolódás biztosításához az elsődleges és a másodlagos példánynak is ugyanabban a DNS-zónában kell lennie. Garantálja, hogy ugyanaz a többtartományos (SAN) tanúsítvány használható a feladatátvételi csoport két példányának ügyfélkapcsolatainak hitelesítésére. Ha az alkalmazás készen áll az éles üzembe helyezésre, hozzon létre egy másodlagos felügyelt SQL-példányt egy másik régióban, és győződjön meg arról, hogy megosztja a DNS-zónát az elsődleges felügyelt SQL-példánysal. Ezt úgy teheti meg, hogy megad egy opcionális paramétert a létrehozás során. Ha a PowerShellt vagy a REST API-t használja, az opcionális paraméter neve .DNSZonePartner Az ennek megfelelő, nem kötelezően kitöltendő mező neve az Azure Portalon: Elsődleges felügyelt példány.

Fontos

Az alhálózatban létrehozott első felügyelt példány határozza meg a DNS-zónát az adott alhálózat összes későbbi példányához. Ez azt jelenti, hogy ugyanazon alhálózat két példánya nem tartozhat különböző DNS-zónákhoz.

A másodlagos felügyelt SQL-példánynak az elsődleges példánysal azonos DNS-zónában való létrehozásáról további információt a felügyelt Azure SQL-példány feladatátvételi csoportjának konfigurálása című témakörben talál.

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

A jobb teljesítmény érdekében mindkét felügyelt példányt párosított régiókban helyezze üzembe. Az SQL Managed Instance feladatátvételi csoportjainak teljesítménye jobb a párosított régiókban a nem párosított régiókhoz képest.

A felügyelt Azure SQL-példány olyan biztonságos üzembehelyezési gyakorlatot követ, amelyben az Azure párosított régiói általában nem egyszerre vannak üzembe helyezve. 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 először az elsődleges példányt frissíti, néha pedig a másodlagos példányt.

Ha a felügyelt Azure SQL-példány egy feladatátvételi csoport része, és a csoport példányai nem az Azure párosított régióiban találhatók, válassza ki az elsődleges és a másodlagos adatbázis különböző karbantartási időszakainak ütemezését. Válasszon például egy hétköznapi karbantartási időszakot a geo-másodlagos adatbázishoz, és egy hétvégi karbantartási időszakot a geo-elsődleges adatbázishoz.

A példányok közötti georeplikációs adatforgalom engedélyezése és optimalizálása

Csatlakozás kapcsolatot az elsődleges és másodlagos példányt üzemeltető virtuális hálózati alhálózatok között a folyamatos georeplikációs forgalom érdekében létre kell hozni és fenn kell tartani. A hálózati topológia és a szabályzatok alapján többféleképpen is biztosíthatja a kapcsolatot a példányok között:

A globális virtuális hálózati társhálózat-létesítés (VNet-társviszony) a feladatátvételi csoport két példánya közötti kapcsolat létesítésére ajánlott módszer. Kis késésű, nagy sávszélességű privát kapcsolatot biztosít a társított virtuális hálózatok között a Microsoft gerincinfrastruktúrájának használatával. A társviszonyban lévő virtuális hálózatok közötti kommunikációhoz nincs szükség nyilvános internetre, átjárókra vagy további titkosításra.

Kezdeti vetés

A felügyelt példányok közötti feladatátvételi csoport létrehozásakor az adatreplikálás megkezdése előtt van egy kezdeti üzembe helyezési fázis. A kezdeti vetés fázisa a művelet leghosszabb és legdrágább része. Miután a kezdeti magvetés befejeződött, a rendszer szinkronizálja az adatokat, és csak az azt követő adatmódosítások replikálódnak. A kezdeti magveté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 számítási feladatainak intenzitásától, valamint az elsődleges és másodlagos példányt üzemeltető virtuális hálózatok közötti kapcsolat sebességétől függ, amely leginkább a kapcsolat létesítésének módjától függ. Normál körülmények között, és ha a kapcsolat az ajánlott globális virtuális hálózatok közötti társviszony-létesítéssel jön létre, a vetés sebessége a felügyelt SQL-példány esetében akár óránként 360 GB is lehet. A magvetés párhuzamosan történik a felhasználói adatbázisok kötegében – nem feltétlenül az összes adatbázis esetében egyszerre. Több kötegre lehet szükség, ha a példányon sok adatbázis található.

Ha a két példány közötti kapcsolat sebessége lassabb a szükségesnél, akkor a magvetés ideje valószínűleg észrevehetően csökken. A megadott vetéssebesség, az adatbázisok száma, az adatok teljes mérete és a kapcsolati sebesség alapján megbecsülheti, hogy mennyi ideig tart a kezdeti magvetési fázis az adatreplikálás megkezdése előtt. Egy 100 GB-os adatbázis esetében például a kezdeti magfázis körülbelül 1,2 órát vesz igénybe, ha a hivatkozás óránként 84 GB-ot képes leküldenni, és ha nincs más adatbázis bevetése. Ha a hivatkozás óránként csak 10 GB-ot tud átvinni, akkor egy 100 GB-os adatbázis üzembe helyezése körülbelül 10 órát vehet igénybe. Ha több adatbázist szeretne replikálni, a magvetés párhuzamosan lesz végrehajtva, és lassú kapcsolati sebességgel kombinálva a kezdeti vetés fázisa jelentősen hosszabb időt vehet igénybe, különösen akkor, ha az adatok párhuzamos bevetése minden adatbázisból meghaladja a rendelkezésre álló kapcsolati sávszélességet.

Fontos

Rendkívül alacsony sebességű vagy foglalt kapcsolat esetén, amely miatt a kezdeti vetés fázisa napokig tarthat, a feladatátvételi csoport létrehozása időtúllépést okozhat. A létrehozási folyamat 6 nap után automatikusan megszakad.

Geo-feladatátvétel kezelése geo-másodlagos példányra

A feladatátvételi csoport kezeli az elsődleges felügyelt példány összes adatbázisának geo feladatátvételét. Csoport létrehozásakor a példány minden adatbázisa automatikusan georeplikált lesz a geo-másodlagos példányra. Nem használhat feladatátvételi csoportokat az adatbázisok egy részhalmazának részleges feladatátvételéhez.

Fontos

Ha egy adatbázis az elsődleges felügyelt példányra kerül, az is automatikusan a geo másodlagos felügyelt példányra lesz elvetve.

Az olvasási-írási figyelő (elsődleges MI) használata

Olvasási-írási számítási feladatok esetén használja <fog-name>.zone_id.database.windows.net kiszolgálónévként. Csatlakozás ionok automatikusan az elsődlegesre lesznek irányítva. Ez a név nem változik a feladatátvétel után. A geo feladatátvétel magában foglalja a DNS-rekord frissítését, így az új ü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. Mivel a másodlagos példány megosztja a DNS-zónát az elsődlegessel, az ügyfélalkalmazás ugyanazzal a kiszolgálóoldali SAN-tanúsítvánnyal tud újra csatlakozni hozzá. A meglévő ügyfélkapcsolatokat le kell zárni, majd újra létre kell hozni az új elsődlegeshez való átirányításhoz. Az írásvédett figyelő és az írásvédett figyelő nem érhető el a felügyelt példány nyilvános végpontja segítségével.

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

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. Ha közvetlenül a geo-másodlagoshoz szeretne csatlakozni, használja <fog-name>.secondary.<zone_id>.database.windows.net a kiszolgáló nevét.

A üzletileg kritikus szinten a felügyelt SQL-példány 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 georeplikált másodlagos példányt konfigurált, ezzel a képességgel csatlakozhat egy írásvédett replikához az elsődleges helyen vagy a georeplikált helyen:

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

Az írásvédett figyelő és az írásvédett figyelő nem érhető el nyilvános végponton keresztül felügyelt példány esetén.

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. A csoport geo feladatátvétele csak az Azure SQL-összetevők á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 régióra váltanak, a függő összetevők közötti késés növekedhet. Győződjön meg arról, hogy az alkalmazás összes összetevőjének redundanciája a másodlagos régióban van, és az alkalmazás összetevőinek feladatátvétele az adatbázissal együtt, hogy az alkalmazás teljesítményét ne befolyásolja a régióközi késés.

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.

DNS-frissítés

Az olvasási-írási figyelő DNS-frissítése közvetlenül a feladatátvétel kezdeményezése után történik. Ez a művelet nem okoz adatvesztést. Az adatbázis-szerepkörök váltásának folyamata azonban normál körülmények között akár 5 percet is igénybe vehet. A befejezésig az új elsődleges példány egyes adatbázisai továbbra is írásvédettek lesznek. Ha feladatátvételt kezdeményez a PowerShell használatával, az elsődleges replikaszerepkör váltásának művelete szinkron. Ha az Azure Portalon kezdeményezik, a felhasználói felület a befejezés állapotát jelzi. Ha a REST API-val kezdeményezik, a befejezés nyomon követéséhez használja az Azure Resource Manager szabványos lekérdezési mechanizmusát.

Fontos

A manuális tervezett feladatátvétel használatával helyezze vissza az elsődleges helyet az eredeti helyre, miután a geo-feladatátvételt okozó leállást elhárította.

Költségek megtakarítása licencmentes DR-replikával

Az SQL Server licencköltségeit úgy takaríthatja meg, hogy konfigurálja a másodlagos felügyelt példányt, hogy csak vészhelyreállításhoz (DR) lehessen használni. Ennek beállításához tekintse meg a felügyelt Azure SQL-példány licencmentes készenléti replikáinak konfigurálását.

Mindaddig, amíg a másodlagos példányt nem használják olvasási számítási feladatokhoz, a Microsoft ingyenes számú virtuális magot biztosít az elsődleges példánynak megfelelően. A másodlagos példány által használt számításért és tárolásért továbbra is díjat számítunk fel. A feladatátvételi csoportok csak egy replikát támogatnak – a replikának olvasható replikának kell lennie, vagy csak DR-replikaként kell kijelölnie.

A rendszeradatbázisok objektumaitól függő forgatókönyvek engedélyezése

A rendszeradatbázisok nem replikálódnak a feladatátvételi csoportban a másodlagos példányra. A rendszeradatbázisok objektumaitól függő forgatókönyvekhez mindenképpen hozza létre ugyanazokat az objektumokat a másodlagos példányon, és tartsa őket szinkronizálva az elsődleges példánnyal.

Ha például ugyanazokat a bejelentkezéseket szeretné használni a másodlagos példányon, mindenképpen azonos SID-vel hozza létre őket.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

További információt a Bejelentkezések és ügynökfeladatok replikálása című témakörben talál.

Példánytulajdonságok és adatmegőrzési szabályzatok példányainak szinkronizálása

A feladatátvételi csoportban lévő példányok külön Azure-erőforrások maradnak, és az elsődleges példány konfigurációjában végzett módosítások nem lesznek automatikusan replikálva a másodlagos példányra. Győződjön meg arról, hogy minden releváns módosítást végrehajt az elsődleges és a másodlagos példányon is. Ha például módosítja a biztonsági mentési tár redundanciájú vagy hosszú távú biztonsági mentési adatmegőrzési szabályzatát az elsődleges példányon, győződjön meg arról, hogy a másodlagos példányon is módosítja azt.

Példányok méretezése

Az elsődleges és a másodlagos példányt felskálázhatja vagy leskálázhatja egy másik számítási méretre ugyanazon szolgáltatási szinten belül vagy egy másik szolgáltatási szintre. Ha ugyanabban a szolgáltatási szinten belül skáláz fel, javasoljuk, hogy először skálázza fel a geo-másodlagost, majd skálázza fel az elsődlegeset. Ha ugyanabban a szolgáltatási szinten belül skáláz le, fordítsa vissza a sorrendet: először az elsődleges skálázást, majd a másodlagos skálázást. Ha egy másik szolgáltatási szintre skálázza a példányt, a rendszer kikényszeríti ezt a javaslatot. A rendszer kényszeríti a műveletek sorrendjét a szolgáltatási szint és a virtuális magok, valamint a tárterület skálázása során.

Ezt a sorozatot kifejezetten azért javasoljuk, hogy az alacsonyabb termékváltozatú földrajzilag másodlagos példány ne legyen túlterhelve, és a frissítési vagy alacsonyabb verzióra váltási folyamat során ne kelljen újra feltölteni adatokkal.

Feljegyzés

Van egy ismert probléma , amely befolyásolhatja a hozzárendelt feladatátvételi csoport figyelőjével skálázott példány akadálymentességét.

Kritikus adatok elvesztésének megakadályozása

A nagy kiterjedésű hálózatok nagy késése miatt a georeplikálás aszinkron replikációs mechanizmust használ. Az aszinkron replikáció elkerülhetetlenné teszi az adatvesztés lehetőségét, ha az elsődleges hiba meghiúsul. A kritikus tranzakciók adatvesztéssel szembeni védelme érdekében az alkalmazásfejlesztő közvetlenül a tranzakció véglegesítése után meghívhatja 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. Azonban nem várja meg, hogy a továbbított tranzakciók visszajátsszon (újra) a másodlagoson. sp_wait_for_database_copy_sync hatóköre egy adott georeplikációs hivatkozásra vonatkozik. Ezt az eljárást bármely olyan felhasználó meghívhatja, aki rendelkezik az elsődleges adatbázishoz való kapcsolódási jogosultsággal.

A felhasználó által kezdeményezett, tervezett geo feladatátvétel során az adatvesztés elkerülése érdekében a replikáció automatikusan és ideiglenesen szinkron replikációra változik, majd feladatátvételt hajt végre. A replikáció ezután a geo feladatátvétel befejezése után aszinkron módba tér vissza.

Feljegyzés

sp_wait_for_database_copy_sync megakadályozza az adatvesztést az adott tranzakciók geo feladatátvétele után, de nem garantálja az olvasási hozzáférés teljes szinkronizálását. Az eljáráshívás által sp_wait_for_database_copy_sync okozott késés jelentős lehet, és a hívás időpontjában az elsődlegesen még nem továbbított tranzakciónapló méretétől függ.

Feladatátvételi csoport állapota

A feladatátvételi csoport az adatreplikálás aktuális állapotát leíró állapotát jelenti:

  • Vetés – A feladatátvételi csoport létrehozása után a kezdeti vetés addig tart, amíg az összes felhasználói adatbázis inicializálódik a másodlagos példányon. A feladatátvételi folyamat nem indítható el, amíg a feladatátvételi csoport a bevetési állapotban van, mivel a felhasználói adatbázisok még nem lesznek átmásolva a másodlagos példányra.
  • Szinkronizálás – a feladatátvételi csoport szokásos állapota. Ez azt jelenti, hogy az elsődleges példány adatváltozásai aszinkron módon replikálódnak a másodlagos példányra. Ez az állapot nem garantálja, hogy az adatok minden pillanatban teljes mértékben szinkronizálódnak. A feladatátvételi csoport példányai közötti replikációs folyamat aszinkron jellege miatt előfordulhat, hogy az elsődlegesről továbbra is replikálni kell az adatokat a másodlagosra. Az automatikus és a manuális feladatátvétel is kezdeményezhető, amíg a feladatátvételi csoport szinkronizálási állapotban van.
  • Feladatátvétel folyamatban – ez az állapot azt jelzi, hogy az automatikus vagy manuálisan kezdeményezett feladatátvételi folyamat folyamatban van. A feladatátvételi csoport vagy a további feladatátvételek nem kezdeményezhetők, amíg a feladatátvételi csoport ebben az állapotban van.

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.

Feladatátvételi csoportok tranzakciós replikációval

A tranzakciós replikáció használata feladatátvételi csoportban lévő példányokkal támogatott. Ha azonban konfigurálja a replikációt, mielőtt hozzáadja a felügyelt SQL-példányt egy feladatátvevő csoporthoz, a replikáció szünetel, amikor elkezdi létrehozni a feladatátvevő csoportot, és a replikációs figyelő állapotot Replicated transactions are waiting for the next log backup or for mirroring partner to catch upjelenít meg. A replikáció a feladatátvételi csoport sikeres létrehozása után folytatódik.

Ha egy közzétevő vagy forgalmazó felügyelt SQL-példány feladatátvételi csoportban van, a felügyelt SQL-példány rendszergazdájának törölnie kell a régi elsődleges példány összes kiadványát, és újra kell konfigurálnia őket az új elsődlegesen a feladatátvétel után. Tekintse át a tranzakciós replikációs útmutatót az ebben a forgatókönyvben szükséges tevékenységek lépéséhez.

Engedélyek, korlátozások és előfeltételek

A feladatátvételi csoport konfigurálásának megkezdése előtt tekintse át a feladatátvételi csoport konfigurálásának útmutatóját az engedélyek, korlátozások és előfeltételek 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 tekintse át a feladatátvételi csoport konfigurálását.

Kapcsolódó tartalom