Beste Hot/Warm Backup Server-Replikationsstrategie (SQL Server 2005)

Question

Ich habe zwei identische Server mit SQL Server 2005 und meine Anwendung.

harte Anforderungen:

1. Ich muss in der Lage sein, Daten zu aktualisieren, entweder Server.
2. Ich muss in der Lage sein, beide Server zu trennen, ohne irgendetwas in der Datenbank neu konfigurieren zu müssen.
3. Wenn ein Server wieder angeschlossen wird, muss er automatisch mit dem anderen Server synchronisiert werden.

Hinweise:

1. Ich ziehe es Optionen, die nicht signifikante Last auf den primären Server, wenn möglich hinzufügen würde.
2. Die beiden Server verfügen über ein privates Netzwerk für die Replikation, so dass Bandbreite kein Problem ist.
3. Es ist in Ordnung, wenn die Daten auf beiden Servern einige Minuten veraltet sind.

Von dem, was ich meine Optionen gelesen habe, sind:

• Transaktionsreplikation mit aktualisierbaren Abonnements (Queued Aktualisierung)
• Mergereplikation

Welche Konfiguration am besten meine Anforderungen passt?

Answer 1

Keine der aktuellen Optionen ermöglichen die Schreibbarkeit beider Server. Ziemlich genau Ihre einzige Option wird die Mergereplikation sein, da dies Aktualisierungen für beide Server ermöglicht.

Merge-Replikation ist jedoch am schwierigsten einzurichten und zu starten. Sie müssen sicherstellen, dass der Verteiler über genügend Speicherplatz verfügt, um sicherzustellen, dass der Verteiler während der gesamten Zeit, in der einer der Server inaktiv ist, nicht über genügend Speicherplatz verfügt.

Protokollversand und Spiegelung ermöglichen keine Aktualisierung des sekundären Servers.

Answer 2

Haben Sie über den Protokollversand nachgedacht?

Ich denke nicht, dass leicht eingerichtet werden kann, so dass die Warm-Standby automatisch übernehmen kann, so dass einige manuelle Bemühungen, um es zum Primären machen.

Und es wird nur so gut sein, wie das zuletzt erhaltene Protokoll - aber Sie könnten einrichten, um Protokolle jede Minute oder so zu versenden.

Wenn Sie die Standby 100% auf dem neuesten Stand haben müssen, dann brauchen Sie eine Lösung, die jede Transaktion synchronisiert - was ein Distributed Commit sein wird.

Aber wenn Sie den Standby von FedEx versenden und einen Prozess erzwingen könnten (d. H. Das "letzte" Protokoll zu versenden), bevor es ausgeschaltet wird, sollte das funktionieren; oder wenn es gerade getrennt, FedEx'd, und dann wieder "online" kommt, sollte der Log Shipping einfach dort weitermachen, wo er aufgehört hat; Wenn Sie es zum Primary machen, wird es so "frisch" wie das neueste Log, das es erhalten hat.