Migrera Azure SQL Database till stöd för tillgänglighetszoner

Den här guiden beskriver hur du migrerar Azure SQL Database från stöd för icke-tillgänglighetszoner till tillgänglighetssupport.

Om du aktiverar zonredundans för Azure SQL Database garanteras hög tillgänglighet eftersom databasen använder Azure Tillgänglighetszoner för att replikera data över flera fysiska platser i en Azure-region. Genom att välja zonredundans kan du göra dina databaser och elastiska pooler motståndskraftiga mot en större uppsättning fel, till exempel oåterkalleliga datacenterfel, utan några ändringar i programlogik.

Förutsättningar

Innan du migrerar till stöd för tillgänglighetszoner läser du följande tabell för att se till att din Azure SQL Database finns på en tjänstnivå och distributionsmodell som stöds. Kontrollera att din nivå och modell erbjuds i en region som stöder tillgänglighetszoner.

Tjänstenivå	Distributionsmodell	Tillgänglighet för zonredundans
Premium	Enkel databas eller elastisk pool	Alla regioner som stöder tillgänglighetszoner
Affärskritisk	Enkel databas eller elastisk pool	Alla regioner som stöder tillgänglighetszoner
Generell användning	Enkel databas eller elastisk pool	Valda regioner som stöder tillgänglighetszoner
Hyperskala	Enkel databas	Alla regioner som stöder tillgänglighetszoner

Krav på stilleståndstid

Migrering för Premium, Affärskritisk och Generell användning tjänstnivå är en onlineåtgärd med en kort frånkoppling mot slutet för att slutföra migreringsprocessen. Om du har implementerat omprövningslogik för tillfälliga standardfel kommer du inte att märka redundansväxlingen.

För tjänstnivån Hyperskala kan stöd för zonredundans endast anges när databasen skapas och kan inte ändras när resursen har etablerats. Om du vill gå över till stöd för tillgänglighetszoner måste du överföra data med databaskopiering, återställning till tidpunkt eller geo-replik. Om måldatabasen finns i en annan region än källan eller om redundansen för lagring av databassäkerhetskopiering för målet skiljer sig från källdatabasen är stilleståndstiden proportionell mot dataåtgärdens storlek.

Migrering (Premium, Affärskritisk och Generell användning)

För tjänstnivåerna Premium, Affärskritisk och Generell användning är det möjligt att migrera till zonredundans.

Följ stegen nedan för att utföra migrering för en enskild databas eller en elastisk pool.

Migrera en enskild databas

Azure-portalen

1. Gå till Azure Portal för att hitta databasen. Sök efter och välj SQL-databaser.

2. Välj den databas som du vill migrera.

3. Under Inställningar väljer du Beräkning + lagring.

4. Välj Ja för Vill du göra databaszonen redundant?

5. Välj Använd.

6. Vänta med att få ett meddelande om att åtgärden har slutförts i Meddelanden på den översta menyn i Azure Portal.

7. Om du vill kontrollera att zonredundans är aktiverat väljer du Översikt och sedan Egenskaper.

8. Under avsnittet Tillgänglighet kontrollerar du att zonredundans har angetts till Aktiverad.

PowerShell

Öppna PowerShell som administratör och kör följande kommando (ersätt platshållarna i "<>" med dina resursnamn). Observera att <server_name> inte bör innehålla .database.windows.net.

Connect-AzAccount
$subscriptionid = <'your subscription id here'>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    DatabaseName = '<Database_Name>'
}
Set-AzSqlDatabase @parameters -ZoneRedundant 

Azure CLI

Använd Azure CLI för att köra följande kommando (ersätt platshållarna i "<>" med dina resursnamn):

    az sql db update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Database_Name>” --zone-redundant 

ARM

Information om hur du aktiverar zonredundans finns i Databaser – Skapa eller uppdatera i ARM och använd properties.zoneRedundant egenskapen .

Migrera en elastisk pool

Viktigt!

Om du aktiverar stöd för zonredundans för elastiska pooler blir alla databaser i poolzonen redundanta.

Azure-portalen

1. Gå till Azure Portal för att hitta och välj den elastiska pool som du vill migrera.

2. Välj Inställningar och välj sedan Konfigurera.

3. Välj Ja för Vill du göra den här elastiska poolzonen redundant?.

4. Välj Spara.

5. Vänta med att få ett meddelande om att åtgärden har slutförts i Meddelanden på den översta menyn i Azure Portal.

6. Kontrollera att zonredundans är aktiverat genom att välja Konfigurera och sedan välja Poolinställningar.

7. Alternativet zonredundant bör vara inställt på Ja.

PowerShell

Öppna PowerShell som administratör och kör följande kommando (ersätt platshållarna i "<>" med dina resursnamn). Observera att <server_name> inte bör innehålla .database.windows.net.

Connect-AzAccount
$subscriptionid = <'your subscription id here'>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    ElasticPoolName = '<Elastic_Pool_Name>'
}

Set-AzSqlElasticPool  @parameters -ZoneRedundant 

Azure CLI

Använd Azure CLI för att köra följande kommando (ersätt platshållarna i "<>" med dina resursnamn):

    az sql elastic-pool update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Elastic_Pool_Name>” --zone-redundant 

ARM

Information om hur du aktiverar zonredundans finns i Elastiska pooler – Skapa eller uppdatera i ARM.

Omdistribuering (Hyperskala)

För tjänstnivån Hyperskala kan stöd för zonredundans endast anges när databasen skapas och kan inte ändras när databasen har etablerats. Om du vill få stöd för zonredundans måste du utföra en dataöverföring från din befintliga hyperskala-tjänstnivå för en enskild databas. För att kunna utföra överföringen och aktivera alternativet zonredundans måste en klon skapas med hjälp av databaskopiering, återställning till tidpunkt eller geo-replik.

Omdistribueringsöverväganden

• Det finns två omdistribueringslägen (online och offline):

  • Metoderna För databaskopiering och återställning till tidpunkt (offlineläge) skapas en transaktionsmässigt konsekvent databas vid en viss tidpunkt. Det innebär att dataändringar som utförs efter att kopierings- eller återställningsåtgärden har initierats inte är tillgängliga för den kopierade eller återställda databasen.

  • Geo-replikmetoden (onlineläge) är en omdistribution där eventuella dataändringar från källan synkroniseras till målet.

• Anslutningssträngen för programmet måste uppdateras så att den pekar på den zonredundanta databasen.

Distribuera om en enskild databas

Databaskopia

Om du vill skapa en databaskopiering och aktivera zonredundans med Azure Portal, PowerShell eller Azure CLI följer du anvisningarna i kopiera en transaktionsmässigt konsekvent kopia av en databas i Azure SQL Database.

Återställning till tidpunkt

Om du vill skapa en återställning till tidpunktsdatabas och aktivera zonredundans med Azure Portal, PowerShell eller Azure CLI följer du anvisningarna i Återställning till tidpunkt.

Geo-replik

Så här skapar du en geo-replik av databasen:

1. Följ anvisningarna med Azure Portal, PowerShell eller Azure CLI i Konfigurera aktiv geo-replikering och redundans (Azure SQL Database) och aktivera zonredundans under Compute + Storage

2. Repliken är seedad, och den tid det tar att seeda data beror på storleken på källdatabasen. Du kan övervaka statusen för seeding i Azure Portal eller genom att köra följande TSQL-frågor på replikdatabasen:

       SELECT * FROM sys.dm_geo_replication_link_status;
       SELECT * FROM sys.dm_operation_status;
   

3. När databassådderingen är klar utför du en planerad redundansväxling (ingen dataförlust) för att göra den zonredundanta måldatabasen till primär. Använd sys.dm_geo_replication_link_status för att visa status för geo-replikeringstillståndet. Är replication_state_desc CATCH_UP när den sekundära databasen är i ett transaktionsmässigt konsekvent tillstånd. I vyn sys.dm_operation_status dynamisk hantering letar du efter state_desc COMPLETED när seeding-åtgärden har slutförts.

4. Uppdatera servernamnet i anslutningssträng för programmet så att det återspeglar den nya zonredundanta databasen.

5. Du kan rensa genom att ta bort den ursprungliga icke-zonredundanta databasen från geo-replikrelationen. Du kan välja att ta bort den.

Inaktivera zonredundans

Om du vill inaktivera zonredundans för en enskild databas eller en elastisk pool kan du använda portalen eller ARM-API:et.

Om du vill inaktivera zonredundans för Hyperskala-tjänstnivå kan du ångra de steg som beskrivs i Omdistribution (Hyperskala).

Elastisk pool

Så här inaktiverar du zonredundans med Azure Portal:

1. Gå till Azure Portal för att hitta och välj den elastiska pool som du inte längre vill vara zonredundant.

2. Välj Inställningar och välj sedan Konfigurera.

3. Välj Nej för Vill du göra den här elastiska poolzonen redundant?.

4. Välj Spara.

Så här inaktiverar du zonredundans med PowerShell:

Set-AzSqlElasticpool -ResourceGroupName "RSETLEM-AzureSQLDB" -ServerName "rs-az-testserver1" -ElasticPoolName "testep10" -ZoneRedundant:$false

Så här inaktiverar du zonredundans med Azure CLI:

az sql elastic-pool update --resource-group "RSETLEM-AzureSQLDB" --server "rs-az-testserver1" --name "testep10" --zone-redundant false

Information om hur du inaktiverar zonredundans med ARM finns i Databaser – Skapa eller uppdatera i ARM och använd properties.zoneRedundant egenskapen.

Enkel databas

Så här inaktiverar du zonredundans med Azure Portal:

1. Gå till Azure Portal för att hitta och välj den databas som du inte längre vill vara zonredundant.

2. Välj Inställningar och välj sedan Konfigurera.

3. Välj Nej för Vill du göra den här databaszonen redundant?

4. Välj Spara.

Så här inaktiverar du zonredundans med PowerShell:

set-azsqlDatabase -ResourceGroupName "RSETLEM-AzureSQLDB" -DatabaseName "TestDB1" -ServerName "rs-az-testserver1" -ZoneRedundant:$false 

Så här inaktiverar du zonredundans med Azure CLI:

az sql db update --resource-group "RSETLEM-AzureSQLDB" --server "rs-az-testserver1" --name "TestDB1" --zone-redundant false

Information om hur du inaktiverar zonredundans med ARM finns i Databaser – Skapa eller uppdatera i ARM och använd properties.zoneRedundant egenskapen.

Nästa steg

Azure-tjänster och regioner som stöder tillgänglighetszoner