Migrieren der Azure SQL-Datenbank zur Unterstützung von Verfügbarkeitszonen

Artikel
04/12/2024

In diesem Leitfaden wird beschrieben, wie Azure SQL-Datenbank zur Verfügbarkeitszonenunterstützung migriert wird.

Das Aktivieren von Zonenredundanz für Azure SQL-Datenbank garantiert Hochverfügbarkeit, da die Datenbank Azure-Verfügbarkeitszonen verwendet, um Daten an mehreren physischen Standorten innerhalb einer Azure-Region zu replizieren. Durch die Auswahl der Zonenredundanz können Sie dafür sorgen, dass Ihre Datenbanken und Pools für elastische Datenbanken mehr Fehlern gegen+ber (u. a. schwerwiegende Ausfälle des Rechenzentrums) resilienter sind, ohne dass die Anwendungslogik geändert werden muss.

Voraussetzungen

Bevor Sie zur Verfügbarkeitszonenunterstützung migrieren, lesen Sie die folgende Tabelle, um sicherzustellen, dass sich Ihre Azure SQL-Datenbank in einem unterstützten Dienstebenen- und Bereitstellungsmodell befindet. Stellen Sie sicher, dass Ihre Dienstebene und Ihr Modell in einer Region angeboten werden, die Verfügbarkeitszonen unterstützt.

Dienstebene	Bereitstellungsmodell	Verfügbarkeit von Zonenredundanz
Premium	Singleton oder Pool für elastische Datenbanken	Alle Regionen, die Verfügbarkeitszonen unterstützen
Unternehmenskritisch	Singleton oder Pool für elastische Datenbanken	Alle Regionen, die Verfügbarkeitszonen unterstützen
Universell	Singleton oder Pool für elastische Datenbanken	Ausgewählte Regionen, die Verfügbarkeitszonen unterstützen
Hyperscale	Einzeldatenbank	Alle Regionen, die Verfügbarkeitszonen unterstützen

Anforderungen an Ausfallzeiten

Die Migration für Premium-, Unternehmenskritisch- und Universell-Dienstebenen ist ein Onlinevorgang mit einer kurzen Downtime gegen Ende des Migrationsprozesses. Wenn Sie Wiederholungslogik bei vorübergehenden Standardfehlern implementiert haben, bemerken Sie den Failover nicht.

Für die Hyperscale-Dienstebene kann die Zonenredundanzunterstützung nur während der Datenbankerstellung angegeben und nicht geändert werden, nachdem die Ressource bereitgestellt wurde. Wenn Sie zur Verfügbarkeitszonenunterstützung wechseln möchten, müssen Sie die Daten mit Datenbankkopie, Zeitpunktwiederherstellung oder Georeplikat übertragen. Wenn sich die Zieldatenbank in einer anderen Region als die Quelle befindet oder die Datenbanksicherungsspeicherredundanz für das Ziel von der Quelldatenbank abweicht, ist die Ausfallzeit proportional zur Größe des Datenvorgangs.

Migration (Premium, Unternehmenskritisch und Universell)

Für die Dienstebenen Premium, Unternehmenskritisch und Universell ist die Migration zur Zonenredundanz möglich.

Führen Sie die folgenden Schritte aus, um die Migration für ein Singleton oder einen Pool für elastische Datenbanken durchzuführen.

Migrieren eines Singleton

Öffnen Sie das Azure-Portal, um Ihre Datenbank zu suchen. Suchen Sie nach SQL-Datenbanken, und wählen Sie diese Option aus.
Wählen Sie die Datenbank aus, die Sie migrieren möchten.
Wählen Sie unter Einstellungen die Option Compute und Speicher aus.
Wählen Sie Ja für Möchten Sie diese Datenbank als zonenredundant festlegen? aus.
Wählen Sie Übernehmen.
Warten Sie, bis Sie unter Benachrichtigungen im oberen Menü des Azure-Portals eine Benachrichtigung zum Abschluss des Vorgangs sehen.
Um zu überprüfen, ob Zonenredundanz aktiviert ist, wählen Sie Übersicht und dann Eigenschaften aus.
Vergewissern Sie sich im Abschnitt Verfügbarkeit, dass die Zonenredundanz auf Aktiviert festgelegt ist.

Öffnen Sie PowerShell als Administrator, und führen Sie den folgenden Befehl aus. Ersetzen Sie dabei die Platzhalter in <> durch Ihre Ressourcennamen. Beachten Sie, dass <server_name> nicht .database.windows.net enthalten sollte.

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

Verwenden Sie die Azure CLI, um den folgenden Befehl auszuführen. Ersetzen Sie dabei die Platzhalter in <> durch Ihre Ressourcennamen:

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

Migrieren eines Pools für elastische Datenbanken

Wichtig

Die Aktivierung der Zonenredundanzunterstützung für Pools für elastische Datenbanken legt alle Datenbanken innerhalb der Poolzone als redundant fest.

Wechseln Sie zum Azure-Portal, um den Pool für elastische Datenbanken zu suchen und auszuwählen, den Sie migrieren möchten.
Wählen Sie Einstellungen und dann Konfigurieren aus.
Wählen Sie Ja für Möchten Sie diesen Pool für elastische Datenbanken als zonenredundant festlegen? aus.
Wählen Sie Speichern.
Warten Sie, bis Sie unter Benachrichtigungen im oberen Menü des Azure-Portals eine Benachrichtigung zum Abschluss des Vorgangs sehen.
Um zu überprüfen, ob die Zonenredundanz aktiviert ist, wählen Sie Konfigurieren und dann Pooleinstellungen aus.
Die Option „Zonenredundant“ sollte auf Ja festgelegt sein.

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

Verwenden Sie die Azure CLI, um den folgenden Befehl auszuführen. Ersetzen Sie dabei die Platzhalter in <> durch Ihre Ressourcennamen:

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

Erneute Bereitstellung (Hyperscale)

Für die Hyperscale-Dienstebene kann die Zonenredundanzunterstützung nur während der Datenbankerstellung angegeben und nicht geändert werden, nachdem die Datenbank bereitgestellt wurde. Wenn Sie Zonenredundanzunterstützung nutzen möchten, müssen Sie eine Datenübertragung aus Ihrem vorhandenen Singleton der Hyperscale-Dienstebene durchführen. Um die Übertragung durchzuführen und die Zonenredundanzoption zu aktivieren, muss ein Klon mithilfe von Datenbankkopie, Zeitpunktwiederherstellung oder Georeplikat erstellt werden.

Überlegungen zur Bereitstellung

Es gibt zwei Modi für die erneute Bereitstellung (online und offline):
- Die Datenbankkopie- und Zeitpunktwiederherstellungsmethode (Offlinemodus) erstellt eine transaktionskonsistente Datenbank zu einem bestimmten Zeitpunkt. Daher sind Datenänderungen, die nach dem Initiieren des Kopier- oder Wiederherstellungsvorgangs erfolgen, nicht in der kopierten oder wiederhergestellten Datenbank vorhanden.
- Die Georeplikatmethode (Onlinemodus) ist eine erneute Bereitstellung, bei der alle Datenänderungen aus der Quelle mit dem Ziel synchronisiert werden.
Verbindungszeichenfolge für die Anwendung muss aktualisiert werden, um auf die zonenredundante Datenbank zu verweisen.

Erneutes Bereitstellen eines Singleton

Datenbankkopie

Um eine Datenbankkopie zu erstellen und Zonenredundanz über das Azure-Portal, PowerShell oder die Azure CLI zu aktivieren, befolgen Sie die Anweisungen unter Kopieren einer transaktionskonsistenten Kopie einer Datenbank in Azure SQL-Datenbank.

Point-in-Time-Wiederherstellung

Um eine Zeitpunktwiederherstellung der Datenbank durchzuführen und Zonenredundanz über das Azure-Portal, PowerShell oder die Azure CLI zu aktivieren, befolgen Sie die Anweisungen unter Zeitpunktwiederherstellung.

Geo-Replikate

So erstellen Sie ein Georeplikat der Datenbank:

Befolgen Sie die Anweisungen für das Azure-Portal, PowerShell oder die Azure CLI unter Konfigurieren der aktiven Georeplikation und des Failovers (Azure SQL-Datenbank), und aktivieren Sie Zonenredundanz unter Compute und Speicher.
Das Replikat wird geseedet, und die für das Seeding der Daten benötigte Zeit hängt von der Größe der Quelldatenbank ab. Sie können den Status des Seedings im Azure-Portal überwachen oder die folgenden TSQL-Abfragen in der Replikatdatenbank ausführen:
```
    SELECT * FROM sys.dm_geo_replication_link_status;
    SELECT * FROM sys.dm_operation_status;
```
Nachdem das Seeding der Datenbank abgeschlossen ist, führen Sie ein geplantes Failover (ohne Datenverlust) aus, um die zonenredundante Zieldatenbank als primäre Datenbank festzulegen. Verwenden Sie sys.dm_geo_replication_link_status, um den Status des Georeplikationszustands anzuzeigen. replication_state_desc ist CATCH_UP, wenn sich die sekundäre Datenbank in einem transaktionskonsistenten Zustand befindet. Suchen Sie in der dynamischen Verwaltungssicht sys.dm_operation_status nach state_desc, was nach Abschluss des Seedingvorgangs den Wert COMPLETED aufweisen sollte.
Aktualisieren Sie den Servernamen in den Verbindungszeichenfolgen für die Anwendung, um die neue zonenredundante Datenbank widerzuspiegeln.
Zum Bereinigen sollten Sie die ursprüngliche nicht zonenredundante Datenbank aus der Georeplikatbeziehung entfernen. Sie können sie löschen.

Deaktivieren der Zonenredundanz

Um die Zonenredundanz für ein Singleton oder einen Pool für elastische Datenbanken zu deaktivieren, können Sie das Portal oder die ARM-API verwenden.

Um die Zonenredundanz für die Hyperscale-Dienstebene zu deaktivieren, können Sie die Schritte rückgängig machen, die unter Erneute Bereitstellung (Hyperscale) aufgeführt sind.

Pool für elastische Datenbanken
Einzeldatenbank

So deaktivieren Sie die Zonenredundanz über das Azure-Portal:

Wechseln Sie zum Azure-Portal, um den Pool für elastische Datenbanken zu suchen und auszuwählen, der nicht mehr zonenredundant sein soll.
Wählen Sie Einstellungen und dann Konfigurieren aus.
Wählen Sie Nein für Möchten Sie diesen Pool für elastische Datenbanken als zonenredundant festlegen? aus.
Wählen Sie Speichern.

Informationen zum Deaktivieren der Zonenredundanz mit ARM finden Sie unter Datenbanken – Erstellen oder Aktualisieren in ARM und „Verwenden der properties.zoneRedundant-Eigenschaft“.