Konfigurieren und Verwalten von benannten Hyperscale-Replikaten

Gilt für:Azure SQL-Datenbank

Dieser Artikel enthält Beispiele zum Konfigurieren und Verwalten eines benannten Hyperscale-Replikats in Azure SQL-Datenbank.

Erstellen Sie ein benanntes Hyperscale-Replikat

Die folgenden Beispielszenarien leiten Sie an zur Erstellung eines benannten Replikats WideWorldImporters_NamedReplica für die Datenbank WideWorldImporters im Azure-Portal, mit T-SQL, PowerShell oder Azure CLI.

Im folgenden Beispiel wird ein neues benanntes Hyperscale-Replikat im Azure-Portal angelegt.

Wechseln Sie zum Azure SQL-Hub bei aka.ms/azuresqlhub.
Erweitern Sie im Ressourcenmenü Azure SQL-Datenbank , und wählen Sie SQL-Datenbanken aus.
Wählen Sie auf der Seite "SQL-Datenbank " die vorhandene Hyperscale-Datenbank aus, für die Sie das benannte Replikat erstellen möchten.
Wählen Sie im Ressourcenmenü unter "Datenverwaltung" die Option "Replikate" und dann "Replikat erstellen" aus.
Wählen Sie unter Replikatkonfiguration die Option Benanntes Replikat aus. Wählen Sie einen vorhandenen Server aus oder erstellen Sie einen neuen Server für das benannte Replikat. Geben Sie den Namen der Datenbank des benannten Replikats ein, und konfigurieren Sie bei Bedarf die Optionen für Compute +Speicher.
Optional konfigurieren Sie ein zonenredundantes benanntes Hyperscale-Replikat. Weitere Informationen finden Sie unter Zonenredundanz für benannte Hyperscale-Replikate in Azure SQL-Datenbank.
1. Wählen Sie auf der Seite Datenbank konfigurieren auf die Frage Möchten Sie diese Datenbank zonenredundant machen? die Antwort Ja aus.
2. Fügen Sie mindestens ein sekundäres Replikat mit hoher Verfügbarkeit zu Ihrer Konfiguration hinzu.
3. Wählen Sie Übernehmen.
Wählen Sie Überprüfen + Erstellen, überprüfen Sie die Informationen, und klicken Sie dann auf Erstellen.
Der benannte Replikatbereitstellungsprozess beginnt.
Nach Abschluss der Bereitstellung wird der Status des benannten Replikats angezeigt.
Kehren Sie zur Seite der primären Datenbank zurück, und wählen Sie Replikate aus. Ihr benanntes Replikat ist unter Benannte Replikate aufgeführt.

Im folgenden Beispiel wird das benannte Replikat WideWorldImporters_NamedReplica für die Datenbank WideWorldImporters über T-SQL erstellt. Das primäre Replikat verwendet das Service-Level-Objective HS_Gen5_4, während das benannte Replikat HS_Gen5_2 verwendet. Beide verwenden denselben logischen Server mit dem Namen contosoeast.

ALTER DATABASE [WideWorldImporters]
ADD SECONDARY ON SERVER [contosoeast]
WITH (SERVICE_OBJECTIVE = 'HS_Gen5_2', SECONDARY_TYPE = Named, DATABASE_NAME = [WideWorldImporters_NamedReplica]);

Im folgenden Beispiel wird ein benanntes Replikat WideWorldImporters_NamedReplica für die Datenbank WideWorldImporters über das PowerShell-Cmdlet New-AzSqlDatabaseSecondary erstellt. Das primäre Replikat verwendet das Service Level Ziel „HS_Gen5_4“, während das benannte Replikat „HS_Gen5_2“ nutzt. Beide verwenden denselben logischen Server mit dem Namen contosoeast.

New-AzSqlDatabaseSecondary -ResourceGroupName "MyResourceGroup" -ServerName "contosoeast" -DatabaseName "WideWorldImporters" -PartnerResourceGroupName "MyResourceGroup" -PartnerServerName "contosoeast" -PartnerDatabaseName "WideWorldImporters_NamedReplica" -SecondaryType Named -SecondaryServiceObjectiveName HS_Gen5_2

Zum Konfigurieren eines zonenredundanten benannten Hyperscale-Replikats müssen Sie die Eingabeparameter –ZoneRedundant und -HighAvailabilityReplicaCount für New-AzSqlDatabaseSecondary beide angeben.

New-AzSqlDatabaseSecondary -ResourceGroupName "MyResourceGroup" -ServerName "contosoeast" -DatabaseName "WideWorldImporters" -PartnerResourceGroupName "MyResourceGroup" -PartnerServerName "contosoeast" -PartnerDatabaseName "WideWorldImporters_NamedReplica" -SecondaryType Named -SecondaryServiceObjectiveName HS_Gen5_2 -HighAvailabilityReplicaCount 1 -ZoneRedundant

Mit Get-AzSqlDatabase können Sie überprüfen, ob das benannte Replikat erstellt wurde.

Get-AzSqlDatabase -DatabaseName "WideWorldImporters_NamedReplica" -ResourceGroupName "MyResourceGroup" -ServerName "contosoeast"

Im folgenden Beispiel wird ein benanntes Replikat WideWorldImporters_NamedReplica für die Datenbank WideWorldImporters über den Azure CLI-Befehl az sql db replica create erstellt. Das primäre Replikat nutzt das Service Level Objective (SLO) HS_Gen5_4, während das benannte Replikat HS_Gen5_2 verwendet. Beide verwenden denselben logischen Server mit dem Namen contosoeast.

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s contosoeast --secondary-type named --partner-database WideWorldImporters_NamedReplica --partner-server contosoeast --service-objective HS_Gen5_2

Zum Konfigurieren eines zonenredundanten benannten Hyperscale-Replikats müssen Sie die Eingabeparameter –zone-redundant und ha-replicas für az sql db replica create beide angeben.

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s contosoeast --secondary-type named --partner-database WideWorldImporters_NamedReplica --partner-server contosoeast --service-objective HS_Gen5_2 --ha-replicas 1 -zone-redundant

So überprüfen Sie, ob ein benanntes Replikat erstellt wird:

az sql db show -g MyResourceGroup -n WideWorldImporters -s contosoeast

Da keine Datenverschiebungen erforderlich sind, kann ein benanntes Replikat in den meisten Fällen in etwa einer Minute erstellt werden. Sobald das benannte Replikat verfügbar ist, kann es im Azure-Portal oder mit einem beliebigem Befehlszeilentool wie der Azure CLI oder PowerShell angezeigt werden. Ein benanntes Replikat kann als reguläre schreibgeschützte Datenbank verwendet werden.

Herstellen einer Verbindung zu einem benannten Hyperscale-Replikat

Zum Herstellen einer Verbindung mit einem benannten Hyperscale-Replikat müssen Sie die Verbindungszeichenfolge für dieses benannte Replikat verwenden und auf die Server- und Datenbanknamen verweisen. Die Option ApplicationIntent=ReadOnly muss nicht angegeben werden, da benannte Replikate immer schreibgeschützt sind.

Wie bei Hochverfügbarkeitsreplikaten werden die Datencaches auf den einzelnen benannten Replikaten mit dem primären Replikat synchronisiert, obwohl das primäre Replikat, die Hochverfügbarkeitsreplikate und die benannten Replikate dieselben Daten auf denselben Seitenservern gemeinsam nutzen. Die Synchronisierung wird vom Transaktionsprotokolldienst vorgenommen, der Protokolldatensätze vom primären Replikat an benannte Replikate weiterleitet. Dies führt dazu, dass die Anwendung von Protokolldatensätzen je nach Workload, die von einem benannten Replikat verarbeitet wird, mit unterschiedlicher Geschwindigkeit durchgeführt werden kann. Daher können verschiedene Replikate eine unterschiedliche Datenlatenz im Hinblick auf das primäre Replikat aufweisen.

Ändern einer Hyperscale-benannten Replik

Sie können das Servicelevelziel eines benannten Replikats bei seiner Erstellung definieren. Dies erfolgt über den Befehl ALTER DATABASE oder auf andere unterstützte Weise (Portal, Azure CLI, PowerShell). Wenn Sie das Servicelevelziel ändern möchten, nachdem das Replikat erstellt wurde, können Sie dies mithilfe des Befehls ALTER DATABASE ... MODIFY für das benannte Replikat selbst tun.

Im folgenden Beispiel ist WideWorldImporters_NamedReplica das benannte Replikat der Datenbank WideWorldImporters.

Öffnen Sie die Seite mit benannter Replikatdatenbank.
Wählen Sie im Ressourcenmenü unter "Einstellungen" die Option "Berechnen + Speicher" aus.
Aktualisieren Sie die vCores-Einstellungen nach Bedarf.

ALTER DATABASE [WideWorldImporters_NamedReplica] MODIFY (SERVICE_OBJECTIVE = 'HS_Gen5_4')

Set-AzSqlDatabase -ResourceGroup "MyResourceGroup" -ServerName "contosoeast" -DatabaseName "WideWorldImporters_NamedReplica" -RequestedServiceObjectiveName "HS_Gen5_4"

az sql db update -g MyResourceGroup -s contosoeast -n WideWorldImporters_NamedReplica --service-objective HS_Gen5_4

Entfernen eines benannten Hyperscale-Replikats

Wenn Sie ein benanntes Hyperscale-Replikat löschen möchten, geschieht dies genauso wie bei einer regulären Datenbank.

Öffnen Sie die Datenbankseite des benannten Replikats und wählen Sie die Option Delete aus.

Sorgen Sie dafür, dass Sie mit der Datenbank master des Servers verbunden sind, der das benannte Replikat enthält, das Sie löschen möchten. Verwenden Sie anschließend den folgenden Befehl:

Dieser Befehl entfernt eine Datenbank mit dem Namen WideWorldImporters_NamedReplica.

DROP DATABASE [WideWorldImporters_NamedReplica];

Dieser Befehl entfernt eine Datenbank mit dem Namen WideWorldImporters_NamedReplica vom logischen Server contosoeast.

Remove-AzSqlDatabase -ResourceGroupName "MyResourceGroup" -ServerName "contosoeast" -DatabaseName "WideWorldImporters_NamedReplica"

Dieser Befehl entfernt eine Datenbank mit dem Namen WideWorldImporters_NamedReplica vom logischen Server contosoeast.

az sql db delete -g MyResourceGroup -s contosoeast -n WideWorldImporters_NamedReplica

Wichtig

Benannte Replikate werden automatisch entfernt, wenn das primäre Replikat, auf deren Grundlage sie erstellt wurden, gelöscht wird.

Benannte Replikatkonfiguration optimieren

Es wird empfohlen, das benannte Replikat mit der gleichen Rechengröße (vCores) wie das primäre Replikat zu konfigurieren. Wenn das primäre Replikat eine hohe Schreiblast aufweist, kann ein benanntes Replikat mit geringerer Rechenkapazität möglicherweise nicht mithalten, was zu einer Replikationsverzögerung führt. Um die Wiederherstellbarkeits-SLAs beizubehalten, kann die Transaktionsprotokollrate der primären Datenbank vorübergehend reduziert werden, damit die sekundären Datenbanken aufholen können.

Wenn Sie sich dafür entscheiden, das benannte Replikat mit einer anderer Compute-Größe (vCores) als das primäre zu erstellen, überwachen Sie die Protokoll-E/A-Rate auf dem primären Replikat über die Zeit hinweg. Auf diese Weise können Sie die minimale Rechenkapazität schätzen, die für die benannten Replikate erforderlich ist, um die Replikationslast zu bewältigen. Weitere Informationen erhalten Sie anhand der folgenden Objekte:

Die dynamische Verwaltungsfunktion sys.dm_hs_database_log_rate() (DMF) bietet zusätzliche Details zur besseren Verständnis einer möglichen Reduzierung der Protokollrate. Es kann angeben, welches spezifische sekundäre Replikat beim Anwenden von Protokolldatensätzen hinterherhinkt, sowie die Gesamtgröße des nicht angewendeten Transaktionsprotokolls.
Verwenden Sie die Ansicht sys.resource_stats, um historische Protokoll-E/A-Daten abzurufen.
Verwenden Sie sys.dm_db_resource_stats für aktuelle Protokoll-E/A-Daten mit höherer Granularität, die kurzfristige Ausschläge besser widerspiegeln.

Weitere Informationen finden Sie unter der Hyperscale-Leistungsdiagnose für Azure SQL-Datenbank.

Feedback

War diese Seite hilfreich?

Last updated on 2026-03-18