Az átállási csoportok áttekintése és ajánlott eljárások (Azure SQL Database)

A következőkre vonatkozik:Azure SQL Database

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

A funkció használatának megkezdéséhez tekintse át a Feladatátvételi csoport konfigurálása az Azure SQL Database-t.

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

Áttekintés

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

A geo-failover RPO és RTO esetén lásd az üzletmenet-folytonosság áttekintését további információért.

Végpont átirányítása

A feladatátvételi csoportok biztosítanak írás-olvasás, illetve írásvédett hallgató végpontokat, 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ét, 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-failover befejezése után a DNS-rekord automatikusan frissül, hogy az új régióba irányítsa a végpontokat.

Csak olvasható munkaterhelések átirányítása

Az elsődleges adatbázisok forgalmának csökkentése érdekében a feladatátvételi csoport másodlagos adatbázisait is használhatja a csak olvasható munkaterhelések elosztására. 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.

Átállási stratégia

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 váratlan leállást észlelnek, amely hatással van a feladatátvételi csoport egy vagy több adatbázisára. Amikor parancssori eszközöket, mint például a PowerShell, az Azure CLI vagy a Rest API használunk, az ügyfél által kezelt átállási szabályzatnak az é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:

Ü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 üzletfolytonosság visszaállításához bármelyik esetben kezdeményezhet kényszerített átváltást.

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 kezeli

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:

• Adatközpontok, rendelkezésre állási zónák vagy régiók szintjén kiesést okozhat természeti katasztrófa, konfigurációs változások, szoftverhibák, vagy hardver hibák, és számos adatbázis a régióban érintett.
• 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ályzat beállítását 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 átvált, 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 é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 feladatcsoport művelet bejegyzése hozzáadódik 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 az Azure-egyetlen logikai kiszolgálója által felügyelt adatbázisok nevesített csoportja, amelyek egységként át tudnak adni egy másik Azure-régióba, ha az elsődleges régióban kimaradás miatt az összes vagy néhány elsődleges adatbázis elérhetetlenné válik.

  Fontos

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

• kiszolgálók

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

• elsődleges

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

• másodlagos

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

• feladatátvétel (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. Átállás csak akkor lehetséges, ha az elsődleges rendszer elérhető. Az átállás 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 után helyezze vissza a számítási feladatot az elsődleges régióba (feladat-visszaállítás)

• Kényszerített failover (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 eljárásként használatos a kimaradások során, amikor a primáris szerver nem érhető el. A kimaradás mérséklésekor a régi elsődleges automatikusan újracsatlakozik, és új másodlagossá válik. Átállás hajtható végre visszaállás végrehajtására, hogy a replikák eredeti elsődleges és másodlagos szerepköreikhez térjenek vissza.

• türelmi időszak adatvesztéssel

  Mivel az adatok aszinkron módon replikálódnak a másodlagos rendszerre, a Microsoft által felügyelt feladatátvételi szabályokkal rendelkező csoportok erőltetett 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.

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

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

  Fontos

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

• Rugalmas készletben lévő adatbázisok hozzáadása a feladatátvételi csoporthoz

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

• feladatátvételi csoport olvasás-írás figyelője

  Egy DNS CNAME rekord, amely az aktuális elsődlegesre mutat. Amikor a feladatátvételi csoport létrejön, automatikusan generálódik, és lehetővé teszi az írás-olvasási terhelés számára, hogy átláthatóan újra csatlakozzon az eredeti elsődleges szerverhez, amikor az elsődleges megváltozik a feladatátvétel után. Amikor a feladatátvételi csoportot egy kiszolgálón hozza létre, a figyelő URL-címhez tartozó DNS CNAME rekord <fog-name>.database.windows.net módjára alakul ki. A feladatátvétel után a DNS-rekord automatikusan frissül, hogy átirányítsa a hallgatót az új elsődleges szerverre.

• Átkapcsolási csoport csak olvasható kapcsolódási pontja

  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-terhelés átlátható módon csatlakozzon a másodlagos kiszolgálóhoz, amikor az változik a feladatátvétel után. Amikor a feladatátvételi csoportot egy kiszolgálón hozza létre, a figyelő URL-címének DNS CNAME rekordja <fog-name>.secondary.database.windows.netlesz. Alapértelmezés szerint az írásvédett figyelő feladatátvételi funkciója le van tiltva, mivel biztosítja, hogy az elsődleges teljesítménye nincs hatással, amikor a másodlagos offline állapotban van. Ez azonban azt is jelenti, hogy az írásvédett munkamenetek nem fognak tudni csatlakozni, amíg a másodlagos szerver helyre nem áll. Ha nem tolerálja a kiesést az írásvédett munkamenetek esetében, és az elsődlegest mind írásvédett, mind írás-olvasható forgalomhoz használhatja az elsődleges teljesítmény csökkenésének potenciális rovására, akkor engedélyezheti a feladatátvételt az írásvédett figyelő számára a AllowReadOnlyFailoverToPrimary tulajdonság konfigurálásával. Ebben az esetben a rendszer automatikusan átirányítja a csak olvasható forgalmat a primer eszközre, ha a szekunder 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 True, az új elsődleges kiszolgáló mind az írási, mind az írásvédett munkameneteket kezelni fogja.

• Több feladatátvételi csoport

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

Feladatátállási csoport architektúrája

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

A szolgáltatás üzletmenet-folytonosságot szem előtt tartva történő tervezésekor kövesse az ebben a cikkben ismertetett általános irányelveket és ajánlott eljárásokat. Feladatátvételi csoport konfigurálásakor győződjön meg arról, hogy a másodlagos rendszeren a hitelesítés és a hálózati hozzáférés megfelelően működik a geo-feladatátvétel után, amikor a geo-másodlagos az új elsődlegessé válik. További részletekért lásd Az Azure SQL Database biztonságának konfigurálása és kezelése földrajzi helyreállításhoz vagy átálláshoz. További információ: Globálisan elérhető szolgáltatások tervezése az Azure SQL Database használatával és Geo-helyreállítás az Azure SQL Databaseesetén.

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

Az elsődleges és a másodlagos kiszolgáló közötti feladatátvételi csoport létesítésére használja a párosított régiókat, mivel a párosított régiókban lévő feladatátvételi csoportok jobb teljesítményt biztosítanak a nem párosított régiókhoz képest.

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

Ha georeplikációs vagy feladatátvételi csoportokkal rendelkezik olyan adatbázisokhoz, amelyek nincsenek összhangban az Azure-régiópárosítással, használjon különböző karbantartási időablak-ütemezéseket az elsődleges és másodlagos adatbázisaihoz. Kiválaszthatja például hétköznap karbantartási időszakát a másodlagos adatbázishoz, és hétvégi karbantartási időszakot az elsődleges adatbázishoz.

Kezdeti vetés

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

A feladatátvételi csoportban lévő adatbázisok száma

A feladatátvételi csoportban lévő adatbázisok száma közvetlenül befolyásolja a feladatátvételi és a kényszerített feladatátvételi műveletek időtartamát.

• Feladatátvétel (más néven tervezett feladatátvétel) során biztosítjuk, hogy az összes elsődleges adatbázis teljes mértékben szinkronizálva legyen a másodlagos adatbázissal, és kész állapotba kerüljön. A vezérlősík túlterhelésének elkerülése érdekében az adatbázisok kötegekben vannak előkészítve. Ezért erősen ajánlott korlátozni a feladatátvételi csoportban lévő adatbázisok számát.
• Kényszerített feladatátvétel esetén az előkészítési fázis gyorsul, mivel az adatszinkronizálás nem indul el. A gyorsabb és kiszámítható feladatátvételi időtartamok elérése érdekében hasznos lehet, ha a feladatátvételi csoportban lévő adatbázisok számát kisebb számra tartjuk.

Több átváltási csoport használata több adatbázis átváltásához

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

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

Olvasási-írási számítási feladatokhoz használja a <fog-name>.database.windows.net kiszolgálónévként a kapcsolati sztringben. A rendszer automatikusan átirányítja a kapcsolatokat az elsődlegesre. Ez a név nem változik a feladatátvétel után. Vegye figyelembe, hogy a feladatátvétel magában foglalja a DNS-rekord frissítését, így az ügyfélkapcsolatok csak az ügyfél DNS-gyorsítótárának frissítése után lesznek átirányítva az új elsődlegesre. Az elsődleges és másodlagos figyelő DNS-rekordjának élettartama (TTL) 30 másodperc.

Használd az írásvédett figyelőt (másodlagos)

Ha logikailag izolált írásvédett számítási feladatokkal rendelkezik, amelyek tolerálják az adatkéséseket, futtathatja őket a földrajzi másodlagos helyen. Írásvédett munkamenetek esetén a <fog-name>.secondary.database.windows.net sztringet használja szervernévként a kapcsolati sztringben. A rendszer automatikusan átirányítja a kapcsolatokat a földrajzi másodlagos helyre. Javasoljuk azt is, hogy a kapcsolati sztringben jelezze az olvasási szándékot a ApplicationIntent=ReadOnly használatával.

Prémium, Üzletileg Kritikus és Hyperscale szolgáltatási szinteken az SQL Database támogatja az írásvédett replikák használatát az írásvédett lekérdezési munkaterhelések kiszervezéséhez a kapcsolati sztring ApplicationIntent=ReadOnly paraméterének használatával. Ha beállított egy földrajzi másodlagos példányt, ezzel lehetősége nyílik csatlakozni egy csak olvasható másolathoz az elsődleges helyen vagy a földrajzi másodlagos helyen.

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

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

Egy tipikus Azure-alkalmazás több Azure-szolgáltatást használ, és több összetevőből áll. Egy csoport feladatátvétele csak az Azure SQL Database állapota alapján aktiválódik. 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 (DR) régióra váltanak, a függő összetevők közötti késés növekedhet. A nagyobb késésnek az alkalmazás teljesítményére gyakorolt hatásának elkerülése érdekében gondoskodjon az alkalmazás összes összetevőjének redundanciáról a DR régióban, kövesse ezeket a hálózati biztonsági irányelveket, és vezényelje a megfelelő alkalmazásösszetevők geo-feladatátvételét az adatbázissal együtt.

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

Ha kimaradás történik az elsődleges régióban, előfordulhat, hogy a legutóbbi tranzakciókat nem replikálták a geo-másodlagosra, és adatvesztést okozhat, ha kényszerített feladatátvételt hajtanak végre.

Visszaállá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.

Engedélyek és korlátozások

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

Feladatátvételi csoportok programozással történő irányítása

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ókért tekintse át a(z) Az Azure SQL Database feladatátvételi csoportjának konfigurálásadokumentumot.

Magas rendelkezésre állás engedélyezése (zónaredundancia)

A rendelkezésre állás redundanciával történő biztosítása tovább javítja a rugalmasságot azáltal, hogy védi az adott régió rendelkezésre állási zónáinak kimaradásai ellen.

Egy vagy több adatbázist tartalmazó feladatátvételi csoport létrehozásakor nincs lehetőség a másodlagos adatbázisok magas rendelkezésre állásának engedélyezésére, függetlenül az elsődleges adatbázisok magas rendelkezésre állási beállításaitól.

Zónaredundancia nem rugalmas skálázású adatbázisokkal

A feladatátvételi csoporton keresztül létrehozott másodlagos adatbázisok alapértelmezés szerint nem magas rendelkezésre állással rendelkeznek. A feladatátvételi csoport létrehozása után engedélyezze a magas rendelkezésre állást a csoportban található adatbázisokon. Ez a viselkedés akkor is érvényes, ha először az Active Geo-Replication-t hozza létre, majd opcionálisan hozzáadja az adatbázisokat egy feladatátvételi csoporthoz.

Zónaredundancia rugalmas skálázással

A feladatátvételi csoporton létrehozott másodlagos adatbázisok öröklik a megfelelő elsődleges adatbázisok magas rendelkezésre állási beállításait. Ezért ha az elsődleges adatbázis magas rendelkezésre állású, akkor a másodlagos adatbázis is engedélyezve lesz. Ezzel szemben, ha az elsődleges adatbázis nem rendelkezik magas rendelkezésre állással, akkor a másodlagos adatbázis sem lesz engedélyezve.

A rendelkezésre állási zónák regionális támogatása

Ha az elsődleges adatbázisban engedélyezve van a magas rendelkezésre állás, és a hozzáadott másodlagos adatbázis egy olyan régióban van, amely még nem támogatja a rendelkezésre állási zónákat, a munkafolyamat a következő 45122-ös kódú hibaüzenettel hiúsul meg: "A feladatátvételi csoport műveletének létrehozása vagy frissítése sikeresen befejeződött; egyes adatbázisok azonban nem adhatók hozzá vagy távolíthatók el a feladatátvételi csoportból. A zónaredundáns adatbázis/készlet kiépítése nem támogatott az aktuális kéréshez. A problémát úgy tudja megkerülni, hogy az Aktív georeplikáció használatával engedélyezi vagy letiltja a magas rendelkezésre állást, miközben létrehozza a másodlagos adatbázist. Ezután igény szerint hozzáadhatja ezeket az adatbázisokat egy feladatátvételi csoporthoz.

Kapcsolódó tartalom

• A példaszkriptekkel kapcsolatban lásd:
  • A PowerShell használata az Azure SQL Database- aktív georeplikálásának konfigurálásához
  • A PowerShell használata az Azure SQL Database-ben készletezett adatbázisok aktív georeplikálásának konfigurálásához
  • Azure SQL Database hozzáadása feladatátvételi csoporthoz a PowerShell használatával
• Az üzletmenet-folytonosság áttekintéséért és forgatókönyveiért lásd: Üzletmenet-folytonosság áttekintése
• Az Azure SQL Database automatikus biztonsági mentéseiről SQL Database automatikus biztonsági mentéseinekcímű témakörben olvashat.
• Az automatikus biztonsági mentések helyreállítási célú használatáról a Adatbázis visszaállítása a szolgáltatás által kezdeményezett biztonsági másolatokbólcímű témakörben olvashat.
• Az új elsődleges kiszolgáló és adatbázis hitelesítési követelményeiről a vészhelyreállítás utáni SQL Database biztonságicímű témakörben olvashat.