Share via

Flytta resurser till en ny region – Azure SQL Database och Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL DatabaseAzure SQL Managed Instance

I den här artikeln får du lära dig ett allmänt arbetsflöde för hur du flyttar databasen eller den hanterade instansen till en ny region.

Översikt

Det finns olika scenarier där du vill flytta din befintliga databas eller hanterade instans från en region till en annan. Du expanderar till exempel ditt företag till en ny region och vill optimera det för den nya kundbasen. Eller så måste du flytta åtgärderna till en annan region av efterlevnadsskäl. Eller så släppte Azure en ny region som ger en bättre närhet och förbättrar kundupplevelsen.

Den här artikeln innehåller ett allmänt arbetsflöde för att flytta resurser till en annan region. Arbetsflödet består av följande steg:

  1. Kontrollera förutsättningarna för flytten.
  2. Förbered för att flytta resurserna i omfånget.
  3. Övervaka förberedelseprocessen.
  4. Testa flyttprocessen.
  5. Initiera den faktiska flytten.
  6. Ta bort resurserna från källregionen.

Kommentar

Den här artikeln gäller migreringar i det offentliga Azure-molnet eller i samma nationella moln.

Kommentar

Om du vill flytta Azure SQL-databaser och elastiska pooler till en annan Azure-region kan du också använda Azure Resource Mover (rekommenderas). I den här självstudien finns detaljerade steg för att göra samma sak.

Kommentar

Den här artikeln använder Azure Az PowerShell-modulen, som är den rekommenderade PowerShell-modulen för interaktion med Azure. För att komma igång med Az PowerShell kan du läsa artikeln om att installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Flytta en databas

Verifiera kraven

  1. Skapa en målserver för varje källserver.

  2. Konfigurera brandväggen med rätt undantag med hjälp av PowerShell.

  3. Konfigurera servrarna med rätt inloggningar. Om du inte är prenumerationsadministratör eller SQL Server-administratör kan du kontakta administratören för att tilldela de behörigheter som du behöver. Mer information finns i Hantera Azure SQL Database-säkerhet efter haveriberedskap.

  4. Om dina databaser krypteras med transparent datakryptering (TDE) och tar med din egen krypteringsnyckel (BYOK eller kundhanterad nyckel) i Azure Key Vault kontrollerar du att rätt krypteringsmaterial etableras i målregionerna.

    • Det enklaste sättet att göra detta är att lägga till krypteringsnyckeln från det befintliga nyckelvalvet (som används som TDE-skydd på källservern) till målservern och sedan ange nyckeln som TDE-skydd på målservern

      Kommentar

      En server eller hanterad instans i en region kan nu anslutas till ett nyckelvalv i vilken annan region som helst.

    • Som bästa praxis för att säkerställa att målservern har åtkomst till äldre krypteringsnycklar (krävs för att återställa databassäkerhetskopior) kör du cmdleten Get-AzSqlServerKeyVaultKey på källservern eller Cmdleten Get-AzSqlInstanceKeyVaultKey på den källhanterade instansen för att returnera listan över tillgängliga nycklar och lägga till nycklarna på målservern.
    • Mer information och metodtips för att konfigurera kundhanterad TDE på målservern finns i Transparent datakryptering i Azure SQL med kundhanterade nycklar i Azure Key Vault.
    • Information om hur du flyttar nyckelvalvet till den nya regionen finns i Flytta ett Azure-nyckelvalv mellan regioner

  5. Om granskning på databasnivå är aktiverat inaktiverar du det och aktiverar granskning på servernivå i stället. Efter redundansväxlingen kräver granskning på databasnivå trafiken mellan regioner, vilket inte är önskvärt eller möjligt efter flytten.

  6. För granskningar på servernivå kontrollerar du att:

    • Lagringscontainern, Log Analytics eller händelsehubben med befintliga granskningsloggar flyttas till målregionen.
    • Granskning konfigureras på målservern. Mer information finns i Komma igång med SQL Database-granskning.

  7. Om din instans har en långsiktig kvarhållningsprincip (LTR) förblir de befintliga LTR-säkerhetskopiorna associerade med den aktuella servern. Eftersom målservern är annorlunda kan du komma åt de äldre LTR-säkerhetskopiorna i källregionen med hjälp av källservern, även om servern tas bort.

    Kommentar

    Detta är inte tillräckligt för att flytta mellan det nationella molnet och en offentlig region. En sådan migrering kräver att LTR-säkerhetskopiorna flyttas till målservern, som för närvarande inte stöds.

Förbereda resurser

  1. Skapa en redundansgrupp mellan källans server och målservern.

  2. Lägg till de databaser som du vill flytta till redundansgruppen.

    Replikering av alla tillagda databaser initieras automatiskt. Mer information finns i Använda redundansgrupper med SQL Database.

Övervaka förberedelseprocessen

Du kan regelbundet anropa Get-AzSqlDatabaseFailoverGroup för att övervaka replikering av dina databaser från källan till målet. Utdataobjektet Get-AzSqlDatabaseFailoverGroup för innehåller en egenskap för ReplicationState:

  • ReplicationState = 2 (CATCH_UP) anger att databasen är synkroniserad och kan redväxlades på ett säkert sätt.
  • ReplicationState = 0 (SEEDING) anger att databasen ännu inte är seedad och ett försök att redundansväxla misslyckas.

Testsynkronisering

När ReplicationState är 2ansluter du till varje databas eller delmängd av databaser med hjälp av den sekundära slutpunkten <fog-name>.secondary.database.windows.net och utför alla frågor mot databaserna för att säkerställa anslutning, korrekt säkerhetskonfiguration och datareplikering.

Initiera flytten

  1. Anslut till målservern med hjälp av den sekundära slutpunkten <fog-name>.secondary.database.windows.net.
  2. Använd Switch-AzSqlDatabaseFailoverGroup för att växla den sekundära hanterade instansen till att vara den primära med fullständig synkronisering. Åtgärden lyckas eller så återställs den.
  3. Kontrollera att kommandot har slutförts med hjälp nslook up <fog-name>.secondary.database.windows.net av för att kontrollera att DNS CNAME-startpunkterna till målregionens IP-adress. Om växelkommandot misslyckas uppdateras inte CNAME.

Ta bort källdatabaserna

När flytten är klar tar du bort resurserna i källregionen för att undvika onödiga avgifter.

  1. Ta bort redundansgruppen med Remove-AzSqlDatabaseFailoverGroup.
  2. Ta bort varje källdatabas med Remove-AzSqlDatabase för var och en av databaserna på källservern. Detta avslutar automatiskt geo-replikeringslänkar.
  3. Ta bort källservern med Remove-AzSqlServer.
  4. Ta bort nyckelvalvet, granskningslagringscontainrar, händelsehubben, Microsoft Entra-instansen och andra beroende resurser för att sluta faktureras för dem.

Flytta elastiska pooler

Verifiera kraven

  1. Skapa en målserver för varje källserver.

  2. Konfigurera brandväggen med rätt undantag med hjälp av PowerShell.

  3. Konfigurera servrarna med rätt inloggningar. Om du inte är prenumerationsadministratör eller serveradministratör arbetar du med administratören för att tilldela de behörigheter som du behöver. Mer information finns i Hantera Azure SQL Database-säkerhet efter haveriberedskap.

  4. Om dina databaser krypteras med transparent datakryptering och använder din egen krypteringsnyckel i Azure Key Vault kontrollerar du att rätt krypteringsmaterial etableras i målregionen.

  5. Skapa en elastisk målpool för varje elastisk källpool och se till att poolen skapas på samma tjänstnivå, med samma namn och samma storlek.

  6. Om en granskning på databasnivå är aktiverad inaktiverar du den och aktiverar granskning på servernivå i stället. Efter redundansväxlingen kräver granskning på databasnivå trafik mellan regioner, vilket inte är önskat eller möjligt efter flytten.

  7. För granskningar på servernivå kontrollerar du att:

    • Lagringscontainern, Log Analytics eller händelsehubben med befintliga granskningsloggar flyttas till målregionen.
    • Granskningskonfigurationen konfigureras på målservern. Mer information finns i SQL Database-granskning.

  8. Om din instans har en långsiktig kvarhållningsprincip (LTR) förblir de befintliga LTR-säkerhetskopiorna associerade med den aktuella servern. Eftersom målservern är annorlunda kan du komma åt de äldre LTR-säkerhetskopiorna i källregionen med hjälp av källservern, även om servern tas bort.

    Kommentar

    Detta är inte tillräckligt för att flytta mellan det nationella molnet och en offentlig region. En sådan migrering kräver att LTR-säkerhetskopiorna flyttas till målservern, som för närvarande inte stöds.

Förbered för flytt

  1. Skapa en separat redundansgrupp mellan varje elastisk pool på källservern och dess elastiska motsvarighetpool på målservern.

  2. Lägg till alla databaser i poolen i redundansgruppen.

    Replikering av de tillagda databaserna initieras automatiskt. Mer information finns i Använda redundansgrupper med SQL Database.

    Kommentar

    Även om det är möjligt att skapa en redundansgrupp som innehåller flera elastiska pooler rekommenderar vi starkt att du skapar en separat redundansgrupp för varje pool. Om du har ett stort antal databaser över flera elastiska pooler som du behöver flytta kan du köra förberedelsestegen parallellt och sedan initiera flyttsteget parallellt. Den här processen skalas bättre och tar mindre tid jämfört med att ha flera elastiska pooler i samma redundansgrupp.

Övervaka förberedelseprocessen

Du kan regelbundet anropa Get-AzSqlDatabaseFailoverGroup för att övervaka replikering av dina databaser från källan till målet. Utdataobjektet Get-AzSqlDatabaseFailoverGroup för innehåller en egenskap för ReplicationState:

  • ReplicationState = 2 (CATCH_UP) anger att databasen är synkroniserad och kan redväxlades på ett säkert sätt.
  • ReplicationState = 0 (SEEDING) anger att databasen ännu inte är seedad och ett försök att redundansväxla misslyckas.

Testsynkronisering

När ReplicationState är 2ansluter du till varje databas eller delmängd av databaser med hjälp av den sekundära slutpunkten <fog-name>.secondary.database.windows.net och utför alla frågor mot databaserna för att säkerställa anslutning, korrekt säkerhetskonfiguration och datareplikering.

Initiera flytten

  1. Anslut till målservern med hjälp av den sekundära slutpunkten <fog-name>.secondary.database.windows.net.
  2. Använd Switch-AzSqlDatabaseFailoverGroup för att växla den sekundära hanterade instansen till att vara den primära med fullständig synkronisering. Den här åtgärden lyckas eller så återställs den.
  3. Kontrollera att kommandot har slutförts med hjälp nslook up <fog-name>.secondary.database.windows.net av för att kontrollera att DNS CNAME-startpunkterna till målregionens IP-adress. Om växelkommandot misslyckas uppdateras inte CNAME.

Ta bort elastiska källpooler

När flytten är klar tar du bort resurserna i källregionen för att undvika onödiga avgifter.

  1. Ta bort redundansgruppen med Remove-AzSqlDatabaseFailoverGroup.
  2. Ta bort varje elastisk källpool på källservern med Remove-AzSqlElasticPool.
  3. Ta bort källservern med Remove-AzSqlServer.
  4. Ta bort nyckelvalvet, granskningslagringscontainrar, händelsehubben, Microsoft Entra-klientorganisationen och andra beroende resurser för att sluta faktureras för dem.

Flytta en hanterad instans

Verifiera kraven

  1. För varje källhanterad instans skapar du en målinstans av SQL Managed Instance av samma storlek i målregionen.
  2. Konfigurera nätverket för en hanterad instans. Mer information finns i Nätverkskonfiguration.
  3. Konfigurera måldatabasen master med rätt inloggningar. Om du inte är prenumerations- eller SQL Managed Instance-administratör kan du kontakta administratören för att tilldela de behörigheter som du behöver.
  4. Om dina databaser krypteras med transparent datakryptering och använder din egen krypteringsnyckel i Azure Key Vault kontrollerar du att Azure Key Vault med identiska krypteringsnycklar finns i både käll- och målregioner. Mer information finns i Transparent datakryptering med kundhanterade nycklar i Azure Key Vault.
  5. Om granskning är aktiverat för den hanterade instansen kontrollerar du att:
    • Lagringscontainern eller händelsehubben med befintliga loggar flyttas till målregionen.
    • Granskning konfigureras på målinstansen. Mer information finns i Granskning med SQL Managed Instance.
  6. Om din instans har en långsiktig kvarhållningsprincip (LTR) förblir de befintliga LTR-säkerhetskopiorna associerade med den aktuella instansen. Eftersom målinstansen är annorlunda kan du komma åt de äldre LTR-säkerhetskopiorna i källregionen med hjälp av källinstansen, även om instansen tas bort.

Kommentar

Detta är inte tillräckligt för att flytta mellan det nationella molnet och en offentlig region. En sådan migrering kräver att LTR-säkerhetskopiorna flyttas till målinstansen, som för närvarande inte stöds.

Förbereda resurser

Skapa en redundansgrupp mellan varje källhanterad instans och motsvarande målinstans för SQL Managed Instance.

Replikering av alla databaser på varje instans initieras automatiskt. Mer information finns i Redundansgrupper.

Övervaka förberedelseprocessen

Du kan regelbundet anropa Get-AzSqlDatabaseInstanceFailoverGroup för att övervaka replikeringen av dina databaser från källan till målet. Utdataobjektet Get-AzSqlDatabaseInstanceFailoverGroup för innehåller en egenskap för ReplicationState:

  • ReplicationState = CATCH_UP anger att databasen är synkroniserad och kan redväxlades på ett säkert sätt.
  • ReplicationState = SEEDING anger att databasen ännu inte är seedad, och ett försök att redundansväxla misslyckas.

Testsynkronisering

När ReplicationState är CATCH_UPansluter du till den geo-sekundära med hjälp av den sekundära slutpunkten <fog-name>.secondary.<zone_id>.database.windows.net och utför alla frågor mot databaserna för att säkerställa anslutning, korrekt säkerhetskonfiguration och datareplikering.

Initiera flytten

  1. Anslut till den hanterade målinstansen med hjälp av den sekundära slutpunkten <fog-name>.secondary.<zone_id>.database.windows.net.
  2. Använd Switch-AzSqlDatabaseInstanceFailoverGroup för att växla den sekundära hanterade instansen till att vara den primära med fullständig synkronisering. Den här åtgärden lyckas eller så återställs den.
  3. Kontrollera att kommandot har slutförts med hjälp nslook up <fog-name>.secondary.<zone_id>.database.windows.net av för att kontrollera att DNS CNAME-startpunkterna till målregionens IP-adress. Om växelkommandot misslyckas uppdateras inte CNAME.

Ta bort källhanterade instanser

När flytten är klar tar du bort resurserna i källregionen för att undvika onödiga avgifter.

  1. Ta bort redundansgruppen med Remove-AzSqlDatabaseInstanceFailoverGroup. Då tas konfigurationen av redundansgruppen bort och geo-replikeringslänkarna avslutas mellan de två instanserna.
  2. Ta bort den källhanterade instansen med Remove-AzSqlInstance.
  3. Ta bort eventuella ytterligare resurser i resursgruppen, till exempel det virtuella nätverket och säkerhetsgruppen.

Nästa steg

Hantera databasen när den har migrerats.