Ondersteuning voor Azure SQL Database migreren naar beschikbaarheidszone

In deze handleiding wordt beschreven hoe u Azure SQL Database migreert van ondersteuning voor niet-beschikbaarheidszones naar beschikbaarheidsondersteuning.

Het inschakelen van zoneredundantie voor Azure SQL Database garandeert hoge beschikbaarheid omdat de database Gebruikmaakt van Azure Beschikbaarheidszones om gegevens te repliceren op meerdere fysieke locaties binnen een Azure-regio. Door zoneredundantie te selecteren, kunt u uw databases en elastische pools tolerant maken voor een grotere set fouten, zoals catastrofale datacenterstoringen, zonder wijzigingen in de toepassingslogica.

Vereisten

Voordat u migreert naar ondersteuning voor beschikbaarheidszones, raadpleegt u de volgende tabel om ervoor te zorgen dat uw Azure SQL Database zich in een ondersteunde servicelaag en implementatiemodel bevindt. Zorg ervoor dat uw laag en model worden aangeboden in een regio die beschikbaarheidszones ondersteunt.

Servicelaag Implementatiemodel Beschikbaarheid van zoneredundantie
Premium Individuele database of elastische pool Alle regio's die beschikbaarheidszones ondersteunen
Bedrijfskritiek Individuele database of elastische pool Alle regio's die beschikbaarheidszones ondersteunen
Algemeen gebruik Individuele database of elastische pool Geselecteerde regio's die beschikbaarheidszones ondersteunen
Hyperscale Individuele database Alle regio's die beschikbaarheidszones ondersteunen

Vereisten voor downtime

Migratie voor Premium, Bedrijfskritiek en servicelaag Algemeen gebruik is een onlinebewerking met een korte verbinding tot het einde van het migratieproces. Als u logica voor opnieuw proberen hebt geïmplementeerd voor tijdelijke standaardfouten, ziet u de failover niet.

Voor de Hyperscale-servicelaag kan zoneredundantie alleen worden opgegeven tijdens het maken van de database en kan deze niet worden gewijzigd zodra de resource is ingericht. Als u wilt overstappen op ondersteuning voor beschikbaarheidszones, moet u de gegevens overdragen met databasekopie, herstel naar een bepaald tijdstip of geo-replica. Als de doeldatabase zich in een andere regio bevindt dan de bron of als de redundantie van de databaseback-upopslag voor het doel verschilt van de brondatabase, is downtime evenredig met de grootte van de gegevensbewerking.

Migratie (Premium, Bedrijfskritiek en Algemeen gebruik)

Voor de servicelagen Premium, Bedrijfskritiek en Algemeen gebruik is migratie naar zoneredundantie mogelijk.

Volg de onderstaande stappen om een migratie uit te voeren voor één database of een elastische pool.

Eén database migreren

  1. Ga naar Azure Portal om uw database te vinden. Zoek en selecteer SQL-databases.

  2. Selecteer de database die u wilt migreren.

  3. Selecteer Onder Instellingen Compute + Storage.

  4. Selecteer Ja als u deze databasezone redundant wilt maken?

  5. Selecteer Toepassen.

  6. Wacht totdat u een melding hebt ontvangen dat de bewerking is voltooid in meldingen in het bovenste menu van Azure Portal.

  7. Als u wilt controleren of zoneredundantie is ingeschakeld, selecteert u Overzicht en selecteert u Vervolgens Eigenschappen.

  8. Controleer in de sectie Beschikbaarheid of zoneredundantie is ingesteld op Ingeschakeld.

Een elastische pool migreren

Belangrijk

Het inschakelen van ondersteuning voor zoneredundantie voor elastische pools maakt alle databases binnen de poolzone redundant.

  1. Ga naar Azure Portal om de elastische pool te zoeken en te selecteren die u wilt migreren.

  2. Selecteer Instellingen en selecteer vervolgens Configureren.

  3. Selecteer Ja als u deze elastische poolzone redundant wilt maken?

  4. Selecteer Opslaan.

  5. Wacht totdat u een melding hebt ontvangen dat de bewerking is voltooid in meldingen in het bovenste menu van Azure Portal.

  6. Als u wilt controleren of zoneredundantie is ingeschakeld, selecteert u Configureren en vervolgens Groepsinstellingen.

  7. De zoneredundante optie moet worden ingesteld op Ja.

Opnieuw implementeren (Hyperscale)

Voor de Hyperscale-servicelaag kan zoneredundantie alleen worden opgegeven tijdens het maken van de database en kan deze niet worden gewijzigd zodra de database is ingericht. Als u ondersteuning voor zoneredundantie wilt krijgen, moet u een gegevensoverdracht uitvoeren vanuit uw bestaande individuele database van de Hyperscale-servicelaag. Als u de overdracht wilt uitvoeren en de optie zoneredundantie wilt inschakelen, moet een kloon worden gemaakt met behulp van databasekopie, herstel naar een bepaald tijdstip of geo-replica.

Overwegingen voor opnieuw implementeren

  • Er zijn twee modi voor opnieuw implementeren (online en offline):

    • De methoden voor het kopiëren van databases en herstel naar een bepaald tijdstip (offlinemodus) maken een transactioneel consistente database op een bepaald moment. Als gevolg hiervan zijn alle gegevenswijzigingen die worden uitgevoerd nadat de kopieer- of herstelbewerking is gestart, niet beschikbaar in de gekopieerde of herstelde database.

    • Geo-replicamethode (onlinemodus) is een herployment waarbij gegevenswijzigingen van de bron worden gesynchroniseerd met het doel.

  • Verbinding maken iontekenreeks voor de toepassing moet worden bijgewerkt om te verwijzen naar de zoneredundante database.

Een individuele database opnieuw implementeren

Database-kopie

Als u een databasekopie wilt maken en zoneredundantie wilt inschakelen met Azure Portal, PowerShell of Azure CLI, volgt u de instructies bij het kopiëren van een transactioneel consistente kopie van een database in Azure SQL Database.

Herstel naar een bepaald tijdstip

Als u een herstel naar een bepaald tijdstip wilt maken en zoneredundantie wilt inschakelen met Azure Portal, PowerShell of Azure CLI, volgt u de instructies in Herstel naar een bepaald tijdstip.

Geo-replica

Een geo-replica van de database maken:

  1. Volg de instructies met Azure Portal, PowerShell of Azure CLI in Actieve geo-replicatie en failover configureren (Azure SQL Database) en schakel zoneredundantie in onder Compute + Storage

  2. De replica wordt geseed en de tijd die nodig is voor het seeden van de gegevens, is afhankelijk van de grootte van de brondatabase. U kunt de status van seeding bewaken in Azure Portal of door de volgende TSQL-query's uit te voeren op de replicadatabase:

        SELECT * FROM sys.dm_geo_replication_link_status;
        SELECT * FROM sys.dm_operation_status;
    
  3. Zodra de database seeding is voltooid, voert u een geplande failover (geen gegevensverlies) uit om de zoneredundante doeldatabase als primair te maken. Gebruik de sys.dm_geo_replication_link_status om de status van de geo-replicatiestatus weer te geven. De replication_state_desc secundaire CATCH_UP database heeft een transactioneel consistente status. Zoek in de sys.dm_operation_status dynamische beheerweergave naar state_desc wanneer COMPLETED de seedingbewerking is voltooid.

  4. Werk de servernaam in de verbindingsreeks s voor de toepassing bij zodat deze overeenkomt met de nieuwe zoneredundante database.

  5. Als u wilt opschonen, kunt u de oorspronkelijke niet-zoneredundante database verwijderen uit de geo-replicarelatie. U kunt ervoor kiezen om deze te verwijderen.

Zoneredundantie uitschakelen

Als u zoneredundantie wilt uitschakelen voor één database of een elastische pool, kunt u de portal of ARM-API gebruiken.

Als u zoneredundantie wilt uitschakelen voor de Hyperscale-servicelaag, kunt u de stappen omkeren die worden beschreven in Opnieuw implementeren (Hyperscale).

Zoneredundantie uitschakelen met Azure Portal:

  1. Ga naar Azure Portal om de elastische pool te zoeken en te selecteren die u niet langer zone-redundant wilt maken.

  2. Selecteer Instellingen en selecteer vervolgens Configureren.

  3. Selecteer Nee als u deze elastische poolzone redundant wilt maken?

  4. Selecteer Opslaan.

Als u zoneredundantie met ARM wilt uitschakelen, raadpleegt u Databases - Maken of bijwerken in ARM en gebruikt u de properties.zoneRedundant eigenschap.

Volgende stappen