Konfigurieren eines lizenzfreien Standby-Replikats für Azure SQL Datenbank (Vorschau)

  • Artikel

Gilt für:Azure SQL-Datenbank

In diesem Artikel wird beschrieben, wie Sie Lizenzierungskosten sparen können, indem Sie eine sekundäre Datenbank für die Notfallwiederherstellung (DR) für den Standby-Modus entwerfen, wenn Sie Azure SQL-Datenbank verwenden.

Hinweis

Standby-Azure SQL-Datenbank Replikate befinden sich derzeit in der Vorschau.

Übersicht

Wenn ein sekundäres Datenbank-Replikat nur für die Notfallwiederherstellung verwendet wird und weder Workloads darauf ausgeführt werden noch Anwendungen Verbindungen damit herstellen, können Sie Lizenzkosten sparen, indem Sie die Datenbank als Standby-Replikat definieren. Wenn eine sekundäre Datenbank als Standby-Instanz festgelegt ist, stellt Microsoft Ihnen so viele vCores zur Verfügung wie für die primäre Datenbank lizenziert sind, und zwar ohne zusätzliche Kosten. Dies erfolgt im Rahmen des von den Produktlizenzbedingungen bereitgestellten Vorteils für Failoverrechte. Ihnen werden trotzdem die Computer- und Speicherkosten in Rechnung gestellt, die von der sekundären Datenbank verwendet werden.

Sie können ein Replikat für den Standby-Modus festlegen, wenn Sie eine neue Replikation einer aktiven Georeplikation konfigurieren oder wenn Sie ein bestehendes Replikat in ein Standby-Replikat konvertieren.

Während die aktive Georeplikation das Hinzufügen von vier sekundären Replikaten unterstützt, können Sie nur ein sekundäres Datenbank-Replikat für den Standby-Modus festlegen. Failovergruppen unterstützen ein sekundäres Datenbank-Replikat pro primäre Datenbank, und es kann entweder lesbar oder Standby-Modus sein.

Beim geplanten oder ungeplanten Failover wird das Standby-Replikat zur neuen Primärdatenbank und es fallen die regulären vCore-Lizenzkosten an, während die ursprüngliche Primärdatenbank zur neuen sekundären Standby-Datenbank wird und keine vCore-Lizenzkosten mehr anfallen.

Weitere Informationen finden Sie in diesem Video von Data Exposed:

Kostenvorteil

Wenn Sie ein Datenbank Replikate, die als Standby-Replikate festgelegen, berechnet Microsoft Ihnen keine SQL Server-Lizenzkosten für die vCores, die vom Standby-Replikat verwendet werden. Da für die Datenbank jedoch die gesamte Stunde in Rechnung gestellt wird, werden Ihnen möglicherweise weiterhin Lizenzierungskosten für die gesamte Stunde berechnet, wenn die Zustandsänderung im Laufe der Stunde erfolgt.

Der Vorteil hat unterschiedliche Auswirkungen auf die Kundschaft, je nachdem ob sie das Modell mit nutzungsbasierter Bezahlung oder den Azure-Hybridvorteil nutzt. Für Kundschaft mit nutzungsbasierter Bezahlung wird ein Rabatt für die virtuellen Kerne auf der Rechnung ausgewiesen. Für Kundschaft, die den Azure-Hybridvorteil für das Standbyreplikat verwendet, wird die Anzahl der virtuellen Kerne, die das sekundäre Replikat verwendet, im Lizenzierungspool rückerstattet.

Wenn Sie beispielsweise als Kund*in mit nutzungsbasierter Bezahlung der sekundären Datenbank 16 vCores zugewiesen haben, finden Sie auf Ihrer Rechnung einen Rabatt für 16 vCores, wenn Sie Ihre sekundäre Datenbank nur als Standby-Replikat festlegen.

Wenn Sie in einem anderen Beispiel über 16 Lizenzen mit Azure-Hybridvorteil verfügen und eine verwaltete Datenbank mit jeweils 16 vCores in einer Failover-Gruppe bereitstellen, werden nach dem Festlegen der sekundären Datenbank als Standby-Instanz 16 vCores an Ihren Lizenzpool rückerstattet, die Sie für andere Azure SQL-Bereitstellungen verwenden können.

Funktionen

In der folgenden Tabelle werden die Funktionen einer sekundären verwalteten Standby-Instanz beschrieben:

Funktionalität BESCHREIBUNG
Eingeschränkte Leseworkloads Nachdem Sie Ihre Datenbank als Standby-Instanz festgelegt haben, können Sie nur eine begrenzte Anzahl von Lese-Workloads auf der sekundären Datenbank ausführen, z. B. dynamische Verwaltungssichten (Dynamic Management Views, DMVs), Sicherungen und DBCC-Abfragen (Database Console Commands, Datenbankkonsolenbefehle).
Geplantes Failover Vom Standbyreplikat werden alle geplanten Failoverszenarien unterstützt, einschließlich Wiederherstellungsübungen, das Verschieben von Datenbanken in andere Regionen und das Zurückgeben von Datenbanken an die primäre Instanz. Wenn das sekundäre Failover zum primären Replikat gemacht wird, kann es sowohl Lese- als auch Schreibabfragen verarbeiten. Das neue sekundäre Replikat (das ursprüngliche primäre Replikat) wird zum Standbyreplikat und sollte nicht mehr für Leseworkloads verwendet werden.
Ungeplantes Failover Während eines ungeplanten Failovers kann das sekundäre Replikat, sobald es die primäre Rolle einnimmt, sowohl Lese- als auch Schreibabfragen verarbeiten. Nachdem der Ausfall behoben wurde und die ursprüngliche primäre Instanz wieder verbunden ist, wird diese zum neuen sekundären Standbyreplikat und sollte nicht mehr für Leseworkloads verwendet werden.
Sichern und Wiederherstellen Das Sicherungs- und Wiederherstellungsverhalten von einem Standby-Replikat und einer lesbaren sekundären verwalteten Datenbank-Replikat ist identisch.
Überwachung Alle Überwachungsvorgänge, die von einem lesbaren sekundären Replikat unterstützt werden, werden auch vom Standbyreplikat unterstützt.

Das Standby-Datenbank-Replikat darf nur für die Notfallwiederherstellung verwendet werden. Es dürfen keine Produktionsanwendungen mit dem Replikat verbunden werden. Im Folgenden werden die einzigen Aktivitäten aufgeführt, die bei Standby-Datenbanken zulässig sind:

  • Ausführen von Wartungsvorgängen, z. B. checkDB
  • Verbinden von Überwachungsanwendungen
  • Ausführen von Übungen zur Notfallwiederherstellung

Einschränkungen

In der folgenden Tabelle sind die unterstützten und nicht unterstützten Bereitstellungsmodelle aufgeführt:

Bereitstellungsmodell Computeebene Dienstebene Standby-Replikate unterstützt Hardware
Einzeldatenbank Bereitgestellt Universell Ja Standardserie (Gen5), FSv2-Serie, DC-Serie
Einzeldatenbank Bereitgestellt Unternehmenskritisch Ja Standardserie (Gen5), DC-Serie
Einzeldatenbank Bereitgestellt Hyperscale – –
Einzeldatenbank Serverlos Alle No –
Pool für elastische Datenbanken Alle Alle No –

Die Verwendung einer Standbydatenbank hat die folgenden Einschränkungen:

  • Nur ein sekundäres Datenbank-Replikat kann für den Standby-Modus festgelegt werden.
  • Die serverlose Computerebene wird nicht unterstützt. Standby-Replikate können nicht aktiviert werden, wenn sich die primäre oder sekundäre Datenbank in der serverlosen Computerebene befindet.
  • Das DTU-Einkaufsmodell wird nicht unterstützt. Sie können ein Standby-Replikat nur für Datenbanken aktivieren, indem Sie das vCore-Einkaufsmodell verwenden.
  • Die Hyperscale-Dienstebene wird nicht unterstützt. Nur Datenbanken in den Dienstebenen Allgemeiner Zweck und Unternehmenskritisch können für den Standby-Modus festgelegt werden.
  • Wenn Sie eine Failovergruppe verwenden, werden Standby-Rechte auf Datenbankebene und nicht auf Failovergruppenebene zugewiesen und müssen für jede Datenbank innerhalb der Failovergruppe separat zugewiesen werden.
  • Das Entwerfen eines sekundären Replikats für den Standby-Modus wird nicht unterstützt, wenn es sich bei dem Replikat um ein sekundäres Replikat eines sekundären Replikats handelt (ein Prozess, der als Verkettung bekannt ist).

Voraussetzungen

  • Eine Azure-Subscription. Sollten Sie keine Azure-Subscription haben, erstellen Sie ein kostenloses Azure-Konto, bevor Sie beginnen.
  • Eine primäre bereitgestellte vCore-Azure SQL-Datenbank in der Dienstebene Allgemein oder Unternehmenskritisch, die auf unterstützter Hardware ausgeführt wird. Sehen Sie sich den Schnellstart an und beginnen Sie.

Konfigurieren eines neuen Replikats für den Standby-Modus

Sie können ein Replikat für den Standby-Modus festlegen, wenn Sie eine neue aktive Georeplikationsbeziehung mithilfe von Azure-Portal, PowerShell, Azure CLI oder REST-API konfigurieren.

Führen Sie die folgenden Schritte aus, um eine neue aktive Georeplikationsbeziehung zu erstellen und die sekundäre Datenbank für den Standby-Modus im Azure-Portal festzulegen:

  1. Gehen Sie im Azure-Portal zu Ihrer SQL-Datenbank-Ressource.

  2. Wählen Sie unter Datenverwaltung im Ressourcenmenü Replikate aus, und wählen Sie dann + Replikat erstellen aus, um die Seite SQL-Datenbank erstellen – Georeplikat zu öffnen.

    Screenshot: Replikatseite für die SQL-Datenbank im Azure-Portal.

  3. Wählen Sie auf der Seite SQL-Datenbank erstellen – Georeplikat unter Replikatkonfiguration die Option Standby-Replikat als Replikattyp aus. Aktivieren Sie das Kontrollkästchen, um zu bestätigen, dass Sie das Replikat für den Standby-Modus verwenden.

    Screenshot: Seite „Georeplikat erstellen“ mit hervorgehobenem Standby-Replikat im Azure-Portal.

  4. Geben Sie einen neuen oder vorhandenen Server für die neue Standby-Datenbank an, und verwenden Sie dann Überprüfen + erstellen, um eine endgültige Überprüfung Der Datenbank- und Serverdetails auszuführen.

  5. Verwenden Sie Erstellen, um die Einstellungen zu bestätigen und ein neues Standby-Datenbankreplikat zu erstellen.

Konvertieren eines vorhandenen Replikats

Sie können das Azure-Portal oder den REST-API-Befehl Replication Links – Update verwenden, um ein vorhandenes Replikat von einem regulären Georeplikat in ein Standby-Replikat oder ein Standby-Replikat in ein reguläres Georeplikat zu konvertieren.

Führen Sie die folgenden Schritte aus, um ein bestehendes Replikat im Azure-Portal zu konvertieren:

  1. Gehen Sie im Azure-Portal zu Ihrer SQL-Datenbank-Ressource.
  2. Wählen Sie unter DatenverwaltungReplikate aus.
  3. Wählen Sie die Auslassungspunkte (...) für das Replikat aus, und wählen Sie dann Folgendes aus:
    1. Um ein reguläres Replikat in ein Standby-Replikat zu konvertieren, wählen Sie In Standby konvertieren aus. Aktivieren Sie im Pop-up-Fenster In Standby-Replikat konvertieren das Kontrollkästchen neben Ich bestätige …, und wählen Sie dann Ja aus, um Ihre Änderung zu speichern und Ihr Replikat zu konvertieren.
    2. Um ein Standby-Replikat in ein reguläres Georeplikat zu konvertieren, wählen Sie In Geo konvertieren aus. Aktivieren Sie im Pop-up-Fenster In Georeplikat konvertieren das Kontrollkästchen neben Ich bestätige …, und wählen Sie dann Ja aus, um Ihre Änderungen zu speichern und Ihr Replikat zu konvertieren.

Wenn Sie ein vorhandenes Replikat mithilfe des REST-API-Befehls Replication Links – Update konvertieren, legen Sie für ein Standby-Replikat linkType als STANDBY fest. Oder nutzen Sie GEO, um ein vorhandenes Standby-Replikat wieder in ein normales Georeplikat zu konvertieren.

Anzeigen von Lizenzierungsrechten

Sie können die Lizenzierungsrechte für eine bestehende Datenbank über Azure-Portal, PowerShell, Azure CLI oder REST-API anzeigen.

Führen Sie die folgenden Schritte aus, um die Lizenzierungsrechte für eine vorhandene Datenbank mithilfe des Azure-Portal zu überprüfen:

  1. Rufen Sie Ihre SQL-Datenbank im Azure-Portal auf.

  2. Aktivieren Sie auf der Seite Übersicht unter Grundlagen den Replikattyp. Ein Wert Standby gibt an, dass die Datenbank ein Standby-Replikat ist, und Ihnen werden für diese Datenbank keine SQL-Lizenzierungskosten in Rechnung gestellt:

    Screenshot: Übersichtsseite für die SQL-Datenbank im Azure-Portal mit hervorgehobenem Replikattyp.

Entfernen des Standby-Replikats

Nachdem eine Datenbank als Standby-Modus festgelegt wurde, können Sie die Standby-Eigenschaft nicht einfach entfernen. Um ein Standby-Replikat zu entfernen, müssen Sie die Replikation beenden, um die aktive Georeplikationsbeziehung zu beenden. Nachdem die Replikation beendet wurde, wird Ihre Datenbank zu einem eigenständigen Gerät, und Sie beginnen mit dem Auftreten von Lizenzkosten.

Sie können die Georeplikation stoppen, indem Sie das Azure-Portal, PowerShell, Azure CLI oder REST-API verwenden.

Führen Sie die folgenden Schritte aus, um ein Standby-Replikat zu entfernen, indem Sie die Georeplikation im Azure-Portal beenden:

  1. Rufen Sie Ihre SQL-Datenbank im Azure-Portal auf.
  2. Wählen Sie unter DatenverwaltungReplikate aus.
  3. Wählen Sie die Auslassungspunkte (...) für das Standby-Replikat und dann im Pop-up-Menü Replikation beenden aus. Dadurch wird die Replikation beendet, sodass Ihre sekundäre Datenbank jetzt eigenständig und nicht für Standby vorgesehen ist. Es fallen Lizenzkosten an.

Häufig gestellte Fragen (FAQ)

  • Was sind die Auswirkungen auf die Preisgestaltung?

    Bei sekundären Datenbankreplikaten fallen Kosten für die SQL-Lizenz, Computing und das Speichern von Daten und Backups an. Wenn Sie ein Datenbankreplikat für den Standby-Modus festlegen, werden Ihnen die Lizenzkosten für die vom sekundären Replikat verwendeten vCores nicht in Rechnung gestellt, die Kosten für Rechenleistung und Speicherplatz fallen jedoch weiterhin an.

  • Was sind die ungefähren Einsparungen mit einem Standby-Replikat?

    Ohne Lizenzkosten ist ein Standby-Replikat etwa 35 bis 40 Prozent kostengünstiger als ein reguläres vollständig lesbares sekundäres Replikat. Die Einsparungen können jedoch je nach Region variieren. Um genauere Preise zu erhalten, verwenden Sie den Azure-Preisrechner und legen Sie die SQL Server-Lizenz auf Azure-Hybridvorteil fest.

  • Wie viele vCores werden für das Standby-Replikat lizenzfrei sein?

    Die gleiche Anzahl von vCores wie die primäre Datenbank verwendet. Das Konfigurieren des sekundären Replikats mit derselben Anzahl von vCores wie die primäre Datenbank wird empfohlen, um optimale Georeplikationsleistung zu erzielen.

  • Muss ich über eine SQL Server-Lizenz mit aktiver Software Assurance verfügen, um ein Standby-Replikat zu verwenden?

    Nein Da das Standby-Replikat keine Lizenzkosten verursacht, benötigen Sie keine aktive SQL Server-Lizenz mit aktiver Software Assurance.

  • Wie kann ich das Standby-Replikat verwenden?

    Standby-Replikate sind nur für Notfallwiederherstellungszwecke (DR) vorgesehen und können keine aktiven Lese-Workloads enthalten. Die einzigen akzeptablen Workloads sind für die Überwachung, Wartung wie das Ausführen von dynamischen Verwaltungsansichten (Dynamic Management Views, DMVs) und CheckDB.

  • Kann ich mein vorhandenes lesbares sekundäres Replikat auf ein Standby-Replikat aktualisieren, um Kosten zu sparen?

    Ja, im Azure-Portal im Bereich Replikate. Wählen Sie die Auslassungspunkte (...) und dann die Option zum Konvertieren Ihres Replikats aus.

  • Kann ich die Azure-Hybridvorteil für das Standby-Replikat aktivieren?

    Durch das Festlegen eines Replikats für den Standby-Modus wird der Rabatt durch den Azure-Hybridvorteil ersetzt, sodass Sie das Lizenzierungsmodell für das Replikat nicht mithilfe des Azure-Portals ändern können. Wenn Sie jedoch möchten, dass das Standby-Replikat den Azure-Hybridvorteil beim Failover verwenden soll, können Sie den Azure CLI-Befehl Set-AzSqlDatabase oder az sql db update verwenden, um den Lizenztyp BasePrice (Azure-Hybridvorteil) für das Standby-Replikat zu aktualisieren, das verwendet werden soll, wenn das Standby-Replikat nach dem Failover primär wird.

  • Was geschieht mit dem Standby-Replikatstatus während des Failovers?

    Bei geplantem oder ungeplantem Failover wird das Standby-Replikat primär und es fallen reguläre Lizenzkosten an. Das ursprüngliche primäre Replikat wird zum neuen sekundären Standby-Replikat und es fallen keine vCore-Lizenzierungskosten mehr an. Da für die Instanz jedoch die gesamte Stunde in Rechnung gestellt wird, werden Ihnen für das neue sekundäre Replikat möglicherweise weiterhin Lizenzierungskosten für die gesamte Stunde berechnet, wenn die Zustandsänderung im Laufe der Stunde erfolgt. Wenn für die ursprüngliche primäre Datenbank (die nach dem Failover zum Standby wird) der Azure-Hybridvorteil galt, wird dieser durch den Rabatt für die Standby-Lizenzierung ersetzt.

  • Was geschieht, wenn ich die primäre oder sekundäre Datenbank auf eine höhere vCore-Größe skaliere?

    Beim Skalieren empfiehlt es sich zuerst die sekundäre und dann die primäre Datenbank hochzuskalieren. Obwohl das sekundäre Replikat während des Übergangszeitraums eine höhere Anzahl von vCores als die primäre Datenbank hat, gelten die Vorteile des Standby-Replikats weiterhin. Versuchen Sie, den Übergangszeitraum so kurz wie möglich zu halten.

  • Was geschieht, wenn ich die primäre oder sekundäre Datenbank auf eine niedrigere vCore-Größe herunterskaliere?

    Bei der Skalierung nach unten empfiehlt es sich, zuerst die primäre und dann die sekundäre Datenbank nach unten zu skalieren. Obwohl das sekundäre Replikat während des Übergangszeitraums eine höhere Anzahl von vCores als die primäre Datenbank hat, gelten die Vorteile des Standby-Replikats weiterhin. Versuchen Sie, den Übergangszeitraum so kurz wie möglich zu halten.

  • Was geschieht, wenn ich die Georeplikationsbeziehung zwischen dem primären Replikat und dem Standby-Replikat entferne?

    Nachdem die Georeplikation entfernt wurde, wird die Standby-Datenbank zu einer regulären eigenständigen Datenbank und es entstehen Lizenzierungskosten.

  • Kann ich reservierte Kapazitätsvorteile für das Standby-Replikat erhalten?

    Ja. Reservierte Kapazitätspreise sind vollständig mit dem Standby-Replikat kompatibel.

Zugehöriger Inhalt