Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Microsoft SQL Server Always On-Verfügbarkeitsgruppen (AG) bieten für geschäftskritische Datenbanken Hochverfügbarkeit und Notfallwiederherstellung. Gleichzeitig unterstützt die SQL Server-Replikation Datenverteilung, Auslagerung von Berichtsabfragen, inkrementelle Synchronisierung und serverübergreifende Datenkonsolidierung.
In den meisten Unternehmensumgebungen werden diese beiden Technologien kombiniert, um ausfallsichere Datenpipelines aufzubauen, die auch nach einem Failover eines Replikats ohne Unterbrechung der nachgelagerten Abonnenten weiterlaufen.
Datenbankadministratoren stoßen jedoch häufig auf Probleme aufgrund nativer Einschränkungen zwischen Verfügbarkeitsgruppen und Replikation. Standardmäßig können in AGs gehostete Datenbanken nicht direkt als Replikationsverleger konfiguriert werden. Ohne korrekte Einrichtung kann die Replikation nach einem automatischen oder manuellen Failover vollständig ausfallen.
Dieser Leitfaden erläutert die Konfiguration der Replikation mit Always On-Verfügbarkeitsgruppen. Er umfasst erforderliche Voraussetzungen, detaillierte Schritte und häufige Laufzeitprobleme.
Bevor Sie beginnen, informieren Sie sich über unterstützte Szenarien und Einschränkungen von Always On AG und SQL Server-Replikation:
Unterstützte Replikationstypen:
Nicht unterstützte und inkompatible Replikationsszenarien:
Microsoft schränkt ausdrücklich folgende Replikationstopologien mit AG-gehosteten Datenbanken ein:
Wichtige Architekturregeln:
Falls Always On AG Ihren Anforderungen genügt, stellen wir in diesem Artikel zudem eine einfachere und leistungsstärkere alternative Replikationslösung vor.
Bevor Sie mit der Einrichtung beginnen, stellen Sie sicher, dass alle infrastrukturellen, editionsbezogenen und konfigurationstechnischen Voraussetzungen erfüllt sind.
1. Auf allen Knoten der Verfügbarkeitsgruppe ist die SQL Server Enterprise Edition erforderlich. Die grundlegende Integration von AG und Replikation wird ab SQL Server 2016 vollständig unterstützt. Hochverfügbarkeit der Verteilerdatenbank über Verfügbarkeitsgruppen wird ab SQL Server 2016 SP2 CU3, SQL Server 2017 CU6 und allen späteren Versionen unterstützt.
2. Ihre AG muss vollständig konfiguriert sein mit fehlerfreien Primär- und Sekundärreplikaten, synchronisierten Benutzerdatenbanken und unbehandelten AG-Gesundheitswarnungen.
3. Das SQL Server-Replikationsfeature muss auf jedem Knoten des Verfügbarkeitsgruppenclusters installiert sein, nicht nur auf dem Primärreplikaten. Replikationsagenten und Metadaten erfordern konsistente Binärdateien auf allen potenziellen Failover-Verlegern.
4. Ein eigenständiger entfernter SQL Server-Verteiler wird für den Produktivbetrieb dringend empfohlen. Lokale Verteiler werden zwar unterstützt, heben jedoch die Trennung der Hochverfügbarkeit auf und erhöhen die Komplexität. Der Verteiler verwaltet alle Replikationsmetadaten, Agent-Jobs und die Übermittlung von Transaktionsprotokollen.
5. Ein DNS-benannter Verfügbarkeitsgruppen-Listener ist für diese Integration zwingend erforderlich. Der Listener stellt einen statischen Netzwerkendpunkt bereit, der während eines AG-Failovers unverändert bleibt und eine transparente Umleitung des Replikationsverlegers ermöglicht.
6. Sicherheits- und Netzwerkberechtigungen müssen korrekt konfiguriert sein.
7. AG-Benutzerdatenbanken müssen das Wiederherstellungsmodell VOLL verwenden mit konfigurierten Transaktionsprotokollsicherungen, um das Auslesen von Protokollen für die Transaktionsreplikation zu unterstützen.
Führen Sie folgende Schritte in Ihrer SQL Server-Umgebung durch.
Der Verteiler ist das Herzstück der Replikation. Er speichert die Verteilerdatenbank mit Metadaten und Transaktionsbefehlen. So richten Sie den Replikationsverteiler und die Verteilerdatenbank ein:
► Variante A: Eigenständiger Verteiler (alle unterstützten Versionen)
1. Stellen Sie in SQL Server Management Studio (SSMS) eine Verbindung zur Verteilerinstanz her.
2. Klicken Sie mit der rechten Maustaste auf Replikation und wählen Sie Verteilung konfigurieren aus.
3. Folgen Sie dem Assistenten, um die Instanz als eigenen Verteiler festzulegen, einen Snapshot-Ordner anzugeben und die Verteilerdatenbank zu erstellen.
4. Alternativ mit T-SQL:
USE master;
GO
EXEC sp_adddistributor @distributor = @@SERVERNAME, @password = N'SicheresPasswort!';
GO
EXEC sp_adddistributiondb @database = N'distribution';
GO
► Variante B: Verteilerdatenbank in einer Verfügbarkeitsgruppe (SQL Server 2016 SP2-CU3+ / 2017 CU6+)
Falls Sie Hochverfügbarkeit für den Verteiler benötigen, können Sie die Verteilerdatenbank in eine eigene AG einbinden. Diese Konfiguration erfordert eine sorgfältige Einrichtung, wobei die zentrale Voraussetzung lautet, dass Verleger und Verteiler auf separaten SQL Server-Instanzen laufen müssen. Die AG der Verteilerdatenbank benötigt einen eigenen Listener.
Nachdem der Verteiler eingerichtet ist, konfigurieren Sie die Datenbank für die Veröffentlichung auf dem aktuellen Primärreplikaten.
1. Stellen Sie eine Verbindung zur Instanz des Primärreplikats her.
2. Aktivieren Sie die Datenbank für die Transaktionsreplikation:
USE [IhreDatenbank];
GO
EXEC sp_replicationdboption
@dbname = N'IhreDatenbank',
@optname = N'publish',
@value = N'true';
GO
3. Erstellen Sie die Veröffentlichung. Wichtig: Nutzen Sie an dieser Stelle noch den physischen Servernamen des Primärreplikats, nicht den AG-Listener. Die Umleitung zum Listener erfolgt in einem späteren Schritt.
USE [IhreDatenbank];
GO
EXEC sp_addpublication
@publication = N'IhreVeröffentlichung',
@description = N'Transaktionsveröffentlichung der Datenbank.',
@sync_method = N'concurrent',
@retention = 336,
@allow_push = N'true',
@allow_pull = N'true',
@allow_anonymous = N'false',
@enabled_for_internet = N'false',
@snapshot_in_defaultfolder = N'true',
@compress_snapshot = N'false',
@ftp_port = 21,
@allow_subscription_copy = N'false',
@add_to_active_directory = N'false',
@repl_freq = N'continuous',
@status = N'active',
@independent_agent = N'true',
@immediate_sync = N'true',
@allow_sync_tran = N'false',
@autogen_sync_procs = N'false',
@allow_queued_tran = N'false',
@allow_dts = N'false',
@replicate_ddl = 1,
@allow_initialize_from_backup = N'true',
@enabled_for_p2p = N'false',
@enabled_for_het_sub = N'false';
GO
4. Fügen Sie Artikel (Tabellen, Sichten usw.) zur Veröffentlichung hinzu:
USE [IhreDatenbank];
GO
EXEC sp_addarticle
@publication = N'IhreVeröffentlichung',
@article = N'IhreTabelle',
@source_owner = N'dbo',
@source_object = N'IhreTabelle',
@type = N'logbased',
@description = NULL,
@creation_script = NULL,
@pre_creation_cmd = N'drop',
@schema_option = 0x000000000803509F,
@identityrangemanagementoption = N'none',
@destination_table = N'IhreTabelle',
@destination_owner = N'dbo',
@status = 24;
GO
— Wiederholen Sie diesen Befehl für jede zu replizierende Tabelle
Jedes Sekundärreplikat, das nach einem Failover zum Primär werden kann, muss ordnungsgemäß für die Ausführung der Veröffentlichung konfiguriert sein.
Führen Sie auf jedem Host des Sekundärreplikats folgende Aktionen durch:
1. Hinzufügen des Verteilers (falls noch nicht vorhanden):
USE master;
GO
EXEC sp_adddistributor
@distributor = N'IhrVerteilerServerName',
@password = N'SicheresPasswort!';
GO
2. Registrieren jedes Sekundärreplikats beim Verteiler. Führen Sie diesen Befehl auf der Verteilerinstanz aus:
USE distribution;
GO
EXEC sp_adddistpublisher
@publisher = N'SekundärReplikatHostName', -- Physikalischer Servername des Sekundärreplikats
@distribution_db = N'distribution',
@working_directory = N'\\Netzwerkfreigabe\ReplData',
@security_mode = 1, -- 1 = Windows-Authentifizierung
@trusted = N'false',
@thirdparty_flag = 0,
@publisher_type = N'MSSQLSERVER';
GO
— Wiederholen für jedes Sekundärreplikat, das potenzieller Verleger wird
3. Hinzufügen des Abonnenten als verknüpfter Server auf jedem Sekundärreplikat (erforderlich für Push-Abonnements):
— Auf jedem Sekundärreplikat ausführen
EXEC sp_addlinkedserver
@server = N'AbonnentServerName',
@srvproduct = N'SQL Server';
GO
Dieser Schritt schließt die Einrichtung auf den Sekundärreplikaten ab, sodass diese vollständig als Verleger agieren können.
Führen Sie auf jedem Host des Sekundärreplikats folgenden Befehl aus:
-- Dieser Schritt registriert die Veröffentlichung auf dem Sekundärreplikat
USE [IhreDatenbank];
GO
EXEC sp_replicationdboption
@dbname = N'IhreDatenbank',
@optname = N'publish',
@value = N'true';
GO
Hinweis: Versuchen Sie nicht, die Veröffentlichung auf dem Sekundärreplikat neu zu erstellen. Die Veröffentlichung ist bereits in der Datenbank vorhanden und wird erkannt, sobald die Datenbank zum Primär wird.
Dies ist der entscheidende Schritt für einen nahtlosen Failover. Er teilt dem Verteiler mit, dass er bei Nichterreichbarkeit des ursprünglichen Verlegers stattdessen eine Verbindung zum AG-Listener herstellen soll.
Führen Sie diesen Befehl auf der Verteilerinstanz in der Datenbank distribution aus:
USE distribution;
GO
EXEC sys.sp_redirect_publisher
@original_publisher = N'PhysikalischerPrimärServerName', -- Hostname des ursprünglichen Primärreplikats
@publisher_db = N'IhreDatenbank',
@redirected_publisher = N'IhrAGListenerName'; -- Bei nicht standardmäßigem Port kann dieser ergänzt werden, z. B. 'Listener,2233'
GO
Überprüfen der Umleitung:
USE distribution;
GO
SELECT * FROM MSredirected_publishers;
GO
Bevor Sie Abonnements erstellen, empfiehlt Microsoft die Prüfung, ob alle Replikate ordnungsgemäß als Verleger konfiguriert sind.
Führen Sie diese Validierung auf dem Verteiler aus:
USE distribution;
GO
DECLARE @redirected_publisher sysname;
EXEC sys.sp_validate_replica_hosts_as_publishers
@original_publisher = N'PhysikalischerPrimärServerName',
@publisher_db = N'IhreDatenbank',
@redirected_publisher = @redirected_publisher OUTPUT;
GO
Gibt die Validierung Fehler zurück, prüfen Sie die vorherigen Schritte, um sicherzustellen, dass alle Sekundärreplikate korrekt beim Verteiler registriert und die Veröffentlichungsdatenbanken für die Veröffentlichung aktiviert sind.
Erstellen Sie nun das Abonnement. Hierfür müssen T-SQL-Skripte verwendet werden; der SSMS-Assistent verarbeitet AG-Listener-Szenarien nicht korrekt.
►Variante A: Push-Abonnement (empfohlen für AG-Abonnenten)
Erstellen Sie das Push-Abonnement auf dem Verleger unter Angabe des AG-Listener-Namens des Abonnenten (falls die Abonnentendatenbank sich in einer AG befindet) oder des physischen Servernamens (falls nicht).
-- Auf dem Verleger (Primärreplikat) ausführen
GO
-- Hinzufügen des Abonnements
EXEC sp_addsubscription
@publication = N'IhreVeröffentlichung',
@subscriber = N'AbonnentAGListenerName', -- Nutzen Sie den Listener, falls der Abonnent in einer AG ist
@destination_db = N'AbonnentDatenbank',
@subscription_type = N'Push',
@sync_type = N'automatic',
@article = N'all',
@update_mode = N'read only',
@subscriber_type = 0;
GO
-- Hinzufügen des Verteilungsagent-Jobs
EXEC sp_addpushsubscription_agent
@publication = N'IhreVeröffentlichung',
@subscriber = N'AbonnentAGListenerName',
@subscriber_db = N'AbonnentDatenbank',
@job_login = N'DOMÄNE\ReplAgentKonto',
@job_password = N'SicheresPasswort!',
@subscriber_security_mode = 1, -- 1 = Windows-Authentifizierung
@frequency_type = 64, -- 64 = Kontinuierlich
@frequency_interval = 0,
@frequency_relative_interval = 0,
@frequency_recurrence_factor = 0,
@frequency_subday = 0,
@frequency_subday_interval = 0,
@active_start_time_of_day = 0,
@active_end_time_of_day = 235959,
@active_start_date = 20240101,
@active_end_date = 99991231,
@dts_package_location = N'Distributor';
GO
►Variante B: Pull-Abonnement
Pull-Abonnements werden auf dem Abonnenten erstellt. Geben Sie den AG-Listener-Namen des Verlegers an.
-- Auf dem Abonnenten ausführen
USE [AbonnentDatenbank];
GO
-- Hinzufügen des Pull-Abonnements
EXEC sp_addpullsubscription
@publisher = N'IhrAGListenerName', -- AG-Listener des Verlegers
@publication = N'IhreVeröffentlichung',
@publisher_db = N'IhreDatenbank',
@independent_agent = N'True';
GO
-- Hinzufügen des Verteilungsagent-Jobs auf dem Abonnenten
EXEC sp_addpullsubscription_agent
@publisher = N'IhrAGListenerName',
@publisher_db = N'IhreDatenbank',
@publication = N'IhreVeröffentlichung',
@distributor = N'IhrVerteilerServerName',
@distributor_security_mode = 1,
@distributor_login = N'',
@distributor_password = N'',
@enabled_for_syncmgr = N'False',
@frequency_type = 64,
@frequency_interval = 0,
@frequency_relative_interval = 0,
@frequency_recurrence_factor = 0,
@frequency_subday = 0,
@frequency_subday_interval = 0,
@active_start_time_of_day = 0,
@active_end_time_of_day = 235959,
@active_start_date = 20240101,
@active_end_date = 99991231,
@alt_snapshot_folder = N'',
@working_directory = N'';
GO
Wenn Sie ein Pull-Abonnement erstellen und sich die Abonnentendatenbank in einer AG befindet, wird der Verteilungsagent-Job nur auf dem aktuellen Primärreplikat der Abonnenten-AG erstellt. Nach einem Failover der Abonnenten-AG läuft die Replikation automatisch weiter, solange der ursprüngliche Abonnentenserver funktionsfähig bleibt (der Job wird dort weiterhin ausgeführt).
Für langfristige Stabilität sollten Sie den Job auf dem alten Primär jedoch später deaktivieren und auf dem neuen Primär aktivieren bzw. neu erstellen. Einzelheiten finden Sie im Abschnitt „Verwaltung nach Failover“.
Generieren Sie den anfänglichen Snapshot, um den Abonnenten zu synchronisieren.
-- Auf dem Verleger (Primärreplikat) ausführen
USE [IhreDatenbank];
GO
EXEC sp_startpublication_snapshot @publication = N'IhreVeröffentlichung';
GO
Überwachen Sie die Erstellung und Übermittlung des Snapshots im Replikationsmonitor oder durch Abfrage der Tabelle MSsnapshot_history in der Datenbank distribution.
Für eine einfachere Überwachung fügen Sie den ursprünglichen Verleger zum Replikationsmonitor hinzu:
1. Stellen Sie in SSMS eine Verbindung zur Verteilerinstanz her.
2. Erweitern Sie den Knoten Replikation, klicken Sie mit der rechten Maustaste auf Replikationsmonitor und wählen Sie Verleger hinzufügen aus.
3. Geben Sie den ursprünglichen physischen Servernamen des Verlegers ein. Der Replikationsmonitor erkennt automatisch den umgeleiteten Verleger und zeigt die korrekten Informationen an.
Hinweis: Nach einem Failover zeigt der Replikationsmonitor ggf. weiterhin den Namen des ursprünglichen Primärs an, die Funktionalität der Replikation bleibt hiervon jedoch unbeeinträchtigt.
Obwohl Always On-Verfügbarkeitsgruppen Hochverfügbarkeit bieten, ist die Integration von Verfügbarkeitsgruppen mit Replikationstechnologien ein komplexer Vorgang. Wenn Ihre Anforderungen eine Lese-Schreib-Trennung, visuelle Berichterstellung oder heterogene Datenintegration mittels Datenverteilung umfassen, empfehlen wir eine professionelle Datenbank-Replikationslösung.
i2Stream stellt eine unternehmensgeeignete professionelle Alternative dar, die die Einschränkungen beseitigt, mit denen Unternehmen bei der Erweiterung von Always On AGs über reine Hochverfügbarkeitsszenarien hinaus konfrontiert sind. Es ist keine Enterprise-Edition erforderlich und die Lösung ist nicht auf Windows-Cluster angewiesen.
Hauptfunktionen und Vorteile von i2Stream:
Klicken Sie unten auf die Schaltfläche für die kostenlose Testversion. Wir melden uns bald bei Ihnen, unterstützen Sie bei der Bereitstellung in Ihrer Umgebung und zeigen Ihnen die Bedienung.
Symptome: Der Protokolllese-Agent oder Verteilungsagent gibt nach einem AG-Failover Verbindungsfehler aus.
Häufige Ursachen:
Lösung:
Symptome: Transaktionen werden nicht repliziert, es treten Fehler zu nicht übergebenen Transaktionen auf.
Häufige Ursachen: Die Verteilerdatenbank ist nicht ordnungsgemäß synchronisiert oder es treten Konflikte während der AG-Synchronisierung auf.
Lösung:
Symptome: Der Snapshot-Agent gibt bei in einer AG eingebundenen Datenbanken Fehler wie „Agent-Status konnte nicht abgerufen werden“ aus.
Häufige Ursachen: Die Datenbank wurde der AG hinzugefügt, bevor die Replikation vollständig konfiguriert wurde, oder es wird eine Contained AG verwendet (SQL Server 2022).
Lösung:
Symptome: Nach einem Failover versucht der Protokolllese-Agent weiterhin eine Verbindung zum ehemaligen Primärreplikat herzustellen.
Häufige Ursachen: sp_redirect_publisher wurde auf der falschen Datenbank oder mit fehlerhaften Parametern ausgeführt.
Lösung:
1. Auf dem Verteiler in der Datenbank distribution die Umleitung prüfen:
SELECT * FROM MSredirected_publishers;
2. Bei fehlerhafter Konfiguration die Umleitung entfernen und neu erstellen:
EXEC sys.sp_redirect_publisher
@original_publisher = N'PhysikalischerServerName',
@publisher_db = N'IhreDatenbank',
@redirected_publisher = N'AGListenerName';
3. Neustarten des Protokolllese-Agent-Jobs
Symptome: Nach einem Failover werden alle Replikationsinformationen im Replikationsmonitor weiterhin unter dem Namen der ursprünglichen Primärinstanz angezeigt.
Erläuterung: Dies ist ein bekanntes Verhalten. Der Replikationsmonitor kann den Namen der veröffentlichenden Instanz nach einem Failover nicht anpassen und zeigt weiterhin den Namen des ursprünglichen Primärs an.
Lösung: Es handelt sich nur um eine optische Abweichung, die Funktionalität der Replikation bleibt unbeeinträchtigt. Über T-SQL eingegebene Ablaufverfolgungstoken auf dem neuen Verleger sind im Replikationsmonitor sichtbar.
Die Konfiguration der Replikation mit Always On-Verfügbarkeitsgruppen wandelt Ihre SQL Server-Infrastruktur von einer einfachen Hochverfügbarkeitslösung zu einer umfassenden Datenverteilungsplattform mit integrierter Ausfallsicherheit um.
Wenn Sie jedoch eine einfachere unternehmensgeeignete Datenbank-Replikationslösung wünschen, ist i2Stream die bessere Wahl. Es bietet nicht-intrusive CDC und eine agentenlose Architektur zur kontinuierlichen Datenreplikation zwischen unterschiedlichen Datenbankplattformen.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.
