Freigeben über

Sekundäre Hyperscale-Replikate

  • Artikel

Gilt für: Azure SQL-Datenbank

Wie unter Hyperscale-Dienstebene beschrieben bietet die Hyperscale-Dienstebene in Azure SQL-Datenbank zwei verschiedene Arten von Computeknoten, die auch als „Replikate“ bezeichnet werden:

Sekundäre Replikate sind immer schreibgeschützt. Es gibt drei verschiedene Arten:

  • Hochverfügbarkeitsreplikat
  • Geo-Replikate
  • Benannte Replikate

Jeder Typ verfügt über eine unterschiedliche Architektur und über verschiedene Features, Zwecke und Kosten. Je nach Features, die Sie benötigen, können Sie nur einen oder alle drei Typen zusammen verwenden. Sie können sekundäre Replikate entweder mit serverlosen oder bereitgestellten Computetarifen verwenden.

Tutorials zum Konfigurieren und Verwalten von benannten Hyperscale-Replikaten finden Sie unter:

Hochverfügbarkeitsreplikat

Ein Hochverfügbarkeitsreplikat verwendet dieselben Seitenserver wie das primäre Replikat, es sind also keine Datenkopien erforderlich, um ein Hochverfügbarkeitsreplikat hinzuzufügen. Hochverfügbarkeitsreplikate werden verwendet, um die Datenbankverfügbarkeit zu erhöhen, da sie zu Failoverzwecken als unmittelbar betriebsbereite Standbyreplikate verwendet werden können. Wenn die Verfügbarkeit des primären Replikats nicht mehr gegeben ist, erfolgt das Failover auf eins der vorhandenen Hochverfügbarkeitsreplikate schnell und automatisch. Die Verbindungszeichenfolge muss nicht geändert werden. Während eines Failovers kann für Anwendungen eine minimale Downtime auftreten. Dies ist aktiven Verbindungen geschuldet, die getrennt werden. Wie gewöhnlich wird für dieses Szenario eine geeignete Wiederholungslogik empfohlen. Mehrere Treiber bieten zu einem gewissen Grad bereits eine automatische Wiederholungslogik. Wenn Sie .NET verwenden, bietet die aktuelle Version der Bibliothek Microsoft.Data.SqlClient nativ vollständige Unterstützung für eine konfigurierbare automatische Wiederholungslogik.

Hochverfügbarkeitsreplikate verwenden denselben Server- und Datenbanknamen wie das primäre Replikat. Das Servicelevelziel (SLO) dieser Replikate ist oft identisch mit dem des primären Replikats. Hochverfügbarkeitsreplikate können nicht als eigenständige Ressourcen über das Portal oder eine API angezeigt oder verwaltet werden. Sie werden mit derselben Computerate wie das primäre Replikat in Rechnung gestellt, die Speicherkosten gelten jedoch nicht für sekundäre Replikate.

Es kann null bis vier Hochverfügbarkeitsreplikate geben. Sie können die Anzahl der Replikate während der Erstellung einer neuen Datenbank angeben oder die Anzahl der Replikate für eine vorhandene Datenbank aktualisieren. Sie können die allgemeinen Verwaltungsendpunkte und -tools (z. B. Azure PowerShell, Azure CLI, Azure-Portal, REST API) verwenden, um die Anzahl der Hochverfügbarkeitsreplikate anzugeben. Das Erstellen oder Entfernen von Hochverfügbarkeitsreplikaten wirkt sich nicht auf aktive Verbindungen auf dem primären Replikat aus.

Herstellen einer Verbindung zu einem Hochverfügbarkeitsreplikat

Bei Hyperscale-Datenbanken bestimmt das Argument ApplicationIntent in der vom Client verwendeten Verbindungszeichenfolge, ob die Verbindung an das primäre Replikat mit Schreibzugriff oder an ein schreibgeschütztes Hochverfügbarkeitsreplikat weitergeleitet wird. Wenn ApplicationIntent auf ReadOnly festgelegt ist und die Datenbank kein sekundäres Replikat aufweist, wird die Verbindung an das primäre Replikat weitergeleitet, und sie weist standardmäßig das ReadWrite-Verhalten auf.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Alle Hochverfügbarkeitsreplikate sind in ihrer Ressourcenkapazität identisch. Wenn mehr als ein Hochverfügbarkeitsreplikat vorhanden ist, wird die Workload mit Leseabsicht willkürlich auf alle Hochverfügbarkeitsreplikate verteilt. Wenn es mehrere Hochverfügbarkeitsreplikate gibt, denken Sie daran, dass jedes im Hinblick auf am primären Replikat vorgenommene Datenänderungen über eine unterschiedliche Datenlatenz verfügen könnte. Jedes Hochverfügbarkeitsreplikat verwendet dieselben Daten wie das primäre Replikat für dieselben Seitenserver. Lokale Datencaches auf den einzelnen Hochverfügbarkeitsreplikaten spiegeln jedoch die am primären Replikat vorgenommenen Änderungen über den Transaktionsprotokolldienst wider, der Protokolldatensätze vom primären Replikat an Hochverfügbarkeitsreplikate weiterleitet. Dies führt dazu, dass die Anwendung von Protokolldatensätzen, je nach Workload, die von einem Hochverfügbarkeitsreplikat ausgeführt wird, mit unterschiedlicher Geschwindigkeit durchgeführt werden kann, was dazu führen kann, dass verschiedene Replikate eine unterschiedliche Datenlatenz im Hinblick auf das primäre Replikat aufweisen können.

Benannte Replikate

Ein benanntes Replikat verwendet genau wie ein Hochverfügbarkeitsreplikat dieselben Seitenserver wie das primäre Replikat. Ähnlich wie Hochverfügbarkeitsreplikate sind keine Datenkopien erforderlich, um ein benanntes Replikat hinzuzufügen.

Es gibt Unterschiede zwischen Hochverfügbarkeitsreplikaten und benannten Replikaten:

  • Benannte Replikate werden im Portal und in API-Aufrufen (Azure CLI, Azure PowerShell, T-SQL) als reguläre (schreibgeschützte) Azure SQL-Datenbank-Instanzen angezeigt.
  • Benannte Replikate können Datenbanknamen haben, die sich vom primären Replikat unterscheiden. Optional können sie sich auf einem anderen logischen Server befinden, solange es sich um dieselbe Region wie die des primären Replikats handelt.
  • Benannte Replikate verfügen über ein eigenes Servicelevelziel, das unabhängig vom primären Replikat festgelegt und geändert werden kann.
  • Es werden bis zu 30 benannte Replikate unterstützt (pro primärem Replikat).
  • Es werden verschiedene Authentifizierungslösungen für jedes benannte Replikat unterstützt, indem verschiedene Anmeldungen für logische Server erstellt werden, die benannte Replikate hosten.

Daher bieten benannte Replikate gegenüber Hochverfügbarkeitsreplikaten mehrere Vorteile, was schreibgeschützte Workloads betrifft:

  • Benutzer, die mit einem benannten Replikat verbunden sind, werden nicht getrennt, wenn das primäre Replikat nach oben oder unten skaliert wird.
  • Benutzer, die mit dem primären Replikat verbunden sind, sind nicht betroffen, wenn benannte Replikate nach oben oder unten skaliert werden.
  • Workloads, die auf einem beliebigen Replikat (primär oder benannt) ausgeführt werden, sind von zeitintensiven Abfragen auf anderen Replikaten nicht betroffen.

Das Hauptziel benannter Replikate besteht darin, eine große Bandbreite von Szenarien mit horizontaler Leseskalierung zu ermöglichen und HTAP-Workloads (Hybrid Transactional and Analytical Processing, hybride Transaktions- und Analyseverarbeitung) zu optimieren. Beispiele für das Erstellen solcher Lösungen finden Sie hier:

Darüber hinaus bieten benannte Replikate Flexibilität und Elastizität, sodass sie auch für viele andere Anwendungsfälle geeignet sind:

  • Zugriffsisolation: Sie können Zugriff auf ein bestimmtes benanntes Replikat gewähren, allerdings nicht auf das primäre Replikat oder andere benannte Replikate.
  • Workloadabhängige Servicelevelziele: Da ein benanntes Replikat über ein eigenes Servicelevelziel verfügen kann, ist es möglich, andere benannte Replikate für andere Workloads und Anwendungsfälle zu verwenden. Ein benanntes Replikat könnte beispielsweise für Power BI-Anforderungen verwendet werden, während ein anderes für Daten für Data-Science-Aufgaben in Apache Spark verwendet werden kann. Jedes kann über ein unabhängiges Servicelevelziel verfügen und unabhängig skaliert werden.
  • Workloadabhängiges Routing: Mit bis zu 30 benannten Replikaten ist es möglich, benannte Replikate in Gruppen zu verwenden, damit eine Anwendung von einer anderen isoliert werden kann. Sie könnten beispielsweise eine Gruppe vier benannter Replikate verwenden, um Anforderungen zu verarbeiten, die von mobilen Anwendungen stammen. Eine andere aus zwei benannten Replikaten bestehende Gruppe kann verwendet werden, um Anforderungen zu verarbeiten, die von einer Webanwendung stammen. Dieser Ansatz ermöglicht eine genaue Anpassung der Leistung und der Kosten der einzelnen Gruppen.

Hinweis

Antworten auf häufig gestellte Fragen zu benannten Hyperscale-Replikaten finden Sie unter Benannte Hyperscale-Replikate in Azure SQL-Datenbank: Häufig gestellte Fragen.

Zonenredundanz für benannte Hyperscale-Replikate

Benannte Hyperscale-Replikate, die für Zonenredundanz konfiguriert sind, verwenden Azure-Verfügbarkeitszonen, um Computeknoten von benannten Replikaten an verschiedene physische Standorte innerhalb einer Azure-Region zu verteilen. Durch Auswählen der Zonenredundanz für benannte Replikate können Sie die Resilienz aller Ebenen Ihrer Hyperscale-Datenbanken auf einen größeren Bereich von Fehlern, einschließlich Ausfällen des Rechenzentrums, ohne Änderungen der Anwendungslogik erhöhen. Weitere Informationen finden Sie unter Zonenredundante Verfügbarkeit von Hyperscale.

Ein Tutorial zum Erstellen eines zonenredundanten benannten Hyperscale-Replikats finden Sie unter Erstellen eines benannten Hyperscale-Replikats.

Informationen zur Problembehandlung und zum Testen der Resilienz von Anwendungsfehlern finden Sie unter Testen der Resilienz von Anwendungsfehlern.

Geo-Replikate

Mit aktiver Georeplikation können Sie ein lesbares sekundäres Replikat der primären Hyperscale-Datenbank in derselben oder einer anderen Azure-Region erstellen. Georeplikate müssen auf einem anderen logischen Server erstellt werden. Der Datenbankname eines Georeplikats stimmt immer mit dem Datenbanknamen des primären Replikats überein.

Wenn Sie ein Georeplikat erstellen, werden alle Daten vom primären Replikat auf andere Seitenserver kopiert. Ein Georeplikat teilt seine Seitenserver nicht mit dem primären Replikat, selbst wenn sie sich in derselben Region befinden. Diese Architektur bietet die notwendige Redundanz für Geofailover.

Mit Georeplikaten wird eine hinsichtlich der Transaktionen konsistente Kopie der Datenbank über asynchrone Replikation erstellt. Wenn sich ein Georeplikat in einer anderen Azure-Region befindet, kann es bei einem Notfall oder Ausfall in der primären Region für die Notfallwiederherstellung verwendet werden. Georeplikate können auch für geografische Szenarios mit horizontaler Leseskalierung verwendet werden. Ab Oktober 2022 wird die Datenbankkopie aus einem sekundären Hyperscale-Georeplikat unterstützt.

Die Georeplikation für die Hyperscale-Datenbank hat die folgenden aktuellen Einschränkungen:

  • Nur ein Georeplikat kann (in derselben oder einer anderen Region) erstellt werden.
  • Die Point-in-Time-Wiederherstellung von Georeplikaten wird nicht unterstützt.
  • Das Erstellen eines Georeplikats eines Georeplikats (auch bekannt als „Verkettung von Georeplikaten“) wird nicht unterstützt.

Problembehandlung

Problembehandlung bei zonenredundanten benannten Hyperscale-Replikaten

  • Informationen zur Problembehandlung und zum Testen der Resilienz von Anwendungsfehlern finden Sie unter Testen der Resilienz von Anwendungsfehlern.

  • Geben Sie beim Erstellen eines zonenredundanten benannten Replikats in PowerShell und CLI unbedingt mindestens ein Hochverfügbarkeitsreplikat an. Ein Beispiel finden Sie unter Erstellen eines benannten Hyperscale-Replikats.

    • In Azure CLI müssen Sie sowohl die Parameter ha-replicas als auch redundant angeben.
    • In PowerShell müssen Sie die Parameter HighAvailabilityReplicaCount und ZoneRedundant angeben.
    • Ohne diese Angabe erhalten Sie die Fehlermeldung: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • In der Hyperscale-Datenbank sollte die Zonenredundanz als Voraussetzung für das Aktivieren dieses Features für benannte Replikate bereits aktiviert sein.

    • Sie können die Zonenredundanz für benannte Replikate optional zu aktivieren, auch wenn die primäre Datenbank Zonenredundanz aktiviert hat.
    • Wenn Sie nicht aktiviert ist, erhalten Sie die Fehlermeldung: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Bekannte Probleme

Teilweise fehlerhafte von sys.databases zurückgegebene Daten

Zeilenwerte, die von sys.databases für benannte Replikate in anderen Spalten zurückgegeben werden als name und database_id, sind ggf. inkonsistent und falsch. Für die Spalte compatibility_level eines benannten Replikats könnte beispielsweise der Wert 140 gemeldet werden, selbst wenn die primäre Datenbank, die dem das benannten Replikat entspricht, auf die Kompatibilitätsebene 150 festgelegt ist. Eine Umgehung, sofern möglich, ist das Abrufen derselben Daten mithilfe der Funktion DATABASEPROPERTYEX(), die die korrekten Daten zurückgibt.

Zugehöriger Inhalt

Tutorials zum Konfigurieren und Verwalten von benannten Hyperscale-Replikaten finden Sie unter:

Weitere Informationen finden Sie unter: