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

Feladatátvételi csoportok áttekintése & legjobb gyakorlatok – Felügyelt Azure SQL-példány

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

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 az Azure SQL Felügyelt 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 georeplikált adatbázisok nagy léptékű üzembe helyezésének és felügyeletének egyszerűsítésére feladatátvételi csoportok szolgálnak.

További információ: Felügyelt Azure SQL-példány magas rendelkezésre állása. A geo-failover RPO-val és RTO-val kapcsolatban tekintse meg az üzletmenet-folytonosság áttekintését.

Végpont átirányítása

A feladatátvételi csoportok írható-olvasható és írásvédett figyelő végpontokat kínálnak, amelyek földrajzi feladatátvétel során változatlanok maradnak. Geo-túlterhelés esetén nem kell módosítania az alkalmazás kapcsolati karakterláncát, mert a kapcsolatok automatikusan a jelenlegi elsődleges kiszolgálóra irányítják. A geo feladatátvétel a csoport összes másodlagos adatbázisát az elsődleges szerepkörre váltja. A geo-átállás befejezése után a DNS-rekord automatikusan frissül, hogy a végpontokat az új régióba irányítsa át.

Írásvédett munkaterhelések áthelyezése

Az elsődleges adatbázisok forgalmának csökkentése érdekében használhatja a feladatátvételi csoport másodlagos adatbázisait is a csak olvasható munkaterhelések áthelyezéséhez. Az olvasási védettséggel rendelkező figyelő használatával irányíthatja az ilyen típusú 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.

Átállási szabályzat

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

  • Ügyfél által kezelt (ajánlott) – Az ügyfelek végrehajthatnak egy feladatátvételt egy csoporton, ha váratlan kimaradást észlelnek, amely érinti a feladatátvételi csoport egy vagy több adatbázisát. Parancssori eszközök, például a PowerShell, az Azure CLI vagy a Rest API használatakor az ügyfél által felügyelt feladatátvételi szabályzat értéke manual.
  • Microsoft által felügyelt – Az elsődleges régiót érintő széles körű leállá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 Microsoft-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:

Átállási szabályzat Átállási 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 átáll a másodlagos rendszerre. 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ási nem elegendő a kimaradás enyhítéséhez, és előfordulhat, hogy a feladatátvételi csoport adatbázisai nem lesznek elérhetők olyan időtartamra, amely nem elfogadható az adatbázisokat használó alkalmazások szolgáltatásiszint-szerződése (SLA) számára. 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 ezen esetek bármelyikében kezdeményezhet kényszerített failovert.

A feladatátvételi szabályzat ügyfél által felügyeltre való 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 régió szintjén előforduló kimaradást természeti katasztrófák, konfigurációs változások, szoftverhibák vagy hardverkomponens-meghibásodások okozhatják, és a régió számos adatbázisát is érinthetik.
  • 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.

Fontos

Használja az ügyfél által felügyelt feladatátvételi szabályzatot a vészhelyreállítási terv teszteléséhez és implementálásához. Ne a Microsoft által felügyelt feladatátvételre támaszkodjon, amelyet a Microsoft csak akkor hajthat végre, ha szélsőséges körülmények merülnek fel. A rendszer a Microsoft által felügyelt feladatátvételt kezdeményezi azon régió összes feladatátvételi csoportjához, amelyek feladatátvételi szabályzata a Microsoft által felügyeltre van állítva. Egyéni hibatűrő csoport esetén nem kezdeményezhető. Ha a feladatátvételi csoport szelektív feladatátvételére van szüksége, használja az ügyfél által felügyelt feladatátvételi szabályzatot.

A feladatátvételi szabályzatot csak akkor állítsa csak 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ételen megy keresztül, függetlenül a zónaredundanciára vonatkozó 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 és bármely georeplikációs kapcsolat 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-kkal vagy virtuális magokkal) rendelkezik. Ha az összes adatbázis 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 Feladatátvételi Azure SQL-feladatátvételi csoport műveletnévhez tartozó bejegyzést hozzáadják az Azure Monitor tevékenységnaplóhoz. A bejegyzés tartalmazza a feladatátvételi csoport nevét Erőforrásalatt, és által kezdeményezett esemény egyetlen kötőjelet (-) jelenít meg, amely 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ójának 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ányban.

  • 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 hosztoló 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 elérhetetlenségét okozhatja, beleértve a memóriában lévő OLTP-objektumokat is a földrajzi másodlagos rendszeren. Ez viszont azt is eredményezheti, hogy az átállás sikertelen lesz. 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 méretben nagy adatműveletek lehetnek, és eltarthat egy ideig, amíg befejeződnek.

  • Átkapcsolás (adatvesztés nélkül)

    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. Átkapcsolás 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égzése éles üzemben, 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 után (visszaállás), adja vissza a munkaterhelést az elsődleges régióba.

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

    A kényszerített átkapcsolás 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ődleges kiszolgálóról. Ez a művelet potenciális adatvesztést okozhat. A kényszerített átváltást helyreállítási módszerként alkalmazzák szolgáltatáskiesés esetén, amikor az elsődleges rendszer nem érhető el. A kimaradás mérséklésekor a régi elsődleges automatikusan újracsatlakozik, és új másodlagossá válik. Automatizált átkapcsolást hajthat végre a visszakapcsoláshoz, visszaadva a replikákat az eredeti elsődleges és másodlagos szerepköreikbe.

  • 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. A GracePeriodWithDataLossHourskonfigurálásával szabá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. Ehhez a példányhoz egy többdomaines (SAN) tanúsítvány van biztosítva, amely hitelesíti az ügyfélkapcsolatokat az ugyanabban a DNS zónában található bármely példánnyal. 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 írás- és olvasási figyelő

    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 írás-olvasási munkaterhelés transzparensen újracsatlakozzon az elsődlegeshez, amikor az elsődleges a feladatátvételt követően 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 <fog-name>.<zone_id>.database.windows.net lesz.

  • 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-munka terhelés transzparens módon csatlakozzon a másodlagos adatbázishoz, amikor a másodlagos adatbázis megváltozik feladatátvétel után. 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 <fog-name>.secondary.<zone_id>.database.windows.net lesz. Alapértelmezés szerint, a csak olvasható figyelő átkapcsolása le van tiltva, mivel ez biztosítja, hogy az elsődleges teljesítményére ne legyen hatással, ha a másodlagos kapcsolat offline. 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 munkamenetekhez, és az elsődlegest szeretné használni mind írásvédett, mind írás/olvasási forgalomhoz, azzal a kockázattal, hogy ez a teljesítményromlását idézheti elő az elsődleges kiszolgálónál, akkor a AllowReadOnlyFailoverToPrimary tulajdonság konfigurálásával engedélyezheti a feladatátvételt az írásvédett figyelő számára. Ebben az esetben a rendszer automatikusan átirányítja a csak olvasható forgalmat az elsődleges szerverre, ha a másodlagos nem érhető el.

    Jegyzet

    A AllowReadOnlyFailoverToPrimary tulajdonság csak akkor lép érvénybe, 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 Igaz, az új elsődleges mind az írható, mind a csak olvasható munkameneteket 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. Az olyan rendszeradatbázisok, mint a master és a msdb nem lesznek replikálva.

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:

Azure SQL felügyelt példány feladatátvételi csoportjának diagramja.

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ó az ügyfélkapcsolatok hitelesítésére a feladatátvételi csoport bármelyik két példányában. 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 PowerShellt vagy REST API-t használ, az opcionális paraméter neve DNSZonePartner. Az Azure Portálon az ennek megfelelő opcionális mező neve Felügyelt Elsődleges 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 Felügyelt Azure SQL-példány feladatátvételi csoportjának konfigurálásacímű témakörben talál.

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

Mindkét felügyelt példányt helyezze üzembe a párosított régiókban a teljesítmény javítása érdekében. Az SQL Managed Instance feladatátvételi csoportjai a párosított régiókban jobb teljesítményt biztosítanak 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 az Azure SQL Managed Instance egy feladatátvételi csoportrésze, és a csoport példányai nem Azure-párosított régiókban találhatók, válasszon különböző karbantartási időszakokat az elsődleges és a másodlagos adatbázis számára. Válasszon például egy hétköznap 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 forgalom engedélyezése és optimalizálása

Az elsődleges és másodlagos példányt üzemeltető virtuális hálózati alhálózatok közötti kapcsolatot 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éle mód közül választhat a példányok közötti kapcsolat biztosítására.

Globális virtuális hálózati társviszony (VNet-társviszony) az ajánlott módszer két példány közötti kapcsolat létesítésére egy feladatátvételi csoportban. Alacsony késésű, nagy sávszélességű privát kapcsolatot biztosít a társviszonyban lévő virtuális hálózatok között a Microsoft gerincinfrastruktúra 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. A kezdeti vetés befejezése után az adatok szinkronizálódnak, és csak az azt követő adatmódosítások lesznek replikálva. 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

A kezdeti vetés fázisa rendkívül alacsony sebességű vagy forgalmas kapcsolatok esetén napokig tarthat. Ebben az esetben a feladatátvételi csoport létrehozása időtúllépést okozhat. A feladatátvételi csoport létrehozása 6 nap után automatikusan megszűnik.

Geo-failover kezelése egy 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 az egyes adatbázisok a példányon belül automatikusan földrajzilag replikáltak lesznek a 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 törlésre kerül az elsődleges felügyelt példányon, az automatikusan törlődik a geo-másodlagos felügyelt példányon is.

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

Olvasási-írási számítási feladatokhoz használja a <fog-name>.zone_id.database.windows.net kiszolgálónévként. A rendszer automatikusan átirányítja a kapcsolatokat az elsődlegesre. Ez a név nem változik a feladatátvétel után. A geográfiai 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 irányítva az új elsődleges szerverre. 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 olvasás-írás figyelő és az írásvédett figyelő nem érhető el a felügyelt példány nyilvános végpontján keresztül.

Í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 a <fog-name>.secondary.<zone_id>.database.windows.net-t kiszolgáló névként.

Az Üzletileg kritikus szinten a felügyelt SQL-példány támogatja a írásvédett replikák használatát a csak olvasási lekérdezési feladatok tehermentesítéséhez, a kapcsolati sztring ApplicationIntent=ReadOnly paraméterének 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 ApplicationIntent=ReadOnly és <fog-name>.<zone_id>.database.windows.net.
  • 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ás-olvasás figyelő és az olvasásvédett figyelő nem érhető el a felügyelt példány nyilvános végpontján keresztül.

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

Egy tipikus Azure-alkalmazás több Azure-szolgáltatást használ, és több összetevőből áll. A csoport geográfiai átállása csak az Azure SQL-összetevők állapota alapján indul el. Előfordulhat, hogy az elsődleges régió többi Azure-szolgáltatását nem érinti a kimaradás, és az összetevők 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 biztosított a másodlagos régióban, és szükség esetén az alkalmazás összetevőit és az adatbázist együtt helyezze át, hogy az alkalmazás teljesítményét ne befolyásolja a magasabb régióközi késlelteté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ókat nem replikálták a geo-másodlagosra, és adatvesztést okozhat, 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 csak olvashatók lesznek. Ha a PowerShell használatával kezdeményezi az átállást, az elsődleges másolat szerepkörének váltása szinkron művelet. 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 rendszert az eredeti helyére, 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 Felügyelt Azure SQL-példány licencmentes készenléti replikáinak konfigurálása.

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 failover csoportok csak egyetlen replikát támogatnak – a replikának vagy olvashatónak kell lennie, vagy DR-replikaként kell lennie megjelölve.

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

A rendszeradatbázisok nincsenek replikálva a feladatátvételi csoport másodlagos példányára. A rendszeradatbázisok objektumaitól függő forgatókönyvek engedélyezéséhez győződjön meg arról, hogy ugyanazokat az objektumokat hozza létre a másodlagos példányon, és szinkronizálja őket az elsődleges példánysal.

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ó: Bejelentkezések és ügynökfeladatok replikálása.

Példánytulajdonságok és adatmegőrzési szabályzat 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 az elsődleges és másodlagos példányon is végrehajtja az összes releváns módosítást. 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 skálázása

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 a példányt egy másik szolgáltatási szintre skálázza, ez a javaslat érvényesítésre kerül. 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.

A sorozat kifejezetten azért ajánlott, hogy elkerülje azt a problémát, amely miatt az alacsonyabb termékváltozatú geo-másodlagos egység túlterhelődik, és a frissítési vagy leminősítési folyamat során újra kell inicializálni.

Fontos

  • A feladatátvételi csoporton belüli példányok esetében nem támogatott a szolgáltatásszint megváltoztatása a következő generációs általános célú szintre, vagy arról történő visszaváltás. A replika módosítása előtt először törölnie kell a feladatátvételi csoportot, majd újra létre kell hoznia a feladatátvételi csoportot a módosítás érvénybe lépése után.
  • ismert probléma, amely hatással lehet a hozzárendelt feladatátvételi csoport figyelőjével skálázásra kerülő példány hozzáférhetőségére.

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 sp_wait_for_database_copy_sync hívása blokkolja a hívó szálat, 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. Azonban nem várja meg, hogy a továbbított tranzakciók újra visszajátszódjanak a másodlagos rendszeren. 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 geográfiai 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 végrehajtja a feladatátvételt. A replikáció ezután a földrajzi feladatátvétel befejezése után aszinkron módba tér vissza.

Jegyzet

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

Átváltási csoport állapota

Az átváltási csoport jelentése az aktuális állapotot, az adatreplikálás állapotát bemutatja.

  • Kezdeti kiosztás – A pótcsoport létrehozása után történik a kezdeti kiosztás, 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 vetési állapotban van, mivel a felhasználói adatbázisok még nincsenek á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 adatváltozások még replikálásra várnak 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. Az átállási csoport módosítása vagy további átállások nem kezdeményezhetők, amíg az átállási csoport ebben az állapotban van.

Visszaállítás

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 rendszerre való visszaállást manuálisan kell kezdeményezni.

Funkciók közötti együttműködés

Mentések

A teljes biztonsági mentés a következő esetekben történik:

  • A kezdeti vetés megkezdése előtt, amikor feladatátvételi csoportot hoz létre.
  • Átállás után.

A teljes biztonsági mentés olyan adatművelet mérete, amelyet nem lehet kihagyni vagy elhalasztani, és egy kis időt is igénybe vehet. A befejezéshez szükséges idő az adatok méretétől, az adatbázisok számától és az elsődleges adatbázisok számítási feladatainak intenzitásától függ. A teljes biztonsági mentés észrevehetően késleltetheti a kezdeti telepítést, és késleltetheti vagy megakadályozhatja a feladatátvételi műveletet egy új példányon röviddel a feladatátvétel után.

Napló-visszajátszó Szolgáltatás

Az Log Replay Service (LRS) segítségével Azure SQL Managed Instance-ba migrált adatbázisok nem vehetők fel átvételi csoportba, amíg az átállási lépést végre nem hajtják. Az LRS-lel migrált adatbázis visszaállítási állapotban van az átállásig, és a visszaállítási állapotban lévő adatbázisok nem vehetők fel feladatátvételi csoportokba. A feladatátvételi csoport létrehozása visszaállítási állapotú adatbázissal késlelteti a feladatátvételi csoport létrehozását, amíg az adatbázis-visszaállítás befejeződik.

Tranzakciós replikáció

A feladatátvételi csoportban lévő példányokkal történő tranzakciós replikáció használata támogatott. Ha azonban a felügyelt SQL-példány feladatátvételi csoportba való hozzáadása előtt konfigurálja a replikációt, a replikáció szünetel a feladatátvételi csoport létrehozásakor, a replikációs figyelő pedig Replicated transactions are waiting for the next log backup or for mirroring partner to catch upállapotot jelení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 a tevékenységek lépéseiért, amelyek szükségesek ebben a forgatókönyvben.

Engedélyek és korlátozások

A feladatátvételi csoport konfigurálása előtt tekintse át a engedélyek és korlátozások listáját,.

Feladatátvételi csoportok programozott módon történő 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 feladatátvételi csoport konfigurálását.

Vészhelyreállítási gyakorlatok

A DR gyakorlat végrehajtásának ajánlott módja a manuális tervezett átállás, az alábbi oktatóanyag szerint: Átállási teszt.

A kényszerített átállást használó gyakorlat végrehajtása nem ajánlott, mivel ez a művelet nem biztosít védőkorlátokat az adatvesztés ellen. Ennek ellenére az adatvesztés nélküli kényszerített feladatátvételt úgy lehet elérni, hogy az alábbi feltételek teljesülnek a kényszerített feladatátvétel megkezdése előtt:

  • A számítási feladat le van állítva az elsődleges felügyelt példányon.
  • Minden hosszú ideig futó tranzakció befejeződött.
  • Az elsődleges felügyelt példányhoz kapcsolódó összes ügyfélkapcsolat megszakadt.
  • Feladatátvételi csoport állapota 'Szinkronizálás'.

Győződjön meg arról, hogy a két felügyelt példány szerepköröket váltott, és hogy a feladatátvételi csoport állapota a "Feladatátvétel folyamatban" állapotról "Szinkronizálás" állapotra váltott, mielőtt opcionálisan kapcsolatot létesítene az új elsődleges felügyelt példánysal, és megkezdené az írási-olvasási számítási feladatot.

Ha adatvesztés nélküli visszaállást szeretne végrehajtani az eredeti felügyelt példányszerepekre, erősen ajánlott a manuális tervezett feladatátvételt használni kényszerített feladatátvétel helyett. Kényszerített visszaállás esetén:

  • Kövesse ugyanazokat a lépéseket, mint az adatvesztés nélküli feladatátvétel esetében.
  • Hosszabb visszaállási végrehajtási idő várható, ha a kényszerített visszaállás végrehajtása röviddel azután történik, hogy a kezdeti kényszerített átállás befejeződött, mivel várni kell a korábbi elsődleges kezelt példányon folyamatban lévő automatikus biztonsági mentési műveletek befejezésére.
  • A felügyelt példányon az elsődlegesről a másodlagos szerepkörre áttűnő, fennálló automatikus biztonsági mentési műveletek hatással lesznek az adatbázis rendelkezésre állására ezen a példányon.
  • A feladatátvételi csoport állapotával állapítsa meg, hogy mindkét példány sikeresen módosította-e a szerepköreit, és készen áll-e az ügyfélkapcsolatok elfogadására.

Kapcsolódó tartalom