Verwenden Sie automatisches Seeding, um eine Always On-Verfügbarkeitsgruppe zu initialisieren

Gilt für:SQL Server

Mit SQL Server 2016 wurde das automatische Seeding von Verfügbarkeitsgruppen eingeführt. Beim Erstellen einer Verfügbarkeitsgruppe mit automatischem Seeding erstellt SQL Server automatisch die sekundären Replikate für jede Datenbank in der Gruppe. Sie müssen sekundäre Replikate nicht mehr manuell sichern und wiederherstellen. Erstellen Sie zum Aktivieren des automatischen Seedings die Verfügbarkeitsgruppe mit T-SQL, oder verwenden Sie die neueste Version von SQL Server Management Studio.

Weitere Hintergrundinformationen finden Sie unter Automatisches Seeding für sekundäre Replikate.

Voraussetzungen

In SQL Server 2016 erfordert automatisches Seeding, dass der Pfad für Daten- und Protokolldateien für jede SQL Server-Instanz der Verfügbarkeitsgruppe identisch ist. In SQL Server 2017 können Sie unterschiedliche Pfade verwenden, Microsoft empfiehlt jedoch, dieselben Pfade zu verwenden, wenn alle Replikate auf derselben Plattform (z.B. Windows oder Linux) gehostet werden. Plattformübergreifende Verfügbarkeitsgruppen besitzen unterschiedliche Pfade für die Replikate. Weitere Informationen finden Sie unter Datenträgerlayout.

Verfügbarkeitsgruppenseeding kommuniziert über den Datenbankspiegelungs-Endpunkt. Öffnen Sie Eingangsfirewallregeln für den Port für den Spiegelungsendpunkt auf jedem Server.

Datenbanken in einer Verfügbarkeitsgruppe müssen sich im vollständigen Wiederherstellungsmodell befinden. Die Datenbank muss über eine aktuelle vollständige Sicherung und eine aktuelle Transaktionsprotokollsicherung verfügen. Diese Sicherungsdateien werden nicht für das automatische Seeding verwendet, aber sie sind erforderlich, bevor die Datenbank einer Verfügbarkeitsgruppe hinzugefügt wird.

Verfügbarkeitsgruppe mit automatischem Seeding erstellen

Zum Erstellen einer Verfügbarkeitsgruppe mit automatischem Seeding legen Sie SEEDING_MODE=AUTOMATICfest.

Im folgenden Beispiel wird eine Verfügbarkeitsgruppe auf einem Windows Server-Failovercluster mit zwei Knoten erstellt. Aktualisieren Sie vor dem Ausführen der Skripts die Werte für Ihre Umgebung.

1. Erstellen Sie die Endpunkte. Jeder Server benötigt einen Endpunkt. Das folgende Skript erstellt einen Endpunkt, der TCP-Port 5022 für den Listener verwendet. Legen Sie <endpoint_name> und LISTENER_PORT entsprechend Ihrer Umgebung fest, und führen Sie das Skript auf beiden Servern aus:

   CREATE ENDPOINT [<endpoint_name>] 
       STATE=STARTED
       AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
       FOR DATA_MIRRORING (
           ROLE = ALL, 
           AUTHENTICATION = WINDOWS NEGOTIATE, 
           ENCRYPTION = REQUIRED ALGORITHM AES
           )
   GO
   

2. Erstellen Sie die Verfügbarkeitsgruppe. Das folgende Skript erstellt die Verfügbarkeitsgruppe. Aktualisieren Sie die Werte für den Gruppennamen, die Servernamen und die Domänennamen in spitzen Klammern <>, und führen Sie das Skript auf der primären Instanz von SQL Server aus.

   CREATE AVAILABILITY GROUP [<availability_group_name>]
       FOR DATABASE db1
       REPLICA ON'<*primary_server*>'
       WITH (ENDPOINT_URL = N'TCP://<primary_server>.<fully_qualified_domain_name>:5022', 
           FAILOVER_MODE = AUTOMATIC, 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
           BACKUP_PRIORITY = 50, 
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), 
           SEEDING_MODE = AUTOMATIC),
       N'<secondary_server>' WITH (ENDPOINT_URL = N'TCP://<secondary_server>.<fully_qualified_domain_name>:5022', 
           FAILOVER_MODE = AUTOMATIC, 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
           BACKUP_PRIORITY = 50, 
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), 
           SEEDING_MODE = AUTOMATIC);
   GO
   

3. Verknüpfen Sie die sekundäre Serverinstanz mit der Verfügbarkeitsgruppe, und gewähren Sie der Verfügbarkeitsgruppe Berechtigungen zum Erstellen von Datenbanken. Aktualisieren Sie das folgende Skript, ersetzen Sie die Werte für Ihre Umgebung in spitzen Klammern <>, und führen Sie dieses auf der sekundären Replikatinstanz von SQL Server aus:

   ALTER AVAILABILITY GROUP [<availability_group_name>] JOIN
   GO  
   ALTER AVAILABILITY GROUP [<availability_group_name>] GRANT CREATE ANY DATABASE
   GO
   

SQL Server erstellt automatisch das Datenbankreplikat auf dem sekundären Server. Wenn die Datenbank groß ist, kann die Synchronisierung der Datenbank einige Zeit dauern. Wenn sich eine Datenbank in einer Verfügbarkeitsgruppe befindet, die für das automatische Seeding konfiguriert ist, können Sie zum Überwachen des Seedingstatus die Systemsicht sys.dm_hadr_automatic_seeding abfragen. Die folgende Abfrage gibt eine Zeile für jede Datenbank in einer Verfügbarkeitsgruppe zurück, die für das automatische Seeding konfiguriert ist.

SELECT start_time,
    ag.name,
    db.database_name,
    current_state,
    performed_seeding,
    failure_state,
    failure_state_desc
FROM sys.dm_hadr_automatic_seeding autos 
    JOIN sys.availability_databases_cluster db 
        ON autos.ag_db_id = db.group_database_id
    JOIN sys.availability_groups ag 
        ON autos.ag_id = ag.group_id

Automatisches Seeding nach einer Verfügbarkeitsgruppe verhindern

Um vorübergehend zu verhindern, dass das primäre Replikat für weitere Datenbanken ein Seeding in das sekundäre Replikat ausführt, können Sie der Verfügbarkeitsgruppe die Berechtigung zum Erstellen von Datenbanken verweigern. Führen Sie die folgende Abfrage für die Instanz aus, die das sekundäre Replikat hostet, um der Verfügbarkeitsgruppe die Berechtigung zum Erstellen von Replikatdatenbanken zu verweigern.

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    DENY CREATE ANY DATABASE
GO

Aktivieren Sie automatisches Seeding für eine vorhandene Verfügbarkeitsgruppe

Sie können das automatische Seeding für eine vorhandene Datenbank festlegen. Mit dem folgenden Befehl wird eine Verfügbarkeitsgruppe so geändert, dass das automatische Seeding verwendet wird. Führen Sie den folgenden Befehl auf dem primären Replikat aus.

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    MODIFY REPLICA ON '<secondary_node>' 
    WITH (SEEDING_MODE = AUTOMATIC)
GO

Der vorherige Befehl zwingt eine Datenbank bei Bedarf dazu, das Seeding erneut zu starten. Wenn beim Seeding z.B. ein Fehler auftritt, weil auf dem sekundären Replikat zu wenig Speicherplatz verfügbar ist, fügen Sie freien Speicherplatz hinzu, und starten Sie das Seeding durch Ausführen von ALTER AVAILABILITY GROUP ... WITH (SEEDING_MODE=AUTOMATIC) erneut.

Automatisches Seeding stoppen

Um das automatische Seeding für eine Verfügbarkeitsgruppe zu beenden, führen Sie das folgende Skript auf dem primären Replikat aus:

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    MODIFY REPLICA ON '<secondary_node>'   
    WITH (SEEDING_MODE = MANUAL)
GO

Durch das vorherige Skript werden alle Replikate, für die das Seeding derzeit aktiviert ist, abgebrochen, und es wird verhindert, dass SQL Server automatisch ein Replikat in dieser Verfügbarkeitsgruppe initialisiert. Die Synchronisierung für Replikate, die bereits initialisiert wurden, wird hierdurch nicht beendet.

Überwachung des automatischen Seedings einer Verfügbarkeitsgruppe

Verwenden Sie die dynamischen Systemverwaltungssichten (DMVs) zur Überwachung des Seedings

Die folgenden Systemsichten zeigen den Status des automatischen Seedings in SQL Server.

sys.dm_hadr_automatic_seeding

Fragen Sie auf dem primären Replikat sys.dm_hadr_automatic_seeding ab, um den Status des automatischen Seedingvorgangs zu prüfen. Die Ansicht gibt eine Zeile pro Seeding-Prozess zurück. Zum Beispiel:

SELECT start_time, 
    completion_time
    is_source,
    current_state,
    failure_state,
    failure_state_desc
FROM sys.dm_hadr_automatic_seeding

sys.dm_hadr_physical_seeding_stats

Fragen Sie auf dem primären Replikat die DMV sys.dm_hadr_physical_seeding_stats ab, um die physischen Statistiken für jeden aktuell ausgeführten Seedingprozess anzuzeigen. Die folgende Abfrage gibt Zeilen zurück, wenn das Seeding ausgeführt wird:

SELECT * FROM sys.dm_hadr_physical_seeding_stats;

Die beiden Spalten total_disk_io_wait_time_ms und die total_network_wait_time_ms können zur Ermittlung von Leistungsengpässen im Prozess des automatischen Seedings verwendet werden. Die zwei Spalten sind auch in dem erweiterten Ereignis hadr_physical_seeding_progress vorhanden.

• total_disk_io_wait_time_ms stellt die Zeit dar, die der Sicherungs- bzw. Wiederherstellungsthread auf den Datenträger wartet. Dieser Wert ist von Beginn des Seedingvorgangs an kumulativ. Wenn die Datenträger nicht für das Lesen oder Schreiben des Sicherungsdatenstroms bereit sind, geht der Sicherungs- bzw. Wiederherstellungsthread in einen Ruhezustand über und reaktiviert sich jede Sekunde, um zu überprüfen, ob der Datenträger bereit ist.

• total_network_wait_time_ms wird für das primäre und sekundäre Replikat anders interpretiert. Auf dem primären Replikat stellt dieser Zähler die Zeit der Netzwerkflusssteuerung dar. Auf dem sekundären Replikat stellt er die Zeit dar, die der Wiederherstellungsthread auf eine verfügbare Nachricht zum Schreiben auf den Datenträger wartet.

Diagnostizieren Sie die Datenbankinitialisierung mit automatischem Seeding im Fehlerprotokoll

Wenn Sie eine Datenbank zu einer Verfügbarkeitsgruppe hinzufügen, die für das automatische Seeding konfiguriert ist, führt SQL Server eine VDI-Sicherung über den Endpunkt der Verfügbarkeitsgruppe aus. Überprüfen Sie das SQL Server-Fehlerprotokoll auf Informationen darüber, wann die Sicherung abgeschlossen und die sekundäre Datenbank synchronisiert wurde.

Den Zustand auf Datenbankebene mit erweiterten Ereignissen diagnostizieren

Das automatische Seeding umfasst neue erweiterte Ereignisse zum Nachverfolgen von Zustandsänderungen, Fehlern und Leistungsstatistiken während der Initialisierung.

Dieses Skript erstellt z. B. eine Sitzung für erweiterte Ereignisse, die Ereignisse im Zusammenhang mit automatischem Seeding erfasst:

CREATE EVENT SESSION [AlwaysOn_autoseed] ON SERVER 
    ADD EVENT sqlserver.hadr_automatic_seeding_state_transition,
    ADD EVENT sqlserver.hadr_automatic_seeding_timeout,
    ADD EVENT sqlserver.hadr_db_manager_seeding_request_msg,
    ADD EVENT sqlserver.hadr_physical_seeding_backup_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_failure,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_target_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_progress,
    ADD EVENT sqlserver.hadr_physical_seeding_restore_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_submit_callback
    ADD TARGET package0.event_file(
        SET filename=N'autoseed.xel',
            max_file_size=(5),
            max_rollover_files=(4)
        )
WITH (
    MAX_MEMORY=4096 KB,
    EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB,
    MEMORY_PARTITION_MODE=NONE,
    TRACK_CAUSALITY=OFF,
    STARTUP_STATE=ON
    )
GO 

ALTER EVENT SESSION AlwaysOn_autoseed ON SERVER STATE=START
GO 

Die folgende Tabelle enthält die erweiterten Ereignisse die sich auf automatisches Seeding beziehen:

Weitere Überlegungen zur Problembehandlung

Überwachen, wann die automatische Verteilung erfolgt

Fragen Sie mit sys.dm_hadr_physical_seeding_stats derzeit ausgeführte automatische Seedingprozesse ab. Die Sicht gibt für jede Datenbank eine Zeile zurück. Zum Beispiel:

SELECT local_database_name, 
    role_desc, 
    internal_state_desc, 
    transfer_rate_bytes_per_second, 
    transferred_size_bytes, 
    database_size_bytes, 
    start_time_utc, 
    end_time_utc, estimate_time_complete_utc, 
    total_disk_io_wait_time_ms, 
    total_network_wait_time_ms, 
    is_compression_enabled 
FROM sys.dm_hadr_physical_seeding_stats

Problembehandlung: Warum wird eine Datenbank in einer Verfügbarkeitsgruppe, die für das automatische Seeding konfiguriert ist, nicht angezeigt?

Wenn eine Datenbank nicht als Teil einer Verfügbarkeitsgruppe mit aktiviertem automatischen Seeding angezeigt wird, ist beim automatischen Seeding wahrscheinlich ein Fehler aufgetreten. Dadurch wird verhindert, dass die Datenbank zur Verfügbarkeitsgruppe auf dem primären oder sekundären Replikat hinzugefügt wird. Führen Sie eine Abfrage für sys.dm_hadr_automatic_seeding sowohl auf den primären als auch auf den sekundären Replikaten aus. Führen Sie z. B. die folgende Abfrage aus, um einen Fehlerzustand des automatischen Seedings zu identifizieren.

SELECT start_time, 
    completion_time, 
    is_source, 
    current_state, 
    failure_state, 
    failure_state_desc, 
    error_code 
FROM sys.dm_hadr_automatic_seeding

Automatisches Seeding und Leistungsüberlegungen

SQL Server verwendet eine feste Anzahl von Threads für das automatische Seeding. In der primären Instanz verwendet SQL Server einen Thread pro LUN zum Lesen von Änderungen. In der sekundären Instanz verwendet SQL Server einen Thread pro LUN zum Initialisieren der Datenbank.

Legen Sie Traceflag 9567 auf dem primären Replikat fest, um die Komprimierung des Datenstroms während des automatischen Initialisierens zu aktivieren. Dadurch lässt sich die Übertragungsdauer des automatischen Seedings deutlich verringern, allerdings erhöht sich die CPU-Nutzung. Weitere Informationen finden Sie unter Optimieren der Komprimierung für die Verfügbarkeitsgruppe.

Wann Sie das automatische Seeding nicht verwenden sollten

In einigen Szenarien ist das automatische Seeding möglicherweise keine Optimale Lösung zum Initialisieren eines sekundären Replikats. Während des automatischen Seedings führt SQL Server für die Initialisierung eine Sicherung über das Netzwerk aus. Dieser Prozess kann langsam sein, wenn die Datenbanken sehr groß sind oder das sekundäre Replikat remote gespeichert wird. Das Transaktionsprotokoll für diese Datenbanken kann während des Sicherungsvorgangs nicht gekürzt werden, sodass ein längerer Initialisierungsprozess bei einer stark ausgelasteten Datenbank zu einem erheblichen Anwachsen des Transaktionsprotokolls führen kann. Vor dem Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe mit automatischem Seeding sollten Sie daher Datenbankgröße, Last und Standortabstand zwischen den Replikaten untersuchen.

Siehe auch

• CREATE AVAILABILITY GROUP (Transact-SQL)
• Verfügbarkeitsgruppen überwachen und Probleme behandeln