Wir sind gerade dabei, unsere Produktionsumgebung für ein zukünftiges Webprodukt aufzubauen. Für diesen Stack wird ein primärer SQL Server 2008 für Live-Datenbankoperationen verwendet und ein sekundärer SQL Server 2008 erhält seine Daten vom primären SQL Server gespiegelt (über die integrierteSpiegelungFähigkeit). Wir lassen den Report Service auf dem sekundären SQL Server laufen und haben ihn als Hot-Standby, wenn der primäre SQL Server nicht verfügbar ist.
Auf Anwendungsebene haben wir zwei Optionen:
- Implementieren Sie die Fehlererkennung in der App-Ebene, sodass unser DAL den sekundären SQL Server trifft, wenn der primäre SQL Server nicht reagiert. ODER
- Lassen Sie die App-Ebene auf eine VIP verweisen und überlassen Sie die Fehlererkennung HAProxy.
Die Frage ist: Ist Option Nr. 2 eine praktikable Option?
HINWEIS: Wir sind uns bewusst, dass es andere Möglichkeiten gibt, Hochverfügbarkeit auf Datenbankebene bereitzustellen (z. B. Clustering), aber wir streben eine kostengünstige Lösung an.
Antwort1
Was meinen Sie mit „gespiegelten Daten“?
Sie können eine Datenbankspiegelung durchführen. In diesem Fall kann der Client (also Ihr DAL) den FailoverPartner in der Verbindungszeichenfolge verwenden, dem Failover-Ereignis folgen und eine Verbindung zum neuen Principal herstellen. Ihre Berichte würden auf Basis von Datenbank-Snapshots und nicht der Datenbank selbst ausgeführt, da die Spiegelung nicht verfügbar ist.
Sie können über einen Failovercluster verfügen, bei dem der Client zunächst eine Verbindung mit dem Ressourcennamen des Clusters herstellt und den Hostnamen des aktiven Knotens zunächst nicht kennt. Dadurch erhalten Sie jedoch keinen Zugriff auf die Daten des Standbypartners.
Sie können eine Hardwarespiegelung durchführen, aber das ist ein anderes Thema.
Manche sagen, Replikation sei eine Option. Ich gehöre nicht dazu.
Und... das ist im Grunde alles. Abgesehen davon, dass Sie Ihre eigene interne Datenspiegelungstechnologie entwickeln müssen, was auch immer das bedeutet.
Aktualisiert
Wenn Sie Datenbankspiegelung verwenden, geben Sie einfach den Failover-Partner in der Verbindungszeichenfolge an, sieheVerbinden von Clients mit einer gespiegelten Datenbank. Ihre Anwendung muss die Transaktionskonsistenz bei Failover-Ereignissen handhaben. Das Failover-Ereignis trennt die Clients abrupt und im Client-Code wird eine Ausnahme ausgelöst. Alle ausstehenden Transaktionen werden abgebrochen. Der Client-Code muss die Verbindung wiederherstellen, den persistenten Status lesen und die Arbeit ab dem in der Datenbank gefundenen Status fortsetzen. Korrekt geschriebene Anwendungen werden dies problemlos und problemlos handhaben.
Der Spiegel ist immer offline und kann nicht aufgerufen werden. Wenn Sie Berichte auf dem Spiegel ausführen möchten, müssen Sie einen Datenbank-Snapshot erstellen und die Berichte auf dem Snapshot ausführen. Der Snapshot muss regelmäßig aktualisiert (gelöscht und neu erstellt) werden. SieheDatenbankspiegelung und Datenbank-Snapshots.
Lastenausgleichsmodule auf Netzwerkebene haben nichts mit der Spiegelung zu tun und lösen nichts.
Antwort2
Wie wäre es mitnichts des oben Genannten?
Bitte erläutern Sie, was Sie mit gespiegelten SQL-Servern meinen. Verwenden Sie zum Spiegeln ein SAN irgendeiner Art oder die integrierte Spiegelungsfunktion von SQL Server?
Ich kann mir vorstellen, dass Sie HAProxy auf der Webebene verwenden könnten, aber warum sollten Sie dies mit SQL Server tun? Es gibt andere, viel besser unterstützte HA-Optionen mit SQL Server, wie Clustering, Spiegelung und Replikation. Ich würde diese zuerst untersuchen.