Freigeben über


Auslagern von unterstützten Sicherungen auf sekundäre Replikate einer Verfügbarkeitsgruppe

Gilt für:SQL Server

Die Funktionen für aktive sekundäre Always On-Verfügbarkeitsgruppen umfassen auch die Unterstützung von Sicherungen auf sekundären Replikaten. Sicherungsvorgänge können E/A und CPU (mit Sicherungskomprimierung) erheblich belasten. Durch die Auslagerung von Sicherungen auf ein sekundäres Replikat mit dem Status SYNCHRONIZED oder SYNCHRONIZING können Sie die Ressourcen auf der Serverinstanz verwenden, die das primäre Replikat für Arbeitsauslastungen erster Ebene hostet.

Hinweis

RESTORE-Anweisungen sind für die primären oder sekundären Datenbanken einer Verfügbarkeitsgruppe nicht zulässig.

Unterstützte Sicherungstypen für sekundäre Replikate

Wenn Sie eine vollständige Datenbanksicherung für ein sekundäres Replikat ausführen möchten, müssen Sie eine "Nur Kopieren"-Sicherungen ausführen, da kopiergeschützte Sicherungen keine Auswirkungen auf die Protokollkette haben oder die differenzielle Bitmap löschen. Beachte Folgendes:

  • Kopiergeschützte Sicherungen verhindern nicht das Abschneiden des Transaktionsprotokolls auf anderen Replikaten.

  • Eine Copy-Only-Sicherung verhindert das Abschneiden von Protokollen auf dem sekundären Replikat, während die Sicherung ausgeführt wird.

  • Wenn das Transaktionsprotokoll für das primäre Replikat auf ein LSN abgeschnitten wird, das zwischen dem ersten und dem letzten LSN des Transaktionsprotokolls des sekundären Replikats liegt, das die kopiegeschützte Sicherung ausführt, wird möglicherweise der folgende Fehler im Protokoll des sekundären Replikats angezeigt:

    Error 9019: The virtual log file sequence 0x%08x at offset 0x%016I64x bytes in file '%ls' is active and cannot be overwritten with sequence 0x%08x for database '%ls'.

    Während die Sicherung wahrscheinlich erfolgreich ist, schlägt die Synchronisierung für dieses sekundäre Replikat fehl, bis die kopiegeschützte Sicherung abgeschlossen ist. Wenn das sekundäre Replikat auf synchronen Commit festgelegt ist, werden Schreibworkloads für das primäre Replikat möglicherweise blockiert, bis das Protokoll auf das sekundäre Replikat gehärtet werden kann. Nach Abschluss der Sicherung wird das Protokoll im sekundären Replikat abgeschnitten, zu welchem Zeitpunkt es erneut synchronisiert werden sollte. Wenn fehler 9019 beim Ausführen einer kopiegeschützten Sicherung auf einem sekundären Replikat auftritt, führen Sie stattdessen die vollständige Sicherung für das primäre Replikat aus.

Beachten Sie beim Ausführen von Sicherungen auf sekundären Replikaten Folgendes:

  • Zum Sichern einer sekundären Datenbank muss ein sekundäres Replikat in der Lage sein, mit dem primären Replikat zu kommunizieren und synchronisiert oder synchronisierend zu sein.
  • Differenzielle Sicherungen werden auf sekundären Replikaten nicht unterstützt.
  • Das Ausführen konkurrierender Sicherungen, z.B. einer Transaktionsprotokollsicherung auf dem primären Replikat bei gleichzeitiger Sicherung der vollständigen Datenbank auf dem sekundären Replikat, wird derzeit nicht unterstützt.
  • BACKUP LOG unterstützt nur regelmäßige Protokollsicherungen (die Option COPY_ONLY wird für Protokollsicherungen auf sekundären Replikaten nicht unterstützt). Bei sämtlichen Protokollsicherungen von Replikaten (primär oder sekundär) wird ungeachtet ihres Verfügbarkeitsmodus (mit synchronem Commit oder mit asynchronem Commit) eine konsistente Protokollkette sichergestellt.

In einer Verteilten Verfügbarkeitsgruppe können Sicherungen für sekundäre Replikate in derselben Verfügbarkeitsgruppe wie das aktive primäre Replikat oder das primäre Replikat jeder sekundären Verfügbarkeitsgruppen ausgeführt werden. Sicherungen können nicht für ein sekundäres Replikat in einer sekundären Verfügbarkeitsgruppe ausgeführt werden, da sekundäre Replikate nur mit dem primären Replikat in ihrer eigenen Verfügbarkeitsgruppe kommunizieren. Nur für Replikate, die direkt mit dem globalen primären Replikat kommunizieren, können Sicherungsvorgänge durchgeführt werden.

Neu für SQL Server 2025

Ab SQL Server 2025 (17.x) Preview können Sie zusätzlich zu vorhandenen Kopier- und Transaktionsprotokollsicherungen auch vollständige und differenzielle Sicherungen für jedes sekundäre Replikat ausführen.

Verwenden Sie die folgenden Traceflags, um Sicherungen auf sekundären Replikaten zu ermöglichen.

Aktivieren Sie das relevante Traceflag für jedes Replikat in der Verfügbarkeitsgruppe (einschließlich des primären Replikats), damit Sicherungen auf sekundären Replikaten nach einem Failover fortgesetzt werden.

Um beispielsweise differenzielle Sicherungen für sekundäre Replikate zu aktivieren, führen Sie den folgenden Befehl aus:

DBCC TRACEON (3261, -1);

Hinweis

Das Erstellen vollständiger und differenzieller Sicherungen befindet sich in der Vorschau und ist derzeit nur in SQL Server 2025 (17.x) Preview verfügbar.

Konfigurieren, wo Sicherungsaufträge ausgeführt werden

Das Ausführen von Sicherungen auf einem sekundären Replikat zum Auslagern der Sicherungsarbeitsauslastung vom primären Produktionsserver ist ein großer Vorteil. Durch die Ausführung von Sicherungen auf sekundären Replikaten wird es jedoch wesentlich komplexer, den Ausführungsort von Sicherungsaufträgen zu bestimmen. Um diesen Vorgang zu vereinfachen, konfigurieren Sie den Ausführungsort von Sicherungsaufträgen wie folgt:

  1. Konfigurieren Sie die Verfügbarkeitsgruppe, um anzugeben, welche Verfügbarkeitsreplikate am Ort, an dem Sie Sicherungen wünschen, ausgeführt werden sollen. Weitere Informationen finden Sie unter AUTOMATED_BACKUP_PREFERENCE und BACKUP_PRIORITY Parameter in CREATE AVAILABILITY GROUP oder ALTER AVAILABILITY GROUP.

  2. Erstellen Sie skriptbasierte Sicherungsaufträge für jede Verfügbarkeitsdatenbank auf jeder Serverinstanz, die ein Verfügbarkeitsreplikat hostet, das für das Ausführen von Sicherungen infrage kommt. Weitere Informationen finden Sie im Abschnitt "Nachverfolgung: Nach dem Konfigurieren der Sicherung auf sekundären Replikaten" der Konfiguration von Sicherungen auf sekundären Replikaten einer AlwaysOn-Verfügbarkeitsgruppe.