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

Aktív georeplikáció

A következőkre vonatkozik:Azure SQL Database

Ez a cikk az Azure SQL Database aktív georeplikációs funkcióját ismerteti és áttekinti, amely lehetővé teszi az adatok folyamatos replikálását egy elsődleges adatbázisból egy olvasható másodlagos adatbázisba. Az olvasható másodlagos adatbázis ugyanabban az Azure-régióban lehet, mint az elsődleges, vagy gyakrabban 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. Ha egy adatbáziscsoport feladatátvételét kell megoldani, vagy az alkalmazás stabil kapcsolati végpontot igényel, fontolja meg inkább a feladatátvételi csoportok használatát.

Az SQL-adatbázisokat aktív georeplikálással is migrá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.

Az aktív georeplikációs diagram.

Ha az elsődleges adatbázis bármilyen okból meghiúsul, kezdeményezhet geo-átállást bármelyik másodlagos adatbázisra. 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, valamint 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 az elsődleges replikáról a másodlagos replikákra a tranzakciónapló folyamatos továbbításával replikálja a módosításokat. Nem kapcsolódik a tranzakciós replikációhoz, amely dML -parancsok (INSERT, 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 Azure SQL Database üzletmenet-folytonosságának áttekintésében található.

Az alábbi ábrán egy olyan aktív georeplikációs példa látható, amely az USA 2. nyugati régiójában egy elsődleges, az USA keleti régiójában pedig geo-másodlagosként van konfigurálva.

Képernyőkép az Azure Portalról egy SQL DB georeplikációs kapcsolatról.

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 példányt biztonsági másolatként visszaállításhoz.

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: Globálisan elérhető szolgáltatások tervezése az Azure SQL Database használatával.

Terminológia és képességek

  • Automatikus aszinkron replikáció

    Csak egy meglévő adatbázishoz hozhat létre egy földrajzi másolatot. 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ó geoszekunder 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. A további információkért lásd: Írásvédett replikák használata az olvasási lekérdezési terhelés csökkentésére.

    Fontos

    A georeplikát használva másodlagos replikákat hozhat létre az elsődleges régióval megegyező régióban. Használhatja ezeket a másodlagos adatbázisokat a skálázási olvasási igények 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. Az üzletileg kritikus vagy prémium szintű szolgáltatási szintek zónaredundáns konfigurációja vagy általános célú szolgáltatásszint-zónaredundáns konfiguráció használata a rendelkezésre állási zónák elkülönítésének eléréséhez.

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

    Az átállás az elsődleges és a geo-másodlagos adatbázisok szerepeinek átváltását végzi el, miután befejeződött a teljes adatszinkronizálás, így nincs adatvesztés. A feladatátvétel időtartama attól függ, hogy mekkora a tranzakciónapló mérete az elsődleges szerveren, amelyet szinkronizálni kell a geo-másodlagoshoz. Átállás a következő forgatókönyvekre tervezett:

    • Katasztrófa-helyreállítási gyakorlatok végrehajtása a produkciós környezetben, amikor az adatvesztés nem elfogadható.
    • Az adatbázis áthelyezése másik régióba
    • Az adatbázist vigye vissza az elsődleges régióba, miután a kimaradást enyhítették (közismert nevén: visszaállás).

  • Kényszerített átváltás (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, automatikusan újracsatlakozik, újra feltöltődik az elsődlegestől származó aktuális adatokkal, és ú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 kapcsolati végpontja megváltozik, mivel az új elsődleges most 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.

    Jótanács

    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 önálló adatbázis vagy egy rugalmas készletben található adatbázis. 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 geográfiai átállás és visszaállás

    Az alkalmazás vagy a felhasználó bármikor kifejezetten átválthatja a geo-sekundert az elsődleges szerepkörre (a feladatátvétel megtörténhet), miután az elsődleges vetítés befejeződött. Olyan kimaradások során, amikor az elsődleges nem érhető el, csak kényszerített átvétel használható, amely azonnal előlépteti a földrajzi másodlagost az új elsődlegessé. A kimaradás mérséklésekor a rendszer automatikusan geo-másodlagossá teszi a helyreállított elsődlegest, és up-todátumot hoz az új elsődlegeshez. 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 földrajzi átkapcsolást okozó kimaradás enyhítése után célszerű lehet az elsődlegest az eredeti régióba visszaállítani. Ehhez végezzen manuális átkapcsolást.

  • 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 geografiai átváltásra

Annak érdekében, hogy az alkalmazás azonnal hozzáférjen az új elsődleges kiszolgálóhoz 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 konfigurálva. 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. 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-szekunder hét napos alapértelmezett PITR-megőrzési időtartammal van konfigurálva. További információ: Automatikus biztonsági mentések az Azure SQL Database-ben.

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 csoporthoz tartozó failover parancsot. 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 Failover 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 példány legyen konfigurálva ugyanazzal a biztonsági mentési tárolási redundanciával, számítási szinttel (előre kiépített vagy kiszolgáló nélküli) és számítási mérettel (DTU-k vagy virtuális magok) mint az elsődleges. Ha az elsődleges nagy írási terhelést tapasztal, előfordulhat, hogy egy kisebb számítási kapacitással rendelkező geo-másodlagos nem tudja tartani a lépést. Ez a földrajzi másodlagos rendszer replikációs késését okozza, és végül a földrajzi másodlagos rendszer elérhetetlenségét eredményezheti. Ezeknek a kockázatoknak a mérséklése érdekében az aktív georeplikáció csökkenti (korlátozza) az elsődleges tranzakciónapló átvitelének ütemét, ha szükséges, hogy a másodpéldányok felzárkózhassanak.

Egy kiegyensúlyozatlan geográfiai másodlagos konfiguráció további következménye, hogy az átállás után az alkalmazás teljesítménye szenvedhet az új elsődleges számítási kapacitás elégtelensége miatt. 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 idővel figyelnie kell a napló I/O sebességét az elsődleges rendszeren. Így megbecsülheti a földrajzilag másodlagos replika a replikációs terhelés fenntartásához szükséges minimális számítási méretét. Ha például az elsődleges adatbázis P6 (1000 DTU) és a napló IO értéke folyamatosan 50%, akkor a földrajzi másodlagos adatbázisnak legalább P4 (500 DTU) -nak kell lennie. Az előzménynapló IO-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.

Jótanács

A tranzakciónapló I/O-szabályozása a következő esetekben fordulhat elő:

  • ** Ha a másodlagos földrajzi egység kisebb számítási kapacitással rendelkezik, mint az elsődleges. Keresse meg a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO várakozási típust az sys.dm_exec_requests és az sys.dm_os_wait_stats adatbázisnézetekben.
  • A számítási mérethez nem kapcsolódó okok. 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 mentési tárolási redundanciával van konfigurálva, akkor geo-failover után, amikor a geo-másodlagos az elsődlegessé válik, az új biztonsági másolatok tárolása és számlázása az új elsődleges (korábbi másodlagos) kiválasztott tárolási típusára (RA-GRS, ZRS, LRS) 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 történő kiosztásával csökkentheti a licencelési költségeket.

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

Előfizetések közötti georeplikációs szolgáltatás

  • Az Azure Portal használatával aktív georeplikálást állíthat be az előfizetések között, ha mindkét előfizetés ugyanabban a Microsoft Entra-bérlőben található.

    • Ha egy másik Microsoft Entra-bérlő elsődleges előfizetésétől eltérő előfizetésben szeretne geo-másodlagos replikát létrehozni, használja az SQL-hitelesítést és a T-SQL-t. A Microsoft Entra-hitelesítés nem támogatott az előfizetések közötti georeplikáció során, ha a logikai kiszolgáló egy másik Azure-bérlőben található.
    • Az előfizetések közötti georeplikációs műveletek, beleértve a telepítést és a geo-helyreállítást, szintén támogatottak a Databases Create or Update REST API használatával.

  • Az előfizetések közötti geo-másodlagos létrehozása ugyanazon vagy másik Microsoft Entra-bérlőn lévő logikai kiszolgálón nem támogatott, ha a Microsoft Entra-only azonosítás engedélyezve van az elsődleges vagy másodlagos logikai kiszolgálón, és a létrehozást egy Microsoft Entra ID felhasználóval kíséreli meg.

A módszerekről és a részletes utasításokról a következő oktatóanyagban olvashat: Aktív georeplikálás és feladatátvétel konfigurálása (Azure SQL Database).

Privát végpontok

Ha egy magánvégponton keresztül csatlakozik az elsődleges kiszolgálóhoz, a T-SQL használatával nem lehet geo-másodlagost hozzáadni.

  • Ha egy privát végpont konfigurálva van, de a nyilvános hálózati hozzáférés engedélyezett, a geo-másodlagos hozzáadása támogatott, ha nyilvános IP-címről csatlakozik az elsődleges kiszolgálóhoz.
  • Geo-másodlagos hozzáadása után a nyilvános hálózati hozzáférés megtagadható.

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 egy földrajzi feladatátvétel után a hitelesítési 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: Az Azure SQL Database biztonságának konfigurálása és kezelése geovisszaállításhoz vagy feladatátvétel esetére.

Elsődleges adatbázis skálázása

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. A felskálázás során javasoljuk, hogy először a geo-másodlagost skálázza fel, majd az elsődlegest. Lefelé skálázáskor fordítsa meg a sorrendet: először skálázza le az elsődlegeset, majd skálázza le a másodlagost.

További információért a feladatátvételi csoportokról tekintse át a replikák méretezését egy feladatátvételi csoportban.

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

A nagy kiterjedésű hálózatok nagy késése miatt a georeplikálás aszinkron replikációs mechanizmust használ. Az aszinkron replikáció elkerülhetetlenné teszi az adatvesztés lehetőségét, ha az elsődleges hiba meghiúsul. A kritikus tranzakciók adatvesztéssel szembeni védelme érdekében az alkalmazásfejlesztő közvetlenül a tranzakció véglegesítése után meghívhatja a sp_wait_for_database_copy_sync tárolt eljárást. A sp_wait_for_database_copy_sync hívása letiltja a hívási folyamatot, amíg az utolsó véglegesített tranzakciót nem továbbították és rögzítették a másodlagos adatbázis tranzakciónaplójában. Arra is vár, hogy az átvitt 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 bizonyos tranzakciók esetében a geo-failover után, de nem garantálja a teljes szinkronizációt az olvasáshoz való hozzáféréshez. Az sp_wait_for_database_copy_sync eljáráshívás által okozott késés jelentős lehet, és a hívás időpontjában az elsődleges rendszeren még nem továbbított tranzakciónapló méretétől függ.

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

Az RPO-val kapcsolatos késés figyeléséhez használja replication_lag_sec sys.dm_geo_replication_link_status oszlopát az elsődleges adatbázisban. Az elsődlegesen lekötött és a másodlagos tranzakciónaplóhoz rögzített tranzakciók közötti késést jeleníti meg másodpercekben. Ha például a késés egy másodperc, az azt jelenti, hogy ha az elsődlegesen pillanatnyi kimaradás történik, és geo-feladatátvétel indul, elvesznek az utolsó másodpercben végrehajtott tranzakciók.

A késés méréséhez az elsődleges adatbázison végrehajtott és a geo-másodlagoson megerősített változásokat illetően hasonlítsa össze a geo-másodlagoson lévő időt az elsődlegesen található ugyanezzel az értékkel.

Jótanács

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ődleges között a last_commit idő különbségét jelentősen megnövelhetik. Például, ha egy elkötelezettség az elsődleges ágon történik egy hosszú, módosítások nélküli időszak után, a különbség hirtelen egy nagy értékre ugrik fel, mielőtt gyorsan visszaáll nullára. Érdemes lehet riasztást küldeni, ha a két érték közötti különbség hosszú ideig nagy marad.

Programozottan irányítsa az aktív georeplikációt

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.

Fontos

Ezek a T-SQL-parancsok csak az aktív georeplikációs műveletekre vonatkoznak, és nem vonatkoznak a feladatátvételi csoportokra.

Parancs Leírás
ALTER DATABASE Használja a MÁSODLAGOS KISZOLGÁLÓ HOZZÁADÁSA argumentumot, hogy másodlagos adatbázist hozzon létre egy meglévőhöz és elindítsa az adatok replikálását.
ALTER DATABASE FAILOVER vagy FORCE_FAILOVER_ALLOW_DATA_LOSS parancs használata a másodlagos adatbázis elsődlegessé váltására a feladatátvétel kezdeményezésére
ALTER DATABASE Az SQL Database és a megadott másodlagos adatbázis közötti adatreplikálás leállításához használja a REMOVE SECONDARY ON SERVER parancsot.
sys.geo_replication_links (földrajzi replikációs kapcsolatok) 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 véglegesen rögzítik egy földrajzi másodlagos tranzakciónaplóban.

Kapcsolódó tartalom

Aktív georeplikációs konfigurálás:

Egyéb üzletmenet-folytonossági tartalom: