Das Spiegeln von Datenbanken ist definitiv mein “Hochverfügbarkeits – Lieblingsfeature”. Sofern die Datenbanken bereits auf dem Zielserver im NoRecovery Modus wiederhergestellt wurden, dauert das Einrichten keine 10 Sekunden. Nur eines scheitert gerne.. den Failover zu starten. Was kann denn in diesen 10 Sekunden passiert sein.. Der Assistent zum Einrichten der Spiegelung erledigt folgende Dinge:
– Anlegen der Spiegelungsendpunkte (Ein Listener auf normalerweise TCP Port 5022) auf allen beteiligten Servern (Prinzipal, Spiegelpartner, Zeuge)
– Und dann gab es da noch eine bescheidene Frage nach den Dienstkonten, die ein CONNECT Recht benötigen würden.
Meist wird das Einrichten mit folgender Fehlermeldung – Error 1418 – quittiert:
Die Server-Netzwerkadresse TCP://Server:5022 ist nicht erreichbar oder nicht vorhanden. Überprüfen Sie den Namen der Netzwerkadresse, und dass die Ports für die lokalen und Remoteendpunkte betriebsbereit sind.
Um das Einrichten des Assistenten zu kontrollieren, kann man nun folgende Dinge tun:
Das erreicht man am besten über den Kommandokonsolenbefehl netstat
zB. netstat –an oder netstat –ano für zusätzlich Information wie Besitzer des Ports bzw netstat –anb für die Prozess-Id
Es sollte in der Liste auf jeden Fall ein 0.0.0.0:5022 [Abhören] auftauchen.
Die Endpunkte müssen gestartet sein. Dies kann man sehr leicht durch folgendes Skript lösen:
SELECT state, state_desc from sys.database_mirroring_endpoints
In den Spalten sollte ein Started zu finden sein.
Ein Endpunkt läßt sich auch per Skript einrichten (ist auf jedem Server auszuführen)
CREATE ENDPOINT Endpoint_Mirroring STATE=STARTED AS TCP (LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=ALL); –ALL auf Spiegel; PARTNER auf Prinzipal; WITNESS auf Zeugen GO
Dies ist genau der Punkt an dem Spiegelung im SQL Server Management Studio später versagen wird. Die Dienstkonten benötigen ein Connect Recht auf die jeweiligen Endpunkte. Das muss jedem Endpunkt, also allen beteiligten Server eingerichtet werden.
Mit folgenden Skript lässt sich auch dieses Problem lösen:
--Dienstkonten für die Spiegelung müssen ein Login besitzen, falls nicht vorhanden.. CREATE LOGIN [DomäneUser] FROM WINDOWS --Zugriffsrechte auf Spiegelungsendpunkt geben GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO DomäneUser
Das Spiegeln muss natürlich anschließend gestartet werden. Entweder per SSMS oder auch per Skript:
--Auf Spiegel anschließend auf Prinzipal ALTER DATABASE Datenbank SET PARTNER = 'TCP://PARTNERHOST1.COM:5022'; GO --Zeuge in Betrieb nehmen ALTER DATABASE Datenbank SET WITNESS = 'TCP://WITNESSHOST4.COM:5022'; GO
Sollte es dann immer noch scheitern, nochmals gründlich die Firewall prüfen!
– Das Wiederherstellungsmodell muss auf FULL (Vollständig) gesetzt sein
– Das Vollständige Backup sollte inkl. Transaktionsprotokollsicherung auf dem Spiegelpartner im Modus NoRecovery wiederhergestellt werden.
– Die Dienstkonten sind im günstigsten Fall auf allen Maschinen die gleichen Windows Konten.
Falls eine Meldung erscheinen sollte, dass Spiegelung zuvor entfernt werden sollte… bitte sehr! Und für den Fall der Fälle.. der manuelle Failover.
--Entfernen der Spiegelung ALTER DATABASE Datenbank SET PARTNER OFF --Manueller Failover ALTER DATABASE Datenbank SET PARTNER FAIlLOVER
Anschließend eine Überprüfung des Status der Spiegelung
SELECT db.name, m.mirroring_role_desc FROM sys.database_mirroring m JOIN sys.databases db ON db.database_id = m.database_id WHERE db.name = Datenbank; GO
In SQL Server 2016 wurde das sog. dynamic data masking eingeführt. Eine Möglichkeit Daten bei…
Seit Sharepoint Server 2007 präsentiert sich die Installation immer auf die gleiche Weise. Gerade mal,…
Es weihnachtet! Gerade bekam ich von einer Kollegin Plätzchen angeboten mit der Größe eines Diskus…
Nein, bitte nicht verwechseln: temporal tables haben nichts zu tun mit temporary tables table variables…
SQL Server 2016.. habe ich schon erwähnt, dass ich den ziemlich cool finde? Wollen wir…
Nach langer Zeit wieder mal eine Artikel von mir.. der mich besonders erfreut. SQL Server…
View Comments