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

Active geo-replication

  • Cikk

A következőre vonatkozik: Azure SQL Database

Az aktív georeplikációs funkció lehetővé teszi, hogy folyamatosan szinkronizálható, olvasható másodlagos adatbázist hozzon létre egy elsődleges adatbázishoz. Az olvasható másodlagos adatbázis lehet az elsőével azonos Azure-régióban, vagy – ez a gyakoribb eset – egy másik régióban. Az ilyen olvasható másodlagos adatbázis geo-másodlagos vagy georeplikaként is ismert.

Az aktív georeplikáció adatbázisonként van konfigurálva, és csak a manuális feladatátvételt támogatja. Ha adatbáziscsoportot szeretne feladatátvételre használni, vagy ha az alkalmazás stabil kapcsolati végpontot igényel, fontolja meg inkább a feladatátvételi csoportokat .

Az SQL Database migrálását aktív georeplikálással is használhatja.

Áttekintés

Az aktív georeplikálás üzletmenet-folytonossági megoldásként lett kialakítva. Az aktív georeplikálás lehetővé teszi az egyes adatbázisok gyors vészhelyreállítását regionális katasztrófa vagy nagy léptékű kimaradás esetén. A georeplikálás beállítása után geo-feladatátvételt kezdeményezhet egy másik Azure-régióban lévő geo-másodlagosra. A geo feladatátvételt az alkalmazás programozott módon vagy manuálisan kezdeményezi a felhasználó.

Az alábbi ábra egy georedundáns felhőalkalmazás jellemző konfigurációját mutatja be aktív georeplikációval.

active geo-replication

Ha az elsődleges adatbázis bármilyen okból meghiúsul, kezdeményezhet geo-feladatátvételt bármelyik másodlagos adatbázisba. Ha a másodlagos szerepkör előléptetve lesz az elsődleges szerepkörre, a rendszer automatikusan összekapcsolja az összes többi másodfokot az új elsődleges szerepkörrel.

A georeplikálást az alábbi módszerek bármelyikével kezelheti, és geo feladatátvételt kezdeményezhet:

Az aktív georeplikálás az Always On rendelkezésre állási csoport technológiáját használja az elsődleges replikán létrehozott tranzakciónapló aszinkron replikálására az összes georeplikára. Bármikor előfordulhat, hogy egy másodlagos adatbázis kissé le van maradva az elsődleges adatbázishoz képest, az adatok azonban a másodlagos adatbázison tranzakciós szempontból garantáltan konzisztensek maradnak. Más szóval a nem véglegesített tranzakciók módosításai nem láthatók.

Megjegyzés:

Az aktív georeplikálás a módosításokat streamelési adatbázis tranzakciónaplója alapján replikálja az elsődleges replikáról a másodlagos replikákra. Nem kapcsolódik a tranzakciós replikációhoz, amely dML -parancsok (IN Standard kiadás RT, UPDATE, DELETE) végrehajtásával replikálja a módosításokat az előfizetőkön.

A georeplikációs szolgáltatás regionális redundanciát biztosít. A regionális redundancia lehetővé teszi, hogy az alkalmazások gyorsan helyreálljanak egy teljes Azure-régió vagy egy régió egyes részeinek természeti katasztrófák, katasztrofális emberi hibák vagy rosszindulatú cselekedetek által okozott állandó veszteségéből. A georeplikációs RPO az üzletmenet-folytonosság áttekintésében található.

Az alábbi ábrán egy példa látható az usa északi középső régiójában elsődleges, az USA déli középső régiójában pedig egy geo-másodlagos georeplikációs konfigurálással konfigurált aktív georeplikációs adatokra.

geo-replication relationship

A vészhelyreállítás mellett az aktív georeplikációs műveletek a következő esetekben használhatók:

  • Adatbázis migrálása: Az aktív georeplikálással minimális állásidővel migrálhat egy adatbázist az egyik kiszolgálóról a másikra.
  • Alkalmazásfrissítések: Az alkalmazásfrissítések során létrehozhat egy másodlagos másodlagos példányt feladat-visszavételi másolatként.

A teljes üzletmenet-folytonosság érdekében az adatbázis regionális redundanciának hozzáadása csak a megoldás része. 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. A vészhelyreállítási megoldások tervezésével kapcsolatos további információkért lásd : Felhőmegoldások tervezése vészhelyreállításhoz aktív georeplikálás használatával.

Aktív georeplikációs terminológia és képességek

  • Automatikus aszinkron replikáció

    Csak egy meglévő adatbázishoz hozhat létre geosládát. A geo-másodlagos bármely logikai kiszolgálón létrehozható, kivéve az elsődleges adatbázissal rendelkező kiszolgálót. A létrehozás után a geo-másodlagos replika fel lesz töltve az elsődleges adatbázis adataival. Ezt a folyamatot vetésnek nevezzük. A geo-másodlagos létrehozása és üzembe helyezése után a rendszer automatikusan és aszinkron módon replikálja az elsődleges adatbázis frissítéseit a geo-másodlagos replikára. Az aszinkron replikáció azt jelenti, hogy a tranzakciók az elsődleges adatbázisban lesznek véglegesítettek a replikálás előtt.

  • Olvasható geo-másodlagos replikák

    Az alkalmazások hozzáférhetnek egy geo-másodlagos replikához, hogy írásvédett lekérdezéseket hajtsanak végre az elsődleges adatbázis eléréséhez használt ugyanazokkal vagy különböző biztonsági tagokkal. További információ: Írásvédett replikák használata írásvédett lekérdezési számítási feladatok kiszervezéséhez.

    Fontos

    A georeplikát használva másodlagos replikákat hozhat létre az elsődleges régióval megegyező régióban. Ezeket a másodfokokat használhatja az olvasási felskálázási forgatókönyvek kielégítésére ugyanabban a régióban. Az ugyanabban a régióban található másodlagos replika azonban nem biztosít további rugalmasságot a katasztrofális hibák vagy a nagy léptékű kimaradások ellen, ezért vészhelyreállítási célokra nem alkalmas feladatátvételi cél. Emellett nem garantálja a rendelkezésre állási zónák elkülönítését. A rendelkezésre állási zónák elkülönítéséhez használja üzletileg kritikus vagy prémium szintű szolgáltatási szintek zónaredundáns konfigurációját vagy általános célú szolgáltatásiszint-zónaredundáns konfigurációját.

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

    A feladatátvétel az elsődleges és a geo-másodlagos adatbázisok szerepköreit váltja át a teljes adatszinkronizálás befejezése után, így nincs adatvesztés. A feladatátvétel időtartama attól függ, hogy milyen méretű a tranzakciónapló az elsődlegesen, amelyet szinkronizálni kell a geo-másodlagosval. A feladatátvétel a következő forgatókönyvekhez készült:

    • Dr. részletezések végrehajtása éles környezetben, ha az adatvesztés nem elfogadható
    • Az adatbázis áthelyezése másik régióba
    • Adja vissza az adatbázist az elsődleges régiónak a kimaradás enyhítése (más néven feladat-visszavétel) után.

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

    A kényszerített feladatátvétel azonnal átváltja a geo-másodlagost az elsődleges szerepkörre anélkül, hogy az elsődlegessel való szinkronizálásra vár. Az elsődlegesen lekötött, de a másodlagosra még nem replikált tranzakciók elvesznek. Ez a művelet helyreállítási módszerként lett kialakítva, ha az elsődleges nem érhető el, de az adatbázis rendelkezésre állását gyorsan vissza kell állítani. Amikor az eredeti elsődleges ismét online állapotba kerül, az automatikusan újracsatlakozik, újra el lesz állítva az elsődlegestől származó aktuális adatokkal, és az új geo-másodlagossá válik.

    Fontos

    A feladatátvétel vagy a kényszerített feladatátvétel után az új elsődleges elsődleges kapcsolati végpontja megváltozik, mert az új elsődleges most már egy másik logikai kiszolgálón található.

  • Több olvasható geo-másodtár

    Egy elsődlegeshez legfeljebb négy geo-másodtár hozható létre. Ha csak egy másodlagos van, és sikertelen, az alkalmazás nagyobb kockázatnak lesz kitéve, amíg létre nem jön egy új másodlagos. Ha több másodfok is létezik, az alkalmazás akkor is védett marad, ha az egyik másodfok sikertelen. További másodfokok is használhatók az írásvédett számítási feladatok vertikális felskálázására.

    Tipp.

    Ha aktív georeplikációt használ egy globálisan elosztott alkalmazás létrehozásához, és négynél több régióban csak olvasható hozzáférést kell biztosítania az adatokhoz, létrehozhat egy másodlagos (láncolásnak nevezett) másodlagos példányt további georeplikák létrehozásához. A láncolt georeplikák replikációs késése magasabb lehet, mint az elsődlegeshez közvetlenül csatlakoztatott georeplikáknál. A láncolt georeplikációs topológiák beállítása csak programozott módon támogatott, az Azure Portalról nem.

  • Adatbázisok georeplikálása rugalmas készletben

    Minden geo-másodlagos lehet egy adatbázis vagy egy rugalmas készlet adatbázisa. Az egyes geo-másodlagos adatbázisok rugalmas készletválasztása különálló, és nem függ a topológia bármely más replikája konfigurációjától (akár elsődleges, akár másodlagos). Minden rugalmas készlet egyetlen logikai kiszolgálón belül található. Mivel egy logikai kiszolgálón az adatbázisneveknek egyedinek kell lenniük, ugyanazon elsődleges adatbázis több geomásodperce soha nem oszthat meg rugalmas készletet.

  • Felhasználó által vezérelt geo-feladatátvétel és feladat-visszavétel

    Az alkalmazás vagy a felhasználó bármikor explicit módon átválthat az elsődleges szerepkörre (feladatátvétel) az első vetés befejeztével. Olyan leállások során, ahol az elsődleges nem érhető el, csak kényszerített feladatátvétel használható, amely azonnal előléptet egy geo-másodlagost az új elsődlegesként. A kimaradás mérséklésekor a rendszer automatikusan geo-másodlagossá teszi a helyreállított elsődlegest, és naprakészen hozza az új elsődlegessel. A georeplikálás aszinkron jellege miatt előfordulhat, hogy a legutóbbi tranzakciók elvesznek a kényszerített feladatátvétel során, ha az elsődleges meghiúsul, mielőtt ezek a tranzakciók geo másodlagosra replikálódnak. Ha egy több geo-másodrendű elsődleges feladat meghiúsul, a rendszer automatikusan újrakonfigurálja a replikációs kapcsolatokat, és felhasználói beavatkozás nélkül összekapcsolja a többi geomásodpertet az újonnan előléptetett elsődlegessel. A geo feladatátvételt okozó kimaradás enyhítése után célszerű lehet az elsődlegest az eredeti régióba visszaküldeni. Ehhez végezzen manuális feladatátvételt.

  • Készenléti replika

    Ha a másodlagos replikát csak vészhelyreállításra (DR) használják, és nem rendelkezik olvasási vagy írási számítási feladatokkal, a replikát készenlétiként is kijelölheti a licencelési költségek csökkentése érdekében.

Felkészülés a geo feladatátvételre

Annak érdekében, hogy az alkalmazás azonnal hozzáférhessen az új elsődlegeshez a geo feladatátvétel után, ellenőrizze, hogy a másodlagos kiszolgáló hitelesítése és hálózati hozzáférése megfelelően van-e konfigurálva. További részletekért tekintse meg az SQL Database vészhelyreállítás utáni biztonságát. Azt is ellenőrizze, hogy a másodlagos adatbázis biztonsági mentési megőrzési szabályzata megegyezik-e az elsődleges adatbázis biztonsági mentési szabályzatával. Ez a beállítás nem része az adatbázisnak, és nem replikálódik az elsődlegesből. Alapértelmezés szerint a geo-másodlagos a hét napos alapértelmezett PITR-megőrzési időtartammal van konfigurálva. További részletekért tekintse meg az SQL Database automatikus biztonsági mentéseit.

Fontos

Ha az adatbázis egy feladatátvételi csoport tagja, a georeplikációs feladatátvételi paranccsal nem kezdeményezheti a feladatátvételt. Használja a csoport feladatátvételi parancsát. Ha egyéni adatbázis feladatátvételére van szüksége, először el kell távolítania azt a feladatátvételi csoportból. Részletekért tekintse meg a feladatátvételi csoportokat .

Geo-másodlagos konfigurálás

Az elsődleges és a geo-másodlagos szolgáltatásszintnek is azonos szolgáltatási szinttel kell rendelkeznie. Azt is erősen ajánlott, hogy a geo-másodlagos legyen konfigurálva ugyanazzal a biztonsági mentési tárolási redundanciával, számítási szinttel (kiépített vagy kiszolgáló nélküli) és számítási mérettel (DTU-k vagy virtuális magok) elsődlegesként. Ha az elsődleges nagy írási számítási feladatot tapasztal, előfordulhat, hogy egy alacsonyabb számítási mérettel rendelkező geo-másodlagos nem tudja tartani a lépést. Ez a geo-másodlagos replikáció késését okozza, és végül a geo-másodlagos elérhetetlenségét okozhatja. Ezeknek a kockázatoknak a mérséklése érdekében az aktív georeplikációs szolgáltatás csökkenti (szabályozza) az elsődleges tranzakciónaplók sebességét, ha szükséges, hogy a másodpéldányok felzárkózhassanak.

Egy kiegyensúlyozatlan geo-másodlagos konfiguráció másik következménye, hogy a feladatátvétel után az alkalmazás teljesítménye az új elsődleges számítási kapacitás elégtelen kapacitása miatt szenvedhet. Ebben az esetben fel kell skálázni az adatbázist, hogy elegendő erőforrással rendelkezzen, ami jelentős időt vehet igénybe, és magas rendelkezésre állású feladatátvételt igényel a vertikális felskálázási folyamat végén, ami megszakíthatja az alkalmazás számítási feladatait.

Ha úgy dönt, hogy egy másik konfigurációval hozza létre a geo-másodlagost, akkor az elsődleges idő függvényében kell figyelnie a napló I/O-sebességét. This lets you estimate the minimal compute size of the geo-secondary required to sustain the replication load. Ha például az elsődleges adatbázis P6 (1000 DTU), és a napló IO-értéke 50%-os, akkor a geo-másodlagosnak legalább P4 -nek (500 DTU- nak) kell lennie. Az előzménynapló I/O-adatainak lekéréséhez használja a sys.resource_stats nézetet. Ha a legutóbbi napló I/O-adatokat nagyobb részletességgel szeretné lekérni, amely jobban tükrözi a rövid távú kiugró értékeket, használja a sys.dm_db_resource_stats nézetet.

Tipp.

A tranzakciónapló I/O-szabályozása az elsődlegesen a geo-másodlagos rendszer alacsonyabb számítási mérete miatt a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO várakozási típus használatával történik, amely a sys.dm_exec_requests és sys.dm_os_wait_stats adatbázisnézetekben látható.

Az elsődleges tranzakciónapló I/O-jának szabályozása olyan okok miatt lehetséges, amelyek nem kapcsolódnak a geo-másodlagos számítási méret csökkentéséhez. Ez a fajta szabályozás akkor is előfordulhat, ha a geo-másodlagos számítási mérete megegyezik vagy nagyobb, mint az elsődleges. További részletekért, beleértve a különböző naplózási I/O-szabályozások várakozási típusait, tekintse meg a tranzakciónaplók sebességszabályozását.

Alapértelmezés szerint a geo-másodlagos biztonsági mentési tár redundanciása megegyezik az elsődleges adatbáziséval. Dönthet úgy, hogy egy geo-másodlagos tárolót egy másik biztonsági mentési tár redundanciájával konfigurál. A biztonsági mentések mindig az elsődleges adatbázisban vannak. Ha a másodlagos tároló más biztonsági mentési redundanciával van konfigurálva, akkor a geo feladatátvétel után, amikor a geo-másodlagos előlépteti az elsődlegesre, az új biztonsági másolatok tárolása és számlázása az új elsődleges (korábbi másodlagos) elsődlegesen kiválasztott tárolási típus (RA-GRS, ZRS, LRS) szerint történik.

Költségmegtakarítás a készenléti replikával

Ha a másodlagos replikát csak vészhelyreállításhoz (DR) használják, és nem rendelkezik olvasási vagy írási számítási feladatokkal, az új aktív georeplikációs kapcsolat konfigurálásakor az adatbázis készenléti állapotba állításával csökkentheti a licencelési költségeket.

További információért tekintse át a licencmentes készenléti replikát .

Cross-subscription geo-replication

A Transact-SQL (T-SQL) használatával hozzon létre egy geo-másodlagosat egy olyan előfizetésben, amely eltér az elsődleges előfizetésétől (függetlenül attól, hogy a Microsoft Entra ID (korábbi nevén Azure Active Directory) ugyanazon bérlője alatt van-e. További információért tekintse át az aktív georeplikációs konfigurálást .

Hitelesítő adatok és tűzfalszabályok szinkronizálása

Ha nyilvános hálózati hozzáférést használ az adatbázishoz való csatlakozáshoz, javasoljuk, hogy adatbázisszintű IP-tűzfalszabályokat használjon a georeplikált adatbázisokhoz. Ezek a szabályok az adatbázissal vannak replikálva, ami biztosítja, hogy az összes geo-másodpéldány ugyanazokat az IP-tűzfalszabályokat tartalmazza, mint az elsődleges. Ez a megközelítés szükségtelenné teszi, hogy az ügyfelek manuálisan konfigurálják és fenntartsák a tűzfalszabályokat az elsődleges és másodlagos adatbázisokat üzemeltető kiszolgálókon. Hasonlóképpen, a tartalmazott adatbázis-felhasználók adathozzáféréshez való használata biztosítja, hogy az elsődleges és a másodlagos adatbázisok mindig ugyanazokkal a hitelesítési hitelesítő adatokkal rendelkezzenek. Így a geo feladatátvétel után a hitelesítési hitelesítő adatok eltérései nem okoznak fennakadásokat. Ha bejelentkezéseket és felhasználókat használ (nem tartalmazott felhasználókat), további lépéseket kell tennie annak érdekében, hogy ugyanazok a bejelentkezések létezhessenek a másodlagos adatbázishoz. A konfiguráció részleteiért lásd : Bejelentkezések és felhasználók konfigurálása.

Scale primary database

Az elsődleges adatbázist felskálázhatja vagy leskálázhatja egy másik számítási méretre (ugyanabban a szolgáltatási szinten belül), anélkül, hogy leválasztaná a földrajzi másodtárat. Ha felskálázást végez, azt javasoljuk, hogy először a földrajzilag másodlagos példányt, majd az elsődleges példányt skálázza fel vertikálisan. Vertikális leskálázáskor fordítsa meg a sorrendet: először az elsődleges, majd másodlagos példányt skálázza le.

Megjegyzés:

Ha a másodlagos georeplikát feladatátvételi csoport konfigurációjának részeként hozta létre, akkor nem ajánlott leskálázni. Így biztosítható, hogy az adatszint elegendő kapacitással rendelkezzen a normál számítási feladatok feldolgozásához egy földrajzi feladatátvétel után.

Fontos

A feladatátvételi csoport elsődleges adatbázisa csak akkor skálázható magasabb szolgáltatási szintre (kiadásra), ha a másodlagos adatbázis először a magasabb szintre van skálázva. Ha például az elsődleges skálázást általános célúról üzletileg kritikus-ra szeretné felskálázni, először a geo-másodlagost kell üzletileg kritikus skáláznia. Ha úgy próbálja skálázni az elsődleges vagy geo-másodlagos skálázást, hogy az megsérti ezt a szabályt, a következő hibaüzenet jelenik meg:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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

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

Megjegyzés:

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

Georeplikáció késésének monitorozása

To monitor lag with respect to RPO, use replication_lag_sec column of sys.dm_geo_replication_link_status on the primary database. It shows lag in seconds between the transactions committed on the primary, and hardened to the transaction log on the secondary. For example, if the lag is one second, it means that if the primary is impacted by an outage at this moment and a geo-failover is initiated, transactions committed in the last second will be lost.

Az elsődleges adatbázis geo-másodlagoson rögzített változásainak késésének méréséhez hasonlítsa össze last_commit geo-másodlagos idő és az elsődleges érték azonos értékével.

Tipp.

Ha az elsődleges replication_lag_sec NULL értékű, az azt jelenti, hogy az elsődleges jelenleg nem tudja, hogy milyen messze van egy geo-másodlagostól. Ez általában a folyamat újraindítása után történik, és átmeneti feltételnek kell lennie. Érdemes lehet riasztást küldeni, ha replication_lag_sec hosszabb ideig null értéket ad vissza. Ez azt jelezheti, hogy a geo-másodlagos nem tud kommunikálni az elsődlegessel kapcsolati hiba miatt.

Vannak olyan feltételek is, amelyek a geo-másodlagos és az elsődlegesen last_commit idő közötti különbséget okozhatják. Ha például egy véglegesítés az elsődlegesen történik hosszú, nem módosuló időszak után, a különbség felugrik egy nagy értékre, mielőtt gyorsan nullára tér vissza. Érdemes lehet riasztást küldeni, ha a két érték közötti különbség hosszú ideig nagy marad.

Aktív georeplikációs programozott kezelés

A korábban tárgyaltak szerint az aktív georeplikálás programozott módon is felügyelhető a T-SQL, az Azure PowerShell és a REST API használatával. Az alábbi táblázatok az elérhető parancsok készletét ismertetik. Az aktív georeplikálás számos Azure Resource Manager API-t tartalmaz a felügyelethez, beleértve az Azure SQL Database REST API-t és az Azure PowerShell-parancsmagokat. Ezek az API-k támogatják az Azure szerepköralapú hozzáférés-vezérlését (Azure RBAC). A hozzáférési szerepkörök implementálásáról további információt az Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC) című témakörben talál.

T-SQL: Önálló és készletezett adatbázisok geo feladatátvételének kezelése

Fontos

Ezek a T-SQL-parancsok csak az aktív georeplikációs műveletekre vonatkoznak, és nem vonatkoznak a feladatátvételi csoportokra. Ezért nem vonatkoznak a felügyelt SQL-példányokra, amelyek csak a feladatátvételi csoportokat támogatják.

Parancs Leírás
ALTER DATABASE Az ADD Standard kiadás CONDARY ON Standard kiadás RVER argumentum használatával hozzon létre egy másodlagos adatbázist egy meglévő adatbázishoz, és indítsa el az adatreplikálást
ALTER DATABASE Feladatátvétel vagy FORCE_FAILOVER_ALLOW_DATA_LOSS használata másodlagos adatbázis elsődlegesként való váltásához a feladatátvétel kezdeményezéséhez
ALTER DATABASE A REMOVE Standard kiadás CONDARY ON Standard kiadás RVER használatával állítsa le az SQL Database és a megadott másodlagos adatbázis közötti adatreplikálást.
sys.geo_replication_links A kiszolgálón lévő összes adatbázis összes meglévő replikációs hivatkozására vonatkozó információt adja vissza.
sys.dm_geo_replication_link_status Lekéri az utolsó replikációs időt, az utolsó replikáció késését és az adott adatbázis replikációs hivatkozásával kapcsolatos egyéb információkat.
sys.dm_operation_status Megjeleníti az összes adatbázis-művelet állapotát, beleértve a replikációs hivatkozások módosítását is.
sys.sp_wait_for_database_copy_sync Emiatt az alkalmazás megvárja, amíg az összes véglegesített tranzakciót meg nem keményíti egy geo-másodlagos tranzakciónapló.

PowerShell: Önálló és készletezett adatbázisok geo feladatátvételének kezelése

Megjegyzés:

Ez a cikk az Azure Az PowerShell-modult használja, amely az Azure-ral való interakcióhoz ajánlott PowerShell-modul. Az Az PowerShell-modul használatának megkezdéséhez lásd az Azure PowerShell telepítését ismertető szakaszt. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

Fontos

A PowerShell Azure Resource Manager modult továbbra is támogatja az Azure SQL Database, de minden jövőbeli fejlesztés az Az.Sql modulhoz tartozik. Ezekhez a parancsmagokhoz lásd: AzureRM.Sql. Az Az modulban és az AzureRm-modulokban található parancsok argumentumai lényegében azonosak.

Parancsmag Leírás
Get-AzSqlDatabase Egy vagy több adatbázist kér le.
New-AzSqlDatabaseSecondary Létrehoz egy másodlagos adatbázist egy meglévő adatbázishoz, és elkezdi az adatok replikálását.
Set-AzSqlDatabaseSecondary Egy másodlagos adatbázist elsődlegessé tesz, hogy feladatátvételt kezdeményezzen.
Remove-AzSqlDatabaseSecondary Leállítja az adatreplikációt egy SQL-adatbázis és a megadott másodlagos adatbázis között.
Get-AzSqlDatabaseReplicationLink Lekéri egy adatbázis georeplikációs hivatkozásait.

Tipp.

A példaszkriptekkel kapcsolatban lásd : Egyetlen adatbázis konfigurálása és feladatátvétele aktív georeplikációs és konfigurált adatbázis konfigurálása és feladatátvétele aktív georeplikációs módszerrel.

REST API: Önálló és készletezett adatbázisok geo-feladatátvételének kezelése

API Leírás
Adatbázis létrehozása vagy frissítése (createMode=Restore) Elsődleges vagy másodlagos adatbázist hoz létre, frissít vagy állít vissza.
Adatbázis létrehozásának vagy frissítésének állapotának lekérése Egy létrehozási művelet során visszaadja az állapotot.
Másodlagos adatbázis beállítása elsődlegesként (tervezett feladatátvétel) Beállítja, hogy melyik másodlagos adatbázis elsődleges, ha az aktuális elsődleges adatbázisból való feladatátvételt végzi el. Ez a beállítás a felügyelt SQL-példányok esetében nem támogatott.
Másodlagos adatbázis beállítása elsődlegesként (nem tervezett feladatátvétel) Beállítja, hogy melyik másodlagos adatbázis elsődleges, ha az aktuális elsődleges adatbázisból való feladatátvételt végzi el. Ez a művelet adatvesztést okozhat. Ez a beállítás a felügyelt SQL-példányok esetében nem támogatott.
Replikációs hivatkozás lekérése Lekéri egy adott adatbázis adott replikációs hivatkozását egy georeplikációs partnerségben. Lekéri a sys.geo_replication_links katalógusnézetben látható információkat. Ez a beállítás a felügyelt SQL-példányok esetében nem támogatott.
Replikációs hivatkozások – Listázás adatbázis szerint Lekéri egy adott adatbázis összes replikációs hivatkozását egy georeplikációs partnerségben. Lekéri a sys.geo_replication_links katalógusnézetben látható információkat.
Replikációs hivatkozás törlése Adatbázis-replikációs hivatkozás törlése. Feladatátvétel során nem végezhető el.

További lépések