Adatbázis-erőforrások migrálása a globális Azure-ba

  • Cikk

Fontos

2018 augusztusa óta nem fogadunk új ügyfeleket, és nem helyeztünk üzembe új funkciókat és szolgáltatásokat az eredeti Microsoft Cloud Germany-helyeken.

Az ügyfelek igényeinek alakulására alapozva nemrég elindítottunk két új adatközpont-régiót Németországban, amelyek az ügyféladatok tárolását, a Microsoft globális felhőhálózatához való teljes kapcsolódást, valamint a piaci verseny díjszabását kínálják.

Emellett 2020. szeptember 30-án bejelentettük, hogy a Microsoft Cloud Germany 2021. október 29-én bezár. További részletek itt érhetők el: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

A mai migrálással kihasználhatja az új német adatközpont-régiókban elérhető funkciók széles választékát, a nagyvállalati szintű biztonságot és az átfogó funkciókat.

Ez a cikk olyan információkat tartalmaz, amelyek segítségével azure-adatbázis-erőforrásokat migrálhat az Azure Germanyből a globális Azure-ba.

SQL Database

Ha kisebb Azure SQL adatbázis számítási feladatait szeretné migrálni anélkül, hogy az áttelepített adatbázis online állapotban marad, hozzon létre egy BACPAC-fájlt az exportálási függvénnyel. A BACPAC-fájlok tömörített (tömörített) fájlok, amelyek metaadatokat és az SQL Server adatbázisból származó adatokat tartalmazzák. A BACPAC-fájl létrehozása után átmásolhatja a fájlt a célkörnyezetbe (például az AzCopy használatával), és az importálási függvénnyel újraépítheti az adatbázist. Vegye figyelembe a következő szempontokat:

  • Ahhoz, hogy egy exportálás tranzakciós szempontból konzisztens legyen, győződjön meg arról, hogy az alábbi feltételek egyike teljesül:
    • Az exportálás során nem történik írási tevékenység.
    • Az SQL-adatbázis tranzakciós szempontból konzisztens másolatából exportálhat.
  • Az Azure Blob Storage-ba való exportáláshoz a BACPAC-fájl mérete legfeljebb 200 GB lehet. Nagyobb BACPAC-fájl esetén exportáljon helyi tárolóba.
  • Ha a SQL Database exportálási művelete 20 óránál tovább tart, a művelet megszakítható. A teljesítmény növeléséhez az alábbi cikkekben talál tippeket.

Megjegyzés

A kapcsolati karakterlánc az exportálási művelet után módosul, mert a kiszolgáló DNS-neve megváltozik az exportálás során.

További információk:

Megjegyzés

Javasoljuk, hogy az Azure-ral való interakcióhoz az Azure Az PowerShell-modult használja. Az első lépésekhez tekintse meg az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.

SQL Database áttelepítése aktív georeplikációval

Olyan adatbázisok esetében, amelyek túl nagyok a BACPAC-fájlokhoz, vagy ha az egyik felhőből a másikba szeretne migrálni, és minimális állásidővel online maradnak, konfigurálhatja az aktív georeplikációt az Azure Germanyből a globális Azure-ba.

Fontos

Az aktív georeplikáció konfigurálása adatbázisok globális Azure-ba való migrálásához csak a Transact-SQL (T-SQL) használatával támogatott, és a migrálás előtt engedélyeznie kell az előfizetését, hogy támogassa a globális Azure-ba való migrálást. A kérés elküldéséhez használja ezt a támogatási kérelem hivatkozását.

Megjegyzés

Az Azure-beli globális felhőrégiók (Németország, Nyugat-Közép- és Észak-Németország) az Azure Germany-felhővel történő aktív georeplikáció támogatott régiói. Ha egy alternatív globális Azure-régióra van szükség a végső adatbázis(ok) célhelyeként, a globális Azure-ba való migrálás befejezése után javasolt egy további georeplikációs kapcsolatot konfigurálni Németországtól Nyugat-Közép-Németországtól vagy Észak-Németországtól a szükséges Globális Azure-felhőrégióhoz.

Az aktív georeplikáció költségeiről az Aktív georeplikáció a Azure SQL Database díjszabásában című szakaszban talál további információt.

Az aktív georeplikációval rendelkező adatbázisok migrálásához egy Azure SQL logikai kiszolgálóra van szükség a globális Azure-ban. A kiszolgálót létrehozhatja a portál, a Azure PowerShell, az Azure CLI stb. használatával, de az aktív georeplikáció konfigurálása az Azure Germanyből a globális Azure-ba való migráláshoz csak a Transact-SQL (T-SQL) használatával támogatott.

Fontos

A felhők közötti migráláskor az elsődleges (Azure Germany) és a másodlagos (globális Azure) kiszolgálónévelőtagoknak eltérőnek kell lenniük. Ha a kiszolgálónevek megegyeznek, az ALTER DATABASE utasítás futtatása sikeres lesz, de a migrálás sikertelen lesz. Ha például az elsődleges kiszolgáló nevének előtagja myserver (myserver.database.cloudapi.de), a másodlagos kiszolgáló nevének előtagja a globális Azure-ban nem lehet myserver.

A ALTER DATABASE utasítás lehetővé teszi egy célkiszolgáló megadását a globális Azure-ban a teljes DNS-kiszolgáló nevének használatával a céloldalon.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbaz adatbázis nevét jelöli egy Azure SQL-kiszolgálón az Azure Germany-ban.
  • public-server.database.windows.neta globális Azure-ban létező Azure SQL kiszolgálónevet jelöli, ahol az adatbázist át kell telepíteni. A "database.windows.net" névtérre van szükség, cserélje le a nyilvános kiszolgálót a logikai SQL-kiszolgáló nevére a globális Azure-ban. A globális Azure-beli kiszolgálónak más névvel kell rendelkeznie, mint az Azure Germany elsődleges kiszolgálójának.

A parancs végrehajtása a migrálni kívánt helyi adatbázist üzemeltető Azure Germany-kiszolgálón található master adatbázison történik.

  • A T-SQL start-copy API hitelesíti a bejelentkezett felhasználót a nyilvános felhőkiszolgálón azáltal, hogy megkeres egy olyan felhasználót, aki ugyanazzal az SQL-bejelentkezéssel/felhasználónévvel rendelkezik a kiszolgáló master adatbázisában. Ez a megközelítés felhőfüggetlen; így a T-SQL API a felhők közötti másolatok indítására szolgál. Az engedélyekkel és a témakörrel kapcsolatos további információkért lásd: Aktív georeplikáció ésALTER DATABASE (Transact-SQL) létrehozása és használata.

  • A kezdeti T-SQL-parancsbővítmény kivételével, amely egy Azure SQL logikai kiszolgálót jelez a globális Azure-ban, az aktív georeplikációs folyamat többi része megegyezik a helyi felhőben meglévő végrehajtással. Az aktív georeplikáció létrehozásának részletes lépéseiért lásd: Aktív georeplikáció létrehozása és használata kivétellel a másodlagos adatbázis létrehozása a globális Azure-ban létrehozott másodlagos logikai kiszolgálón.

  • Ha a másodlagos adatbázis létezik a globális Azure-ban (az Azure Germany adatbázis online példányaként), az ügyfél az ALTER DATABASE T-SQL paranccsal kezdeményezhet adatbázis-feladatátvételt az Azure Germanyből a globális Azure-ba ehhez az adatbázishoz (lásd az alábbi táblázatot).

  • Ha a feladatátvétel után a másodlagos adatbázis elsődleges adatbázissá válik a globális Azure-ban, bármikor leállíthatja az aktív georeplikációt, és eltávolíthatja a másodlagos adatbázist az Azure Germany oldalán (lásd az alábbi táblázatot és a diagramon látható lépéseket).

  • A feladatátvételt követően az Azure Germany másodlagos adatbázisa a törlésig továbbra is költségekkel jár.

  • ALTER DATABASE Az paranccsal állíthat be aktív georeplikációt egy Azure Germany-adatbázis globális Azure-ba való migrálásához.

  • Nincs Azure Portal, Azure Resource Manager, PowerShell vagy parancssori felület az aktív georeplikáció konfigurálásához ehhez a migráláshoz.

Adatbázis migrálása az Azure Germanyből a globális Azure-ba:

  1. Válassza ki a felhasználói adatbázist az Azure Germanyben, például: azuregermanydb

  2. Hozzon létre egy logikai kiszolgálót a globális Azure-ban (a nyilvános felhőben), például globalazureserver: . Teljes tartományneve (FQDN) a .globalazureserver.database.windows.net

  3. Indítsa el az aktív georeplikációt az Azure Germanyből a globális Azure-ba a T-SQL-parancs végrehajtásával az Azure Germany kiszolgálóján. Vegye figyelembe, hogy a nyilvános kiszolgáló globalazureserver.database.windows.neta teljes DNS-nevet használja. Ez azt jelzi, hogy a célkiszolgáló a globális Azure-ban található, nem pedig az Azure Germanyben.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Ha a replikáció készen áll az írási-olvasási számítási feladat globális Azure-kiszolgálóra való áthelyezésére, hozzon létre egy tervezett feladatátvétel a globális Azure-ba a T-SQL-parancs globális Azure-kiszolgálón való végrehajtásával.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Az aktív georeplikációs kapcsolat a feladatátvételi folyamat előtt vagy után is megszakítható. A következő T-SQL-parancs végrehajtása a tervezett feladatátvétel után eltávolítja a globális Azure-beli adatbázissal rendelkező georeplikációs hivatkozást olvasási-írási másolatként. Az aktuális geo-elsődleges adatbázis logikai kiszolgálóján (azaz a globális Azure-kiszolgálón) kell futnia. Ezzel befejezi a migrálási folyamatot.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    A tervezett feladatátvétel előtt végrehajtott következő T-SQL-parancs szintén leállítja a migrálási folyamatot, de ebben az esetben az Azure Germany adatbázisa marad az olvasási-írási másolat. Ezt a T-SQL-parancsot az aktuális geo-elsődleges adatbázis logikai kiszolgálóján is futtatni kell, ebben az esetben az Azure Germany-kiszolgálón.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Az Azure SQL-adatbázisok Azure Germany-ből globális Azure-ba való migrálásának lépéseit is követhetjük aktív georeplikációval.

További információkért az alábbi táblázatok a feladatátvétel kezelésére szolgáló T-SQL-parancsokat jelzik. A következő parancsok támogatottak a felhők közötti aktív georeplikációhoz az Azure Germany és a globális Azure között:

Parancs Leírás
ALTER DATABASE Az ADD SECONDARY ON SERVER argumentum használata egy meglévő adatbázis másodlagos adatbázisának létrehozásához és az adatreplikálás indításához
ALTER DATABASE A FELADATÁTVÉTEL vagy a FORCE_FAILOVER_ALLOW_DATA_LOSS használatával másodlagos adatbázist válthat elsődleges adatbázisra a feladatátvétel kezdeményezéséhez
ALTER DATABASE A REMOVE SECONDARY ON SERVER paranccsel megszakíthatja az adatreplikálást egy SQL Database és a megadott másodlagos adatbázis között.

Aktív georeplikációs monitorozási rendszernézetek

Parancs Leírás
sys.geo_replication_links A Azure SQL adatbázis-kiszolgálón lévő összes meglévő replikációs hivatkozással kapcsolatos információt adja vissza.
sys.dm_geo_replication_link_status Lekéri az utolsó replikáció időpontját, az utolsó replikáció késését és az adott SQL-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 állapotát is.
sp_wait_for_database_copy_sync Az alkalmazás megvárja, amíg az aktív másodlagos adatbázis replikálja és nyugtázza az összes véglegesített tranzakciót.

SQL Database hosszú távú megőrzési biztonsági másolatok migrálása

A georeplikációval vagy BACPAC-fájllal rendelkező adatbázisok migrálása nem másolja át a hosszú távú megőrzési biztonsági másolatokat, amelyeket az adatbázis az Azure Germanyben tárolhat. A meglévő hosszú távú megőrzési biztonsági másolatok a cél globális Azure-régióba való migrálásához használhatja a HOSSZÚ TÁVÚ megőrzési biztonsági mentés másolása eljárást.

Megjegyzés

Az itt dokumentált LTR biztonsági mentési másolási módszerek csak az Azure Germany LTR biztonsági másolatait másolhatják a globális Azure-ba. A PITR biztonsági másolatok másolása ezekkel a módszerekkel nem támogatott.

Előfeltételek

  1. A céladatbázisnak, ahol az LTR biztonsági másolatokat másolja, a globális Azure-ban léteznie kell a biztonsági másolatok másolásának megkezdése előtt. Javasoljuk, hogy először telepítse át a forrásadatbázist aktív georeplikációval , majd kezdeményezze az LTR biztonsági mentési másolatát. Ez biztosítja, hogy az adatbázis biztonsági másolatai a megfelelő céladatbázisba legyenek másolva. Ez a lépés nem szükséges, ha egy elvetett adatbázis LTR biztonsági másolatait másolja át. Egy elvetett adatbázis LTR biztonsági másolatainak másolásakor a célrégióban létrejön egy nem megfelelő Adatbázis-azonosító.
  2. A PowerShell Az-modul telepítése
  3. Mielőtt hozzákezdene, győződjön meg arról, hogy a szükséges Azure RBAC-szerepkörökaz előfizetés vagy az erőforráscsoport hatókörében vannak megadva. Megjegyzés: Az elvetett kiszolgálóhoz tartozó LTR biztonsági másolatok eléréséhez az engedélyt az adott kiszolgáló előfizetési hatókörében kell megadni. .

Korlátozások

  • A feladatátvételi csoportok nem támogatottak. Ez azt jelenti, hogy az Azure Germany adatbázis(oka)t migráló ügyfeleknek maguknak kell kezelniük a kapcsolati sztringeket a feladatátvétel során.
  • A Azure Portal, az Azure Resource Manager API-k, a PowerShell vagy a parancssori felület nem támogatott. Ez azt jelenti, hogy minden Egyes Azure Germany-migrálásnak kezelnie kell az aktív georeplikáció beállítását és a T-SQL-en keresztüli feladatátvételt.
  • Az ügyfelek nem hozhatnak létre több földrajzilag másodlagos példányt a globális Azure-ban az Azure Germany adatbázisaihoz.
  • A másodlagos georeplikát az Azure Germany régióból kell elindítani.
  • Az ügyfelek csak a globális Azure-ba migrálhatnak adatbázisokat az Azure Germanyből. Jelenleg a felhők közötti migrálás nem támogatott.
  • Azure AD felhasználókat az Azure Germany felhasználói adatbázisai migrálják, de nem érhetők el az új Azure AD bérlőben, ahol az áttelepített adatbázis található. A felhasználók engedélyezéséhez manuálisan kell elvetni és újra létrehozni őket az új Azure AD bérlőben elérhető aktuális Azure AD felhasználókkal, ahol az újonnan migrált adatbázis található.

Hosszú távú megőrzési biztonsági másolatok másolása a PowerShell használatával

Bevezettük a Copy-AzSqlDatabaseLongTermRetentionBackup nevű új PowerShell-parancsot, amellyel a hosszú távú adatmegőrzési biztonsági másolatok az Azure Germanyből az Azure globális régióiba másolhatók.

  1. LTR biztonsági mentés másolása a biztonsági mentés nevével Az alábbi példa bemutatja, hogyan másolhat LTR biztonsági mentést az Azure Germanyből az Azure globális régióba a backupname használatával.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. LTR biztonsági mentés másolása a backup resourceID használatával Az alábbi példa bemutatja, hogyan másolhatja az LTR biztonsági mentést az Azure Germanyből az Azure globális régióba egy biztonsági mentési erőforrás-azonosító használatával. Ez a példa egy törölt adatbázis biztonsági másolatainak másolására is használható.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Korlátozások

  • Az időponthoz kötött visszaállítási (PITR) biztonsági mentések csak az elsődleges adatbázison készülnek, ez a terv szerint történik. Amikor georedundáns vészhelyreállítással migrálja az adatbázisokat az Azure Germanyből, a PITR biztonsági másolatai a feladatátvételt követően az új elsődleges helyen fognak elindulni. A meglévő PITR biztonsági másolatok (az Azure Germany előző elsődleges adatbázisában) azonban nem lesznek migrálva. Ha az időponthoz kötött visszaállítási forgatókönyvek támogatásához PITR biztonsági másolatokra van szüksége, az adatbázist a PITR biztonsági másolataiból kell visszaállítania az Azure Germanyben, majd át kell telepítenie a helyreállított adatbázist a globális Azure-ba.
  • A hosszú távú adatmegőrzési szabályzatok nem lesznek migrálva az adatbázissal. Ha hosszú távú adatmegőrzési (LTR) szabályzattal rendelkezik az Azure Germany adatbázisában, az áttelepítés után manuálisan át kell másolnia és újra létre kell hoznia az LTR-szabályzatot az új adatbázison.

Hozzáférés kérése

Ha georeplikációval szeretne migrálni egy adatbázist az Azure Germanyből a globális Azure-ba, az Azure Germany-előfizetését engedélyezni kell a felhők közötti migrálás sikeres konfigurálásához.

Az Azure Germany-előfizetés engedélyezéséhez az alábbi hivatkozásra kattintva kell létrehoznia egy migrálási támogatási kérést:

  1. Keresse meg a következő migrálási támogatási kérést.

  2. Az Alapok lapon összegzésként adja meg a Geo-DR migrálás kifejezést, majd válassza a Tovább: Megoldások lehetőséget.

    új támogatási kérelem űrlapja

  3. Tekintse át az ajánlott lépéseket, majd válassza a Tovább: Részletek lehetőséget.

    szükséges támogatási kérelem adatai

  4. A részletek lapon adja meg a következőket:

    1. A Leírás mezőben adja meg azt a globális Azure-előfizetés-azonosítót, amelybe migrálni szeretne. Ha több előfizetésbe szeretne adatbázisokat migrálni, adja hozzá azoknak a globális Azure-azonosítóknak a listáját, amelyeket át szeretne telepíteni az adatbázisokba.
    2. Adja meg a kapcsolattartási adatokat: név, cégnév, e-mail-cím vagy telefonszám.
    3. Töltse ki az űrlapot, majd válassza a Tovább: Áttekintés + létrehozás lehetőséget.

    támogatási kérelem részletei

  5. Tekintse át a támogatási kérést, majd válassza a Létrehozás lehetőséget.

A kérés feldolgozása után a rendszer felveszi Önnel a kapcsolatot.

Azure Cosmos DB

Az Azure Cosmos DB adatmigrálási eszköz használatával adatokat migrálhat az Azure Cosmos DB-be. Az Azure Cosmos DB adatmigrálási eszköz egy nyílt forráskódú megoldás, amely különböző forrásokból importál adatokat az Azure Cosmos DB-be, beleértve a JSON-fájlokat, a MongoDB-t, a SQL Server, a CSV-fájlokat, az Azure Table Storage-ot, az Amazon DynamoDB-t, a HBase-t és az Azure Cosmos-tárolókat.

Az Azure Cosmos DB adatmigrálási eszköze grafikus felületi eszközként vagy parancssori eszközként érhető el. A forráskód az Azure Cosmos DB Adatmigrálási eszköz GitHub-adattárában érhető el. Az eszköz lefordított verziója a Microsoft letöltőközpontban érhető el.

Az Azure Cosmos DB-erőforrások migrálásához javasoljuk, hogy hajtsa végre a következő lépéseket:

  1. Tekintse át az alkalmazás üzemidejének követelményeit és a fiókkonfigurációkat a legjobb műveleti terv meghatározásához.
  2. Klónozza a fiókkonfigurációkat az Azure Germanyből az új régióba az adatmigrálási eszköz futtatásával.
  3. Ha karbantartási időszak használata lehetséges, másolja az adatokat a forrásból a célhelyre az adatmigrálási eszköz futtatásával.
  4. Ha karbantartási időszak használata nem lehetséges, másolja az adatokat a forrásból a célhelyre az eszköz futtatásával, majd hajtsa végre az alábbi lépéseket:
    1. Konfigurációalapú megközelítéssel módosíthatja az alkalmazások olvasási/írási műveletét.
    2. Végezze el az első szinkronizálást.
    3. Növekményes szinkronizálás beállítása és a változáscsatorna felzárkóztatása.
    4. A pont beolvassa az új fiókot, és ellenőrzi az alkalmazást.
    5. Állítsa le a régi fiókba való írást, ellenőrizze, hogy a változáscsatorna be van-e állítva, majd mutasson az írásokra az új fiókra.
    6. Állítsa le az eszközt, és törölje a régi fiókot.
  5. Futtassa az eszközt annak ellenőrzéséhez, hogy az adatok konzisztensek-e a régi és az új fiókok között.

További információk:

Azure Cache for Redis

Ha egy Azure Cache for Redis-példányt szeretne migrálni az Azure Germanyből a globális Azure-ba, néhány lehetőség közül választhat. A választott lehetőség a követelményektől függ.

1. lehetőség: Adatvesztés elfogadása, új példány létrehozása

Ez a megközelítés akkor a legértelmesebb, ha az alábbi feltételek mindegyike teljesül:

  • A Azure Cache for Redis átmeneti adat-gyorsítótárként használja.
  • Az alkalmazás automatikusan újra feltölti a gyorsítótáradatokat az új régióban.

Adatvesztéssel történő migrálás és új példány létrehozása:

  1. Hozzon létre egy új Azure Cache for Redis példányt az új célrégióban.
  2. Frissítse az alkalmazást úgy, hogy az új példányt használja az új régióban.
  3. Törölje a régi Azure Cache for Redis példányt a forrásrégióban.

2. lehetőség: Adatok másolása a forráspéldányból a célpéldányba

A Azure Cache for Redis csapat egyik tagja írt egy nyílt forráskódú eszközt, amely importálási vagy exportálási funkció nélkül másol adatokat az egyik Azure Cache for Redis példányból egy másikba. Az eszközzel kapcsolatos információkért tekintse meg a 4. lépést a következő lépésekben.

Adatok másolása a forráspéldányból a célpéldányba:

  1. Hozzon létre egy virtuális gépet a forrásrégióban. Ha Azure Cache for Redis adatkészlete nagy, a másolási idő minimalizálása érdekében válasszon viszonylag nagy méretű virtuálisgép-méretet.
  2. Hozzon létre egy új Azure Cache for Redis példányt a célrégióban.
  3. Adatok kiürítése a célpéldányból . (Ügyeljen arra, hogy ne ürítse ki a forráspéldányt . Kiürítésre azért van szükség, mert a másolási eszköz nem írja felül a célhelyen található meglévő kulcsokat.)
  4. A következő eszközzel automatikusan átmásolhatja az adatokat a forrás Azure Cache for Redis példányról a cél Azure Cache for Redis példányra: Eszközforrás és eszköz letöltése.

Megjegyzés

Ez a folyamat az adathalmaz méretétől függően hosszú időt vehet igénybe.

3. lehetőség: Exportálás a forráspéldányból, importálás a célpéldányba

Ez a megközelítés kihasználja azokat a funkciókat, amelyek csak a Prémium szinten érhetők el.

Exportálás a forráspéldányból és importálás a célpéldányba:

  1. Hozzon létre egy új Prémium szintű Azure Cache for Redis-példányt a célrégióban. Használja ugyanazt a méretet, mint a forrás Azure Cache for Redis példány.

  2. Exportálja az adatokat a forrás-gyorsítótárból , vagy használja az Export-AzRedisCache PowerShell-parancsmagot.

    Megjegyzés

    Az Azure Storage-fiók exportálásának ugyanabban a régióban kell lennie, mint a gyorsítótárpéldánynak.

  3. Másolja az exportált blobokat a célrégió egyik tárfiókjába (például az AzCopy használatával).

  4. Importáljon adatokat a cél gyorsítótárba , vagy használja az Import-AzRedisCAche PowerShell-parancsmagot.

  5. Konfigurálja újra az alkalmazást a cél Azure Cache for Redis példány használatára.

4. lehetőség: Adatok írása két Azure Cache for Redis példányba, egy példányból beolvasva

Ehhez a módszerhez módosítania kell az alkalmazást. Az alkalmazásnak több gyorsítótárpéldányba kell adatokat írnia, miközben az egyik gyorsítótárpéldányból olvas. Ennek a megközelítésnek akkor van értelme, ha a Azure Cache for Redis tárolt adatok megfelelnek a következő feltételeknek:

  • Az adatok rendszeresen frissülnek.
  • A rendszer minden adatot a cél Azure Cache for Redis példányba ír.
  • Elegendő ideje van az összes adat frissítésére.

További információk:

PostgreSQL és MySQL

További információt a PostgreSQL és a MySQL "Adatok biztonsági mentése és migrálása" című szakaszában talál.

PostgreSQL és MySQL

Következő lépések

Megismerheti az erőforrások migrálásához szükséges eszközöket, technikákat és javaslatokat a következő szolgáltatáskategóriákban: