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

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 feladatátvételi csoportok funkcióval kezelheti egy felügyelt SQL-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.

Első lépésként tekintse át a felügyelt Azure SQL-példány feladatátvételi csoportjának konfigurálását ismertető cikket.

Áttekintés

A feladatátvételi csoportok funkció lehetővé teszi a felhasználói adatbázisok replikációjának és feladatátvételének kezelését egy felügyelt SQL-példányról egy másik Felügyelt SQL-példányra egy másik Azure-régióban. 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 írás- és olvasási, valamint írásvédett figyelővégpontokat biztosítanak, amelyek a 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.
  • A Microsoft felügyelte – Az 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:

Á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 csoportok A feladatátvételi csoport 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 Egy régió 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.
A Microsoft által felügyelt feladatátvétel csak szélsőséges körülmények között hajthat meg végre. Erősen ajánlott az ügyfél által felügyelt feladatátvételi szabályzat .		 Igen

Ügyfél által kezelt

Ritkán a beépített rendelkezésre állás vagy a 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 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:

  • A régiószintű kimaradást természeti katasztrófaesemény, konfigurációváltozások, szoftverhibák vagy hardverösszetevő-hibák, valamint a régió számos adatbázisa érinti.
  • 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

A vészhelyreállítási terv teszteléséhez és implementálásához használja az ügyfél által felügyelt feladatátvételi szabályzatot. 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 kezdeményez egy Microsoft által felügyelt feladatátvételt a régió összes feladatátvételi csoportjához, amelyek feladatátvételi szabályzata a Microsoft felügyelete alá van állítva. Az egyes feladatátvételi csoportok esetében nem indítható el. Ha szelektíven kell feladatátvételt végrehajtania a feladatátvételi csoporton, 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ételeket a türelmi időszak lejárta után egy ideig lehet aktiválni, mivel a kényszerített feladatátvétel tényleges ideje jelentősen eltérhet.
  • 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 elsődleges és másodlagos replikái azonos szolgáltatási szinttel, számítási szinttel és számítási mérettel rendelkeznek.

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 SQL-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, ha az elsődleges felügyelt SQL-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

    Az elsődleges adatbázisokat az átkapcsolási csoportban üzemeltető SQL-felügyelt példány.

  • másodlagos

    A failover csoportban lévő felügyelt SQL példány, amely a másodlagos adatbázisokat üzemelteti. 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 SQL-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 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-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 a következőképpen alakul.<fog-name>.secondary.<zone_id>.database.windows.net 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 értéke Igaz, az új elsődleges példány az írási és csak olvasható 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. Az elsődleges példányon lévő összes felhasználói adatbázis replikálva lesz a másodlagos példányra. A rendszeradatbázisok, mint például master és msdb, nincsenek replikálva.

Az alábbi ábra egy georedundáns felhőalkalmazás tipikus konfigurációját mutatja be felügyelt SQL-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 kapcsolat 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. Ehhez megadhat egy opcionális paramétert a példány létrehozásakor. 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 SQL-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 SQL-példány üzembe helyezése párosított régiókban teljesítménybeli okokból. 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éleképpen is biztosíthatja a kapcsolatot a példányok között:

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ársított 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 SQL-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 többnyire 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 felhasználói adatbázisok kötegében, de 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 használatával 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 rendszer párhuzamosan hajtja végre a magvetést. Lassú kapcsolati sebességgel kombinálva a kezdeti vetés fázisa jelentősen tovább tarthat, különösen akkor, ha az adatok párhuzamos bevetése az összes adatbázisból meghaladja a rendelkezésre álló 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 hat 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 SQL-példányon lévő összes adatbázis geo-feladatátvételét. Egy 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 SQL-példányra kerül, az is automatikusan a felügyelt geo-másodlagos SQL-példányra kerül.

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 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ás-olvasó figyelő és az írásvédett figyelő nem érhető el a felügyelt SQL-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 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 olvasási-írási figyelő és a csak olvasható figyelő nem érhető el a felügyelt SQL-példány nyilvános végpontja használatával.

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 a kimaradás nem érinti az elsődleges régió többi Azure-szolgáltatását, é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ője redundáns a másodlagos régióban, és mind az alkalmazás összetevői, mind az adatbázis egyszerre kerülnek át a másodlagos régióba, így a nagyobb régióközi késleltetés nem befolyásolja az alkalmazás teljesítményét.

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 georedundánsra, és a kényszerített feladatátvétel végrehajtása adatvesztést okozhat.

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 öt 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 SQL-példányt, hogy csak vészhelyreállításhoz (DR) használhassa. 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 feladatátvételi csoportok csak egy replikát támogatnak, és a replikának olvasható replikának kell lennie, vagy csak DR-replikaként kell kijelölni.

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 mindenképpen hozza létre ugyanazokat az objektumokat a másodlagos példányon. 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 hozza létre őket azonos SID értékkel.

-- 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 csoport példányai elkülönülnek az Azure-erőforrásoktól, és az elsődleges példány konfigurációjában végrehajtott módosítások nem replikálódnak automatikusan a másodlagos példányra. Győződjön meg arról, hogy az elsődleges és a 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ával vagy az elsődleges példány hosszú távú biztonsági mentési megőrzési szabályzatával kapcsolatos szabályokat, mindenképpen módosítsa azt a másodlagos példányon is.

Példányok skálázása

Az elsődleges és a másodlagos példány konfigurációjának azonosnak kell lennie. Ez magában foglalja a számítási méretet, a tárterületet és a szolgáltatási szintet. Ha módosítania kell a feladatátvételi csoport konfigurációját, ezt úgy teheti meg, hogy az egyes példányokat ennek megfelelően skálázhatja ugyanarra a konfigurációra. További információért tekintse át a feladatátvételi csoport skálázási példányait.

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. Az adatok védelmének megismeréséhez tekintse át az adatvesztés megelőzését ismertető cikket.

Átváltási csoport állapota

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

  • Vetés: A kezdeti vetés a feladatátvételi csoport létrehozása után történik, egészen addig, amíg az összes felhasználói adatbázis inicializálódik a másodlagos példányon. A feladatátvétel nem indítható el, amíg a feladatátvételi csoport Seeding á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 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étel folyamatban van. A feladatátvételi csoport vagy további átállások nem kezdeményezhetők, amíg a feladatátvételi 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, a rendszer a megadott türelmi időszaknak megfelelően elindítja a geo-másodlagos kiszolgálóra történő kényszerített feladatátvételt egy vészforgatókönyvben. 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.

Vegye figyelembe a következőket:

  • A feladatátvételi csoport másodlagos példányán üzemeltetett adatbázisokról csak akkor készül biztonsági mentés, ha a példány az elsődleges példánnyá válik a feladatátvétel után, vagy amíg a feladatátvételi csoport meg nem szűnik.
  • Miután egy adatbázis a feladatátvétel után az elsődleges szerepkörre vált, vagy önállóvá válik egy feladatátvételi csoport elvetése után, a rendszer automatikusan elindítja a teljes adatbázis biztonsági mentését az időponthoz kötött visszaállítások megkönnyítése érdekében.
  • Az adatbázis nem állítható vissza egy példányból olyan időpontra, amikor a példány másodlagos replika volt egy feladatátvételi csoportban. Az adott időpontra való visszaállításhoz vissza kell állítania az adatbázist az adott időpontban elsődleges példányból.
  • Ha egy elvetett feladatátvételi csoportot ugyanazon a felügyelt SQL-példánypáron szeretne újból létrehozni, a feladatátvételi csoport elvetése után minden felhasználói adatbázist el kell távolítani a kívánt másodlagosról. Az adatbázis csak a függőben lévő biztonsági mentési műveletek befejezése után lesz teljesen eltávolítva, beleértve a teljes biztonsági mentést is, ha nem készült el (ami adatméret-művelet). Hagyjon időt a másodlagos példány törlésére, miután elvetett egy nagyon nagy adatbázist tartalmazó feladatátvételi csoportot, mivel minden adatbázisnak folyamatban lehet egy függőben lévő teljes biztonsági mentési művelete.

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 jelentősen 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 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 a feladatátvételi csoport létrehozásakor. A replikációs figyelő az állapotot Replicated transactions are waiting for the next log backup or for mirroring partner to catch upjeleníti 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 a Feladatátvételi csoport konfigurálása című témakört.

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.

Kényszerített feladatátvétel alkalmazásával történő 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áll az elsődleges felügyelt SQL-példányon.
  • Minden hosszú ideig futó tranzakció befejeződött.
  • Az elsődleges felügyelt SQL-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 SQL-példány szerepkört váltott. Azt is, 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 SQL-példányhoz, és megkezdené az olvasási-írási számítási feladatot.

Ha adatvesztés nélküli feladat-visszavételt szeretne végrehajtani az eredeti felügyelt SQL-példányszerepkörökre, erősen ajánlott manuális, tervezett feladatátvételt használni a 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 feladat-visszavételi végrehajtási idő várható, ha a kényszerített feladat-visszavételt röviddel a kezdeti kényszerített feladatátvétel befejezése után hajtják végre, mivel várnia kell a korábbi elsődleges sql-alapú felügyelt példányon végrehajtott, folyamatban lévő automatikus biztonsági mentési műveletek befejezésére.
  • Az elsődleges szerepkörből a másodlagosba áthelyezés közben végzett automatikus biztonsági mentések hatással lehetnek 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

  • Last updated on