Verschieben von Datenbanken in neue Rechenzentren

Mein Unternehmen verlagert unsere Infrastruktur in ein neues Rechenzentrum und ich versuche herauszufinden, wie die Datenbank auf dem neuen Server am besten mit der aktuellen Produktionsdatenbank synchronisiert werden kann, bis die neuen Umgebungen betriebsbereit sind. Da ich kein Vollzeit-DBA bin, habe ich einige Nachforschungen angestellt und nach dem, was ich gelesen habe, sieht es so aus, als würde ein transnationales Replikations-Setup unseren Anforderungen am besten entsprechen.

Einige Details: Die Produktionsdatenbank ist ungefähr 90 GB groß und mit Robocopy dauerte es ungefähr 9 Stunden, um eine Kopie davon auf einen der neuen Server zu verschieben. Die aktuelle Produktionsdatenbank muss während des gesamten Migrationsprozesses online und zugänglich bleiben. Da es sich um eine einfache Wiederherstellung handelt, ist die Datenbankspiegelung nicht verfügbar.

Ist eine Transaktionsreplikation die beste Methode, um die Datenbanken synchron zu halten?

Mein Plan:

1. (Fertig) Übertragen Sie die aktuelle Datenbank und protokollieren Sie auf dem neuen Server und hängen Sie sie an die neue Instanz von SQL Server an
2. Richten Sie einen Distributor auf unserem Entwicklungsdatenbankcomputer ein und veröffentlichen Sie ihn aus der Produktionsdatenbank
3. Erstellen Sie auf dem neuen Datenbankcomputer einen Abonnenten, der Updates akzeptiert, die einmal pro Nacht vom Distributor gesendet werden

Ich habe zwei Dinge im Kopf. Für die Transaktionsreplikation muss für jede veröffentlichte Tabelle ein Primärschlüssel vorhanden sein, und für viele Tabellen in der Produktionsdatenbank sind keine Primärschlüssel definiert. Ich denke nicht, dass dies ein zu großes Problem sein wird, da mein Hauptanliegen darin besteht, die Datenbanken nur zu synchronisieren. Wir werden die verschiedenen Anwendungen, die die Datenbank verwenden, zu einem späteren Zeitpunkt testen, aber ich möchte sicherstellen, dass dies kein ernstes Problem ist. Zweitens muss ich auch alle zugeordneten System-DBs aus der ursprünglichen Instanz verschieben, z. B. den Master? Wir wechseln zu einem Active Directory-Setup in der neuen Umgebung, daher interessieren mich die Benutzer und dergleichen nicht, aber ich bin mir nicht sicher, ob die System-DBs erforderlich sind.

Und verstehe ich diese Konzepte im Allgemeinen richtig?

Ihre aktuelle Situation:

• 90 GB Datenbank, die Sie in ein neues Rechenzentrum verschieben möchten.
• Die Datenbank wird einfach wiederhergestellt.
• Sie möchten T-Rep verwenden, um die Daten synchron zu halten.
• Es gibt viele Tabellen in der Datenbank, die keinen Primärschlüssel haben. Dies ist eine Voraussetzung dafür, dass Tabellen veröffentlicht werden.
• Sie haben bereits ein Backup in das Zieldatenzentrum kopiert.

Ich sehe viele Nachteile in Ihrem Ansatz:

• T-Rep ist im Vergleich zu anderen Technologien nicht einfach einzurichten. Wenn sich das Schema ändert, ist ein neuer Snapshot erforderlich.
• Wenn Sie mit T-REP arbeiten, müssen Sie Schemaänderungen vornehmen - fügen Sie Primärschlüssel zu Tabellen hinzu, die nicht vorhanden sind.
• Wenn Sie Änderungen an Ihrer vorhandenen Datenbank vornehmen, muss Ihre Anwendung vollständig getestet werden, um unerwartetes Verhalten zu vermeiden.
• Wenn Ihre Datenbank eine große Anzahl von Transaktionen aufweist und von der Netzwerkbandbreite zwischen den beiden Rechenzentren abhängt, tritt ebenfalls eine Replikationslatenz auf.

Aufgrund meiner Erfahrung ist unten meine Empfehlung:

• Ändern Sie Ihre Datenbank auf vollständige Wiederherstellung. Dies ist im Vergleich zum Erstellen von PKs keine große Auswirkung.
• Versenden Sie die vollständige Sicherung der Quelldatenbank - erstellen Sie eine Sicherung mit Komprimierung und aktivieren Sie die sofortige Dateiinitialisierung. Auf diese Weise können Sie die Wiederherstellungszeit im Ziel-Rechenzentrum verkürzen.
• Stellen Sie die Datenbank auf dem Zielserver wieder her WITH NORECOVERY.
• Implementieren Sie Logshipping und initialisieren Sie es aus der Sicherung.
• Lassen Sie die Protokolle alle 1 Minute versenden.
• Erstellen Sie am Tag des Failovers eine letzte Endprotokollsicherung für die Quelle und stellen Sie sie am Ziel mithilfe von wieder her WITH RECOVERY. Dadurch wird die Zieldatenbank online geschaltet.
• Sobald die Zieldatenbank online ist, müssen Sie Benutzer synchronisieren .
• Sie sollten Ihre web.config so ändern, dass sie auf den neuen Server verweist.

Sie müssen keine Systemdatenbanken verschieben. Stellen Sie sicher, dass Sie alle Vorbereitungsarbeiten ausführen, bevor Sie Anmeldungen, Jobs, SSIS-Pakete usw. per Hand ausschreiben und auf dem Zielserver erstellen.

In dieser Antwort finden Sie Schritte nach der Wiederherstellung und andere bewährte Methoden .

Hinweis: Sie können auch die Datenbankspiegelung implementieren (SYNC oder ASYNC, abhängig von der verwendeten SQL Server-Edition). Das Protokollieren ist jedoch einfach zu implementieren, und wenn Sie es testen, werden Sie nicht enttäuscht. Ich habe die Terabyte-Datenbank mit der oben beschriebenen Technik erfolgreich von einem Rechenzentrum in ein anderes verschoben und sie funktioniert einwandfrei.

Die aktuelle Produktionsdatenbank muss während des gesamten Migrationsprozesses online und zugänglich bleiben.

Es wird immer Ausfallzeiten geben, die Sie planen müssen. Selbst wenn Sie viel Geld in Lösungen wie Clustering investieren, kommt es beim Failover zu Ausfallzeiten. Sie müssen abwägen, wie viel Ihr Unternehmen in Ausfallzeiten nahe Null investieren kann, im Vergleich zu den verfügbaren Ausfallzeiten mit akzeptablen Ausfallzeiten.

Ich hatte keine Gelegenheit, dies selbst zu verwenden, und ich denke, es befindet sich noch in der Vorschau, aber SQL Data Sync auf der Azure-Plattform könnte eine mögliche Option sein:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Es funktioniert sowohl mit lokalen als auch mit Azure SQL-Datenbanken und scheint ein nützliches Werkzeug zu sein, um Datenbanken synchron zu halten.