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. Sekundäre Replikate werden sowohl von serverlosen als auch von bereitgestellten Computingebenen unterstützt.

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 hauptsächlich verwendet, um die Datenbankverfügbarkeit zu erhöhen, da sie zu Failoverzwecken als unmittelbar betriebsbereite Replikate dienen. 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 dieser Replikate ist oft identisch mit dem des primären Replikats. Hochverfügbarkeitsreplikate können nicht als eigenständige Ressource über das Portal oder eine API angezeigt oder verwaltet werden.

Es kann null bis vier Hochverfügbarkeitsreplikate geben. Die Anzahl kann während der Erstellung einer Datenbank oder nach Erstellung einer Datenbank über den üblichen Verwaltungsendpunkt und die üblichen Verwaltungstools (z. B. PowerShell, Azure CLI, Azure-Portal, REST-API) geändert werden. 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 Verhalten ReadWrite 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 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.

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, 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:

  • Bei Benutzern, die mit einem benannten Replikat verbunden sind, wird die Verbindung nicht getrennt, wenn das primäre Replikat hoch- oder herunterskaliert wird. Gleichzeitig sind Benutzer, die mit dem primären Replikat verbunden sind, vom Hoch- oder Herunterskalieren der benannten Replikate nicht betroffen.
  • 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:

Abgesehen von den oben aufgeführten Hauptszenarios bieten benannte Replikate Flexibilität und Elastizität, sodass sie auch für viele anderen 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

Durch die Zonenredundanz für benannte Hyperscale-Replikate in Azure SQL-Datenbank werden Serverknoten in Form benannter Replikate anhand von Azure Verfügbarkeitszonen auf verschiedene physische Standorte innerhalb einer Azure-Region verteilt. 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 ein Georeplikat erstellt wird, 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 die Parameter „ha-replicas“ und „redundant“ beide angeben.
    • In PowerShell müssen Sie den 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.

    • Die Aktivierung der Zonenredundanz für benannte Replikate ist optional, auch wenn für die primäre Datenbank die Zonenredundanz aktiviert ist.
    • 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, auf deren Grundlage das benannte Replikat erstellt wurde, auf 150 festgelegt ist. Eine Problemumgehung, sofern möglich, ist das Abrufen derselben Daten mithilfe der Funktion DATABASEPROPERTYEX(), die die richtigen Daten zurückgibt.

Zugehöriger Inhalt

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

Weitere Informationen finden Sie unter: