SQL Server-Replikation für externe Kopie

Wir haben unsere primären SQL-Server im Haus (derzeit 15 primäre Server (ca. 500 Datenbanken insgesamt), die meisten Server verfügen über Hex-Core-Prozessoren).

Diese werden auf andere Sicherungsserver in einem nahe gelegenen Gebäude gespiegelt (über eine dedizierte 0-ms-Glasfaserverbindung).

Wir möchten eine Live-Kopie unserer Daten in einem meilenweit entfernten externen Rechenzentrum aufbewahren (als Teil eines viel größeren DR-Projekts - dh wenn es in unserer Region ein Kommunikationsproblem gibt).

Derzeit verwenden wir SQL Server 2008 R2 - Standard Edition.

Die Verwendung der "Standard Edition" von SQL Server 2008 R2 beschränkt uns offensichtlich auf die synchrone Spiegelung, da asynchron eine "Enterprise Edition" -Funktion ist.

Wir haben Tests mit synchroner Offsite-Spiegelung durchgeführt, aber die Latenz hat es einfach zu einem No-Go gemacht.

Ich würde gerne ein Upgrade auf SQL Server 2012 Enterprise durchführen und AlwaysOn-Verfügbarkeitsgruppen implementieren, aber das Unternehmen ist nicht bereit, mehr als 100.000 GBP für das Upgrade der SQL-Lizenzierung auszugeben (2012 pro Kernlizenzierung + unsere Hex-Core-Prozessoren = epischer Fehler) - Sie sind nicht einmal bereit, das Geld für ein Upgrade auf 2008 Enterprise auszugeben. Das ist also auch eine asynchrone Spiegelung aus dem Fenster.

Da mir diese finanziellen Zwänge die Hände gebunden haben, bleibe ich bei der 2008 R2 Standard Edition.

Die einzigen Optionen, die mir offen bleiben, sind Protokollversand und Replikation (korrigieren Sie mich, wenn ich etwas verpasst habe) - Protokollversand ist grob - aber wenn es richtig verwaltet wird, kann es machbar sein - also haben wir das vorerst auf dem Rückgrat.

Meine Fragen):

1. Verfügt SQL Server 2008 R2 Standard über alle Replikationsfunktionen, die für die externe Replikation erforderlich sind?
2. Wäre die Replikation von internen Servern in ein externes Rechenzentrum (20 bis 30 ms Latenz) möglich, ohne die Leistung auf dem Primärserver in irgendeiner Weise zu beeinträchtigen (wäre es in Ordnung, den Replikationsverteiler auf dem "Principle" -Server festzulegen)?
3. Angesichts der Tatsache, dass es sich bei der Replikation nicht um eine Replikationslösung auf Instanzebene handelt, würde die Verwaltung dieser Lösung mehr als 1 DBA umfassen? (Angesichts der Tatsache, dass ich bereits 15 Principle-Server und deren Mirror-Gegenstücke verwalte - zugegebenermaßen mit viel Automatisierung)
4. Wäre eine Replikation von unserem primären Standort aus möglich, ohne die vorhandene Spiegelungskonfiguration zu beeinträchtigen. Nach meinem Verständnis besteht die beste Vorgehensweise darin, den Abonnenten im Gegensatz zum Publisher zu spiegeln. Ist dies korrekt?
5. Gibt es noch etwas, das Replication Virgins vergessen, dass Sie mich darauf aufmerksam machen müssen?

Basierend auf dem, was Sie beschrieben haben, wird der Protokollversand der richtige Weg sein. Holzversand ist alte Schule, bewährt.

Die Replikation ist ziemlich zerbrechlich und bietet viel Spielraum für Fehler, insbesondere wenn neue Tabellen hinzugefügt und diese Tabellen in die Replikationstopologie aufgenommen werden sollen.

Die Upgrade-Kosten für 2012 sind möglicherweise nicht so hoch wie Sie denken. Wenn Sie über Software-Sicherheit und eine Unternehmensvereinbarung verfügen, sparen Sie eine Menge Geld bei der Lizenzierung.

Der Protokollversand mag "roh" sein (ich nenne ihn lieber unkompliziert), aber die Replikation ist komplex und meiner Erfahrung nach spröde. Sie möchten keine Komplexität hinzufügen, wenn Sie dies vermeiden können. Sie möchten keine Heldentaten durchlaufen müssen, um ein fehlerhaftes Replikations-Setup zu beheben.

Das Verwalten der Replikationskonfiguration all dieser Datenbanken wäre ein Problem. Sie können nicht die Replikationsformen verwenden, die Datenbanktabellen verändern würden, da ich vermute, dass das Testen dieser Änderungen an 500 Datenbanken ein sehr großes Projekt ist, wenn nicht sogar eine Karriere für sich. Auf der Abonnentenseite können Leistungsprobleme auftreten, bei denen Sie sich zunächst mit Füllfaktoren, Wartungsplänen und anderen ähnlichen Komplikationen befassen müssen. Was passiert, wenn Sie von Ihren Primärservern zu Ihren "lokalen" Sekundärservern wechseln müssen? Werden Sie die gesamte Replikationskonfiguration erneut durchführen? Das ist wahrscheinlich eine große Aufgabe. Wenn Sie es automatisieren, ist dies die Zeit, die Sie für das Erstellen und Testen der Automatisierung aufgewendet haben. Wenn Sie diese 500 Datenbanken ändern, muss dies berücksichtigt werden.

Denken Sie daran, dass alles, was wir für DR hatten, der Protokollversand bis SQL Server 2005 war. Es ist nicht glamourös, aber es funktioniert.

TL; DR-Simpler ist besser. Verwenden Sie den Protokollversand.