Migrera databasresurser till globala Azure

  • Artikel

Viktigt

Sedan augusti 2018 har vi inte tagit emot nya kunder eller distribuerat några nya funktioner och tjänster till de ursprungliga Platserna i Microsoft Cloud Tyskland.

Baserat på utvecklingen av kundernas behov lanserade vi nyligen två nya datacenterregioner i Tyskland, som erbjuder kunddatahemvist, fullständig anslutning till Microsofts globala molnnätverk samt konkurrenskraftiga priser på marknaden.

Den 30 september 2020 meddelade vi dessutom att Microsoft Cloud Germany stänger den 29 oktober 2021. Mer information finns här: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Dra nytta av bredden av funktioner, säkerhet i företagsklass och omfattande funktioner som är tillgängliga i våra nya tyska datacenterregioner genom att migrera i dag.

Den här artikeln innehåller information som kan hjälpa dig att migrera Azure-databasresurser från Azure Tyskland till globala Azure.

SQL Database

Om du vill migrera mindre Azure SQL Database-arbetsbelastningar utan att hålla den migrerade databasen online använder du exportfunktionen för att skapa en BACPAC-fil. En BACPAC-fil är en komprimerad (zippad) fil som innehåller metadata och data från den SQL Server databasen. När du har skapat BACPAC-filen kan du kopiera filen till målmiljön (till exempel genom att använda AzCopy) och använda importfunktionen för att återskapa databasen. Tänk på följande:

  • För att en export ska vara transaktionsmässigt konsekvent kontrollerar du att något av följande villkor är sant:
    • Ingen skrivaktivitet inträffar under exporten.
    • Du exporterar från en transaktionsmässigt konsekvent kopia av din SQL-databas.
  • Om du vill exportera till Azure Blob Storage är BACPAC-filstorleken begränsad till 200 GB. Exportera till lokal lagring för en större BACPAC-fil.
  • Om exportåtgärden från SQL Database tar längre tid än 20 timmar kan åtgärden avbrytas. I följande artiklar finns tips om hur du ökar prestandan.

Anteckning

Anslutningssträng ändras efter exportåtgärden eftersom DNS-namnet på servern ändras under exporten.

Mer information:

Anteckning

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Migrera SQL Database med aktiv geo-replikering

För databaser som är för stora för BACPAC-filer, eller för att migrera från ett moln till ett annat och vara online med minimal stilleståndstid, kan du konfigurera aktiv geo-replikering från Azure Tyskland till globala Azure.

Viktigt

Du kan bara konfigurera aktiv geo-replikering för att migrera databaser till globala Azure med Hjälp av Transact-SQL (T-SQL), och innan du migrerar måste du begära aktivering av prenumerationen för att stödja migrering till globala Azure. Om du vill skicka en begäran måste du använda den här länken för supportbegäran.

Anteckning

Globala Azure-molnregioner, Tyskland, västra centrala och Tyskland, norra, är de regioner som stöds för aktiv geo-replikering med Azure Tyskland-molnet. Om en alternativ global Azure-region önskas som slutdatabas(er) är rekommendationen efter slutförandet av migreringen till globala Azure att konfigurera ytterligare en geo-replikeringslänk från Tyskland, västra centrala eller Tyskland, norra till den nödvändiga globala Azure-molnregionen.

Mer information om aktiva kostnader för geo-replikering finns i avsnittet Active geo-replication in Azure SQL Database pricing (Priser för aktiv geo-replikering i Azure SQL Database).

Migrering av databaser med aktiv geo-replikering kräver en Azure SQL logisk server i globala Azure. Du kan skapa servern med hjälp av portalen, Azure PowerShell, Azure CLI osv., men att konfigurera aktiv geo-replikering för att migrera från Azure Tyskland till globala Azure stöds bara med Hjälp av Transact-SQL (T-SQL).

Viktigt

Vid migrering mellan moln måste de primära (Azure Tyskland) och sekundära (globala Azure)-servernamnsprefixen vara olika. Om servernamnen är desamma kommer alter database-instruktionen att köras, men migreringen misslyckas. Om prefixet för det primära servernamnet till exempel är myserver (myserver.database.cloudapi.de) kan prefixet för det sekundära servernamnet i globala Azure inte vara myserver.

Med instruktionen ALTER DATABASE kan du ange en målserver i globala Azure med hjälp av dess fullständigt kvalificerade DNS-servernamn på målsidan.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbrepresenterar databasnamnet på en Azure SQL-server i Azure Tyskland.
  • public-server.database.windows.netrepresenterar det Azure SQL servernamnet som finns i globala Azure, där databasen ska migreras. Namnområdet "database.windows.net" krävs. Ersätt public-server med namnet på din logiska SQL-server i globala Azure. Servern i globala Azure måste ha ett annat namn än den primära servern i Azure Tyskland.

Kommandot körs på huvuddatabasen på Den Azure Tyskland-server som är värd för den lokala databasen som ska migreras.

  • T-SQL start-copy-API:et autentiserar den inloggade användaren på den offentliga molnservern genom att hitta en användare med samma SQL-inloggning/användarnamn i huvuddatabasen på den servern. Den här metoden är molnagnostisk. Därför används T-SQL-API:et för att starta kopior mellan moln. Behörigheter och mer information om det här avsnittet finns i Skapa och använda aktiv geo-replikering och ALTER DATABASE (Transact-SQL).

  • Förutom det första T-SQL-kommandotillägget som anger en Azure SQL logisk server i globala Azure, är resten av den aktiva geo-replikeringsprocessen identisk med den befintliga körningen i det lokala molnet. Detaljerade anvisningar för att skapa aktiv geo-replikering finns i Skapa och använda aktiv geo-replikering med ett undantag den sekundära databasen skapas i den sekundära logiska servern som skapats i globala Azure.

  • När den sekundära databasen finns i globala Azure (som sin onlinekopia av Azure Tyskland-databasen) kan kunden initiera en databasredundans från Azure Tyskland till globala Azure för den här databasen med hjälp av T-SQL-kommandot ALTER DATABASE (se tabellen nedan).

  • Efter redundansväxlingen kan du när som helst stoppa den aktiva geo-replikeringen och ta bort den sekundära databasen på Azure Tyskland-sidan när som helst (se tabellen nedan och stegen i diagrammet).

  • Efter redundansväxlingen fortsätter den sekundära databasen i Azure Tyskland att medföra kostnader tills den tas bort.

  • ALTER DATABASE Att använda kommandot är det enda sättet att konfigurera aktiv geo-replikering för att migrera en Azure Tyskland-databas till globala Azure.

  • Det finns inga Azure Portal, Azure Resource Manager, PowerShell eller CLI tillgängliga för att konfigurera aktiv geo-replikering för den här migreringen.

Så här migrerar du en databas från Azure Tyskland till globala Azure:

  1. Välj användardatabasen i Azure Tyskland, till exempel azuregermanydb

  2. Skapa en logisk server i globala Azure (det offentliga molnet), till exempel globalazureserver. Dess fullständigt kvalificerade domännamn (FQDN) är globalazureserver.database.windows.net.

  3. Starta aktiv geo-replikering från Azure Tyskland till globala Azure genom att köra det här T-SQL-kommandot på servern i Azure Tyskland. Observera att det fullständigt kvalificerade DNS-namnet används för den offentliga servern globalazureserver.database.windows.net. Detta är för att indikera att målservern finns i globala Azure, inte Azure Tyskland.

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

  4. När replikeringen är redo att flytta läs- och skrivarbetsbelastningen till den globala Azure-servern initierar du en planerad felövergång till globala Azure genom att köra det här T-SQL-kommandot på den globala Azure-servern.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Den aktiva geo-replikeringslänken kan avslutas före eller efter redundansväxlingen. Om du kör följande T-SQL-kommando efter planerad felövergång tar bort geo-replikeringslänken med databasen i globala Azure som skrivskyddad kopia. Den bör köras på den aktuella geo-primära databasens logiska server (dvs. på den globala Azure-servern). Detta slutför migreringsprocessen.

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

    Följande T-SQL-kommando när det körs innan planerad felövergång stoppar också migreringsprocessen, men i den här situationen förblir databasen i Azure Tyskland skrivskyddad kopia. Det här T-SQL-kommandot bör också köras på den aktuella geo-primära databasens logiska server, i det här fallet på Azure Germany-servern.

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

De här stegen för att migrera Azure SQL databaser från Azure Tyskland till globala Azure kan också följas med hjälp av aktiv geo-replikering.

Mer information finns i följande tabeller nedan anger T-SQL-kommandon för att hantera redundans. Följande kommandon stöds för aktiv geo-replikering mellan moln mellan Azure Tyskland och globala Azure:

Kommando Beskrivning
ALTER DATABASE Använd argumentet ADD SECONDARY ON SERVER (LÄGG TILL SEKUNDÄR PÅ SERVER) för att skapa en sekundär databas för en befintlig databas och starta datareplikering
ALTER DATABASE Använd REDUNDans eller FORCE_FAILOVER_ALLOW_DATA_LOSS för att växla en sekundär databas till att vara primär för att initiera redundans
ALTER DATABASE Använd REMOVE SECONDARY ON SERVER för att avsluta en datareplikering mellan en SQL Database och den angivna sekundära databasen.

Övervakningssystemvyer för aktiv geo-replikering

Kommando Beskrivning
sys.geo_replication_links Returnerar information om alla befintliga replikeringslänkar för varje databas på Azure SQL Database-servern.
sys.dm_geo_replication_link_status Hämtar den senaste replikeringstiden, den senaste replikeringsfördröjningen och annan information om replikeringslänken för en viss SQL-databas.
sys.dm_operation_status Visar status för alla databasåtgärder, inklusive status för replikeringslänkarna.
sp_wait_for_database_copy_sync Gör att programmet väntar tills alla bekräftade transaktioner replikeras och bekräftas av den aktiva sekundära databasen.

Migrera SQL Database säkerhetskopior av långsiktig kvarhållning

Migrering av en databas med geo-replikering eller BACPAC-fil kopieras inte över de långsiktiga kvarhållningssäkerhetskopieringar som databasen kan ha i Azure Tyskland. Om du vill migrera befintliga säkerhetskopior av långsiktig kvarhållning till den globala Azure-målregionen kan du använda proceduren KOPIERA långsiktig säkerhetskopiering av kvarhållning.

Anteckning

Metoder för LTR-säkerhetskopieringskopiering som dokumenteras här kan bara kopiera LTR-säkerhetskopiorna från Azure Tyskland till globala Azure. Kopiering av PITR-säkerhetskopior med dessa metoder stöds inte.

Förutsättningar

  1. Måldatabas där du kopierar LTR-säkerhetskopiorna, i globala Azure måste finnas innan du börjar kopiera säkerhetskopiorna. Vi rekommenderar att du först migrerar källdatabasen med aktiv geo-replikering och sedan initierar säkerhetskopian av LTR. Detta säkerställer att databassäkerhetskopiorna kopieras till rätt måldatabas. Det här steget krävs inte om du kopierar över LTR-säkerhetskopior av en borttagen databas. När du kopierar LTR-säkerhetskopior av en borttagen databas skapas ett dummy-DatabaseID i målregionen.
  2. Installera den här PowerShell Az-modulen
  3. Innan du börjar måste du se till att nödvändiga Azure RBAC-roller beviljas i prenumerations - eller resursgruppsomfånget . Obs! För att få åtkomst till LTR-säkerhetskopior som tillhör en borttagen server måste behörigheten beviljas i serverns prenumerationsomfång. .

Begränsningar

  • Redundansgrupper stöds inte. Det innebär att kunder som migrerar Azure Germany-databaser måste hantera anslutningssträngar själva under redundansväxlingen.
  • Inget stöd för Azure Portal, Azure Resource Manager-API:er, PowerShell eller CLI. Det innebär att varje Azure Tyskland-migrering måste hantera aktiv geo-replikeringskonfiguration och redundans via T-SQL.
  • Kunder kan inte skapa flera geo-sekundärfiler i globala Azure för databaser i Azure Tyskland.
  • Skapandet av en geo-sekundär måste initieras från Azure Tyskland-regionen.
  • Kunder kan bara migrera databaser från Azure Tyskland till globala Azure. För närvarande stöds ingen annan migrering mellan moln.
  • Azure AD användare i Azure Tyskland-användardatabaser migreras men är inte tillgängliga i den nya Azure AD klientorganisation där den migrerade databasen finns. Om du vill aktivera dessa användare måste de tas bort och återskapas manuellt med hjälp av den aktuella Azure AD användare som är tillgängliga i den nya Azure AD klientorganisationen där den nyligen migrerade databasen finns.

Kopiera säkerhetskopior av långsiktig kvarhållning med PowerShell

Ett nytt PowerShell-kommando Copy-AzSqlDatabaseLongTermRetentionBackup har introducerats, som kan användas för att kopiera säkerhetskopior av långsiktig kvarhållning från Azure Tyskland till globala Azure-regioner.

  1. Kopiera LTR-säkerhetskopiering med hjälp av säkerhetskopieringsnamn I följande exempel visas hur du kan kopiera en LTR-säkerhetskopia från Azure Tyskland till en global Azure-region med hjälp av säkerhetskopieringsnamnet.
# 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. Kopiera LTR-säkerhetskopiering med hjälp av resurs-ID för säkerhetskopiering I följande exempel visas hur du kan kopiera LTR-säkerhetskopiering från Azure Tyskland till en global Azure-region med hjälp av ett resurs-ID för säkerhetskopiering. Det här exemplet kan även användas för att kopiera säkerhetskopior av en borttagen databas.
$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

Begränsningar

  • Säkerhetskopieringar för återställning till tidpunkt (PITR) görs bara på den primära databasen, vilket är avsiktligt. När du migrerar databaser från Azure Tyskland med Geo-DR börjar PITR-säkerhetskopieringar ske på den nya primära databasen efter redundansväxlingen. De befintliga PITR-säkerhetskopiorna (på den tidigare primära i Azure Tyskland) migreras dock inte. Om du behöver PITR-säkerhetskopior för att stödja återställning till tidpunkt måste du återställa databasen från PITR-säkerhetskopior i Azure Tyskland och sedan migrera den återställda databasen till globala Azure.
  • Principer för långsiktig kvarhållning migreras inte med databasen. Om du har en princip för långsiktig kvarhållning (LTR) på databasen i Azure Tyskland måste du manuellt kopiera och återskapa LTR-principen på den nya databasen efter migreringen.

Begära åtkomst

Om du vill migrera en databas från Azure Tyskland till globala Azure med hjälp av geo-replikering måste din prenumeration i Azure Tyskland vara aktiverad för att kunna konfigurera migreringen mellan moln.

Om du vill aktivera din Azure Tyskland-prenumeration måste du använda följande länk för att skapa en migreringssupportbegäran:

  1. Bläddra till följande supportbegäran för migrering.

  2. På fliken Grundläggande anger du Geo-DR-migrering som Sammanfattning och väljer sedan Nästa: Lösningar

    nytt formulär för supportbegäran

  3. Granska de rekommenderade stegen och välj sedan Nästa: Information.

    nödvändig information om supportbegäran

  4. Ange följande på informationssidan:

    1. I rutan Beskrivning anger du det globala Azure-prenumerations-ID som du vill migrera till. Om du vill migrera databaser till mer än en prenumeration lägger du till en lista över de globala Azure-ID:t som du vill migrera databaser till.
    2. Ange kontaktuppgifter: namn, företagsnamn, e-post eller telefonnummer.
    3. Fyll i formuläret och välj sedan Nästa: Granska + skapa.

    information om supportbegäran

  5. Granska supportbegäran och välj sedan Skapa.

Du kontaktas när begäran har bearbetats.

Azure Cosmos DB

Du kan använda datamigreringsverktyget i Azure Cosmos DB för att migrera data till Azure Cosmos DB. Datamigreringsverktyget i Azure Cosmos DB är en lösning med öppen källkod som importerar data till Azure Cosmos DB från olika källor, inklusive: JSON-filer, MongoDB, SQL Server, CSV-filer, Azure Table Storage, Amazon DynamoDB, HBase och Azure Cosmos-containrar.

Datamigreringsverktyget i Azure Cosmos DB är tillgängligt som ett grafiskt gränssnittsverktyg eller som kommandoradsverktyg. Källkoden är tillgänglig på GitHub-lagringsplatsen för Azure Cosmos DB-datamigreringsverktyget . En kompilerad version av verktyget finns i Microsoft Download Center.

Om du vill migrera Azure Cosmos DB-resurser rekommenderar vi att du utför följande steg:

  1. Granska kraven på programtid och kontokonfigurationer för att fastställa den bästa åtgärdsplanen.
  2. Klona kontokonfigurationerna från Azure Tyskland till den nya regionen genom att köra datamigreringsverktyget.
  3. Om du kan använda en underhållsperiod kopierar du data från källan till målet genom att köra datamigreringsverktyget.
  4. Om det inte är ett alternativ att använda en underhållsperiod kopierar du data från källan till målet genom att köra verktyget och utför sedan följande steg:
    1. Använd en konfigurationsdriven metod för att göra ändringar i läsning/skrivning i ett program.
    2. Slutför en första synkronisering.
    3. Konfigurera en inkrementell synkronisering och kom ikapp ändringsflödet.
    4. Peka läsningar till det nya kontot och verifiera programmet.
    5. Stoppa skrivningar till det gamla kontot, kontrollera att ändringsflödet har fastnat och peka sedan skrivningar till det nya kontot.
    6. Stoppa verktyget och ta bort det gamla kontot.
  5. Kör verktyget för att verifiera att data är konsekventa för gamla och nya konton.

Mer information:

Azure Cache for Redis

Du har några alternativ om du vill migrera en Azure Cache for Redis instans från Azure Tyskland till globala Azure. Vilket alternativ du väljer beror på dina krav.

Alternativ 1: Acceptera dataförlust, skapa en ny instans

Den här metoden passar bäst när båda följande villkor är uppfyllda:

  • Du använder Azure Cache for Redis som en tillfällig datacache.
  • Ditt program fyller automatiskt i cachedata i den nya regionen.

Så här migrerar du med dataförlust och skapar en ny instans:

  1. Skapa en ny Azure Cache for Redis instans i den nya målregionen.
  2. Uppdatera programmet så att det använder den nya instansen i den nya regionen.
  3. Ta bort den gamla Azure Cache for Redis-instansen i källregionen.

Alternativ 2: Kopiera data från källinstansen till målinstansen

En medlem i Azure Cache for Redis-teamet skrev ett verktyg med öppen källkod som kopierar data från en Azure Cache for Redis instans till en annan utan import- eller exportfunktioner. Se steg 4 i följande steg för information om verktyget.

Så här kopierar du data från källinstansen till målinstansen:

  1. Skapa en virtuell dator i källregionen. Om datauppsättningen i Azure Cache for Redis är stor bör du se till att välja en relativt kraftfull VM-storlek för att minimera kopieringstiden.
  2. Skapa en ny Azure Cache for Redis instans i målregionen.
  3. Rensa data från målinstansen . (Se till att inte tömma från källinstansen . Tömning krävs eftersom kopieringsverktyget inte skriver över befintliga nycklar på målplatsen.)
  4. Använd följande verktyg för att automatiskt kopiera data från källinstansen Azure Cache for Redis till målinstansen Azure Cache for Redis: Verktygskälla och verktygsnedladdning.

Anteckning

Den här processen kan ta lång tid beroende på storleken på din datauppsättning.

Alternativ 3: Exportera från källinstansen, importera till målinstansen

Den här metoden drar nytta av funktioner som endast är tillgängliga på Premium-nivån.

Så här exporterar du från källinstansen och importerar till målinstansen:

  1. Skapa en ny Premium-nivå Azure Cache for Redis instans i målregionen. Använd samma storlek som källan Azure Cache for Redis instans.

  2. Exportera data från källcachen eller använd PowerShell-cmdleten Export-AzRedisCache.

    Anteckning

    Azure Storage-exportkontot måste finnas i samma region som cacheinstansen.

  3. Kopiera de exporterade blobarna till ett lagringskonto i målregionen (till exempel med hjälp av AzCopy).

  4. Importera data till målcachen eller använd PowerShell-cmdleten Import-AzRedisCAche.

  5. Konfigurera om programmet så att det använder målinstansen Azure Cache for Redis.

Alternativ 4: Skriva data till två Azure Cache for Redis instanser, läsa från en instans

För den här metoden måste du ändra ditt program. Programmet måste skriva data till mer än en cacheinstans medan du läser från en av cacheinstanserna. Den här metoden är lämplig om data som lagras i Azure Cache for Redis uppfyller följande kriterier:

  • Data uppdateras regelbundet.
  • Alla data skrivs till målet Azure Cache for Redis instans.
  • Du har tillräckligt med tid för att uppdatera alla data.

Mer information:

PostgreSQL och MySQL

Mer information finns i artiklarna i avsnittet "Säkerhetskopiera och migrera data" i PostgreSQL och MySQL.

PostgreSQL och MySQL

Nästa steg

Lär dig mer om verktyg, tekniker och rekommendationer för migrering av resurser i följande tjänstkategorier: