Ich richte eine HA SQL Server-Umgebung ein, die auf drei SQL Server 2008 R2-Computern und Datenbankspiegelung basiert.
Ich werde sie nennen:
- Principal.Company.Intra
- mirror.company.intra
- zeugen.unternehmen.intra
Die Domain "company.intra" ist die Domain der Holding.
Beide Datenbankmodule überwachen den statischen 52002-Port, sodass Clientanwendungen auf folgende Weise auf sie zugreifen können:
principal.company.intra,52002 & mirror.company.intra,52002Endpunkte werden EP_Mirroringbeim Principal und Mirror, EP_Witnessbeim Zeugen aufgerufen und am 5022-Port beim Principal, 5023 beim Mirror und 5024 beim Zeugen abgehört.
Dienstkonten sind korrekt konfiguriert und erhalten Verbindungsberechtigungen für die Endpunkte des jeweils anderen.
Die Spiegelungsfunktion funktioniert einwandfrei und das Datenbank-Failover ist korrekt, wenn ein manuelles TSQL-Failover oder ein simulierter Systemfehler vorliegt.
Das Problem besteht darin, dass sich Anwendungen beim Failover seltsam verhalten.
Der Kontext für Anwendungstests ist folgender:
Eine kleine .NET-App bestehend aus zwei Textfeldern und einer Schaltfläche:
Wenn auf die Schaltfläche geklickt wird, wird ein gespeicherter Proc-Aufruf ausgeführt und Textbox1 mit der Ausgabe des SP und Textbox2 mit der Datenquelleneigenschaft von my gefüllt SqlConnection.
Die Verbindungszeichenfolge sieht folgendermaßen aus:
Data source=principal.company.intra,52002;failover partner=mirror.company.intra,52002;
initial catalog = TEST_FAILOVER;user ID=user;password=pass;Connection Timeout=30
Ich habe diese App von meinem Laptop aus gestartet, der sich in einer anderen Domain befindet: laptop.childcompany.com
Szenario 1 :
- Ich starte die App
- Taste gedrückt, TB1: SP-Ausgabe / TB2: Principal.Company.Intra, 52002
- Datenbank-Failover
- Taste gedrückt, Verbindungszeitüberschreitung
- Taste gedrückt, Verbindungszeitüberschreitung
- DB-Failover am Spiegel (zurück zum Prinzipal)
- Taste gedrückt, TB1: SP-Ausgabe / TB2: Principal.Company.Intra, 52002
Szenario 2 :
- Datenbank-Failover
- App starten
- Taste gedrückt, TB1: SP-Ausgabe / TB2: Mirror.Company.Intra, 52002
- Datenbank-Failover am Spiegel (zurück zum Prinzipal)
- Taste gedrückt, Verbindungsfehler
- Taste gedrückt, TB1: SP-Ausgabe / TB2: Principal.Company.Intra, 52002
- Datenbank-Failover
- Taste gedrückt, Verbindungszeitüberschreitung
- Taste gedrückt, Verbindungszeitüberschreitung
Ich habe dann versucht, die App auf dem Spiegelserver lokal über RDP zu starten
Szenario 3
- App starten
- Taste gedrückt, TB1: SP-Ausgabe / TB2: Principal.Company.Intra, 52002
- Datenbank-Failover
- Taste gedrückt, Verbindungsfehler
- Taste gedrückt, TB1: SP-Ausgang / TB2: SPIEGEL
Ich habe MSDN auf das Verhalten der Ole DB-Konnektivität im Falle eines Failovers überprüft, um zu verstehen, warum im dritten Szenario die Datenquelleneigenschaft meiner Verbindung auf MIRRORund nicht festgelegt wurdemirror.company.holding,52002
Ich habe erfahren, dass die Failover-Server-Eigenschaft meiner Verbindungszeichenfolge nur für den Fall verwendet wird, dass eine anfängliche Verbindung zum Principal fehlschlägt (was erklärt, warum Szenario 2 ordnungsgemäß funktioniert hat), dass der Principal-Server jedoch für den Fall einer vorhandenen Verbindung bereits bereitgestellt hat die App mit der Spiegelserveradresse (in einem sogenannten "Failover-Cache"); Die angegebenen Informationen sind falsch, keine Überwachungsportinformationen und kein Hostname anstelle des vollqualifizierten Domänennamens, wodurch außerhalb der Domäne der Holdinggesellschaft ein Fehler auftritt.
Im nächsten Schritt habe ich die Ansicht sys.database_mirroring überprüft:
select M.*
from sys.databases D
inner join sys.database_mirroring M on D.database_id = M.database_id
where D.name = 'TEST_FAILOVER'
Und festgestellt, dass das Feld "mirrororing_partner_instance" "MIRROR" anstelle von "mirror.company.intra, 52002" enthält.
Bei einer kurzen Überprüfung von Books Online wurde mir mitgeteilt, dass in diesem Feld Client-Apps des Failover-Partners bei der ersten Verbindung mit der Haupt-DB-Engine informiert werden.
Schließlich lautet meine Frage:
Gibt es eine Möglichkeit, dieses Verhalten zu korrigieren und das Feld "mirrororing_partner_instance" dazu zu bringen, den vollqualifizierten Domänennamen des Spiegels mit dem Überwachungsport zu speichern?
Bei der Endpunkterstellung? Auf Spiegelung der Konfigurationsebene (über eine Änderung der Datenbankanweisung)? DB Engine Konfiguration?
Ich habe bereits erfolgreich versucht, einen SQL Server Native-Clientalias auf Clientcomputern als Problemumgehung einzurichten. Ich würde es jedoch wirklich vorziehen, wenn der Hauptserver die richtigen Failover-Informationen an Clientanwendungen zurückgibt.