Wie kann man externe Entwicklerdatenbanken über die Produktion auf dem Laufenden halten?

Auf SQL Server 2008 R2 wird eine Produktionsdatenbank ausgeführt, in der Dateien gespeichert sind. Wir waren besorgt über die Größe der Datenbank und haben uns daher für die Aktivierung von FILESTREAM entschieden, damit die Dateien auf der Festplatte gespeichert werden und wir hoffentlich die Größe unserer Backups reduzieren können. Ich habe festgestellt, dass wir die FILESTREAM-Dateigruppe von den Sicherungen ausschließen können, aber dann haben wir Probleme beim Abfragen dieser Tabellen bei der Wiederherstellung (da in den Feldern Daten fehlen, was erwartet wird). Unser nächster Gedanke war dann, möglicherweise die Dateien von der Festplatte mit automatisiertem FTP oder Dropbox oder etwas Ähnlichem zu synchronisieren. Ich habe dies jedoch noch nicht vollständig untersucht.

Das eigentliche Problem, das wir hier lösen möchten, besteht darin, unsere Entwickler über die Produktionsdatenbank auf dem Laufenden zu halten. Mit der wachsenden Größe unserer Datenbank wird es immer mühsamer, eine vollständige Sicherung durchzuführen und die Datenbank herunterzuladen, und es wird schließlich unerschwinglich. Ich frage mich, was andere Leute tun, um Remote-Entwickler auf dem Laufenden zu halten.

Ich habe einen kurzen Blick auf den Protokollversand von SQL Server geworfen, aber das scheint nur eine Menge benutzerdefinierter Automatisierung (Planen von FTP- und Wiederherstellungsskripten) zu erfordern, damit es mit einigen Entwicklern an verschiedenen geografischen Standorten zuverlässig funktioniert, und das bin ich nicht sicher, wie die sekundäre Datenbank für die Entwicklung verwendet wird, da sie wahrscheinlich schreibgeschützt ist. Ich bin offen für Vorschläge und bitte lassen Sie mich wissen, ob ich weitere Informationen über unsere Situation liefern kann, die dazu beitragen könnten, Vorschläge zu machen.

UPDATE: Die Entwickler benötigen nur eine einigermaßen aktuelle Kopie der Produktionsdaten. Dies hilft, Probleme zu reproduzieren, damit sie behoben werden können. Wir sind damit einverstanden, dass die Daten etwas veraltet sind, aber wenn wir die Übertragungszeiten auf ein Minimum beschränken, würde dies auf häufige Sicherungen hindeuten.

Vielen Dank für die bisherigen Vorschläge. Um noch ein bisschen mehr hinzuzufügen, ist unsere Datenbank derzeit etwa 12 GB groß. Wir gehen davon aus, dass sich diese Zahl in naher Zukunft verdoppeln wird, wenn mehr Kunden gewonnen werden. Ich habe ein paar Testsicherungen mit aktivierter Komprimierung durchgeführt, die uns ungefähr 1-2 GB erspart haben, aber ich denke, da der größte Teil der gespeicherten Dateien (jetzt in FILESTREAM) sind, werden wir nicht die drastische Reduzierung erhalten, die wir würden hoffe auf (obwohl wir wahrscheinlich noch komprimieren werden, um so viel Platz wie möglich zu sparen). Ich denke, wir möchten die lokalen Kopien ein- oder zweimal pro Woche wiederherstellen können, um die Dinge im Auge zu behalten. Ich bin mir nicht ganz sicher, wie hoch unsere Bandbreitenbeschränkung von unserem gehosteten Server ist, aber es scheint, dass mehrere Leute, die mehrmals im Monat 20-GB-Dateien herunterladen, die Bandbreite, über die wir verfügen, nicht optimal nutzen können. Ich nicht

Ich denke, eine vollständige Datenbankkopie zu geben ist keine gute Idee, da dies mit dem Wachstum der Datenbank zu Schmerzen führen würde. Wir haben das gleiche Setup, aber nicht mit Filestream-Option. Wir verwenden Powershell, um Datenbankschemaskripte zu generieren und diese jeden Abend an Entwickler zu senden. Entwickler verwenden dieses Skript, um eine DB-Shell auf ihrem eigenen Computer zu erstellen (wir haben separate Entwicklungsdatenbanken mit Daten, mit denen sie ihre anwendungsspezifischen Daten abfragen und laden können). Diese Datenbank-Shell wird für die Entwicklung und den Unit-Test-Datenbankcode unter Verwendung von SSDT verwendet. Zum Debuggen von Live-Problemen haben wir eine Kopie der Live-Datenbank auf dem Standby-Server protokolliert, die meist nur 10-13 Minuten zurückliegt. Wir haben kaum Probleme mit diesem Setup, aber alles hängt von einzelnen Szenarien ab. Viel Glück

Ich verwalte eine DB-Umgebung für mehrere Tier-1-Telekommunikationsunternehmen und unsere Daten / Umgebungen sind auf der ganzen Welt verteilt. Es gibt viele Möglichkeiten, wie Sie das erreichen können, wonach Sie suchen, aber es hängt von Ihren Schwachstellen ab.

Fragen :

-Wie groß sind die Datenbanken, wie weit sind die Knoten (oder was noch wichtiger ist, wie lang ist die Latenz zwischen ihnen) und wie viel Bandbreite haben Sie?

-Wie viel Transaktionsprotokollaktivität generieren Sie?

-Wie oft möchten Sie wiederherstellen?

- Aktivieren Sie die Datenkomprimierung für die Sicherungen?

Einige Lektionen gelernt

- Beim Kopieren von Daten auf der ganzen Welt ist mir aufgefallen, dass das Windows CIFS-Protokoll dafür absolut zum Kotzen ist. Es ist sehr ineffizient.

Am Ende haben wir HTTPS verwendet und eine GET-Anfrage gestellt. Das Kopieren von Backups von Asien nach Los Angeles war über 10-mal schneller.

Die Verwendung von Multithreading-Optionen in Robocopy oder anderen Kopierprogrammen war hilfreich, wenn Sie die Sicherung in mehrere Dateien aufteilen.

Einige Optionen:

2 Überraschende Linux-Lösungen

• Eine Lösung, die mir sehr gefällt, ist RSYNC mit Linux-Servern an jedem Ende und das Mounten des Sicherungsordners. Dies ist sehr hilfreich, da Backups automatisch mit einem Protokoll synchronisiert werden, das für WANs effizient ist. Wenn Sie nicht ALLE Ihre Backups synchronisieren möchten, mounten Sie ein anderes Laufwerk auf Ihrem Linux-Server, das wirklich auf einer Windows-Freigabe bereitgestellt wird, in der Sie Backups ablegen. Der RSYNC kümmert sich von dort aus darum und erledigt dies viel schneller als CIFS . Nach meiner Erfahrung sind Linux-Protokolle für das Kopieren von Dateien über große Entfernungen viel besser als Windows CIFS. Ich habe mit einigen CCIEs gesprochen und sie haben dasselbe gesagt.

• Sie können sich auch einen VM WAN-Optimierer ansehen (Google- oder Bing-WAN-Optimierer oder spezifischere Informationen erhalten, z. B. WAN-Optimierer mit hoher Latenz und hoher Bandbreite oder hohe Bandbreite mit niedriger Latenz, unabhängig von Ihrer Umgebung).

Versand von SQL-Transaktionsprotokollen über FTP ist überhaupt nicht beängstigend. Ich hatte einen Junior .Net-Entwickler, der es schnell zum Laufen brachte, obwohl ich beeindruckt war und ihn bei einer anderen Firma anstellte, bei der ich arbeitete. Das Problem ist, dass Sie innerhalb von 24 Stunden möglicherweise viel mehr Daten senden, wenn viele UPDATES, aber keine INSERTS mit Protokollversand vorhanden sind, anstatt nur Backups zu kopieren.

Replikation auf Blockebene des SAN-Dateisystems : Sie sind sich nicht sicher, ob Sie Hardware haben, die dies unterstützt, aber in vielen SANs mittlerer Reichweite können Sie Live-Daten auf die anderen replizieren. Wenn dies bei Ihnen der Fall ist, ist dies eine großartige Option, da der Server-Overhead 0 SQL beträgt, es sei denn, Ihre Netzwerk-Pipe ist begrenzt. In diesem Fall haben Sie andere Probleme.

Transaktionsreplikation in eine zentrale Datenbank : Sie können ein Replikationsschema erstellen, in dem Sie über eine aktuelle Kopie der Daten verfügen. Sie können dann Ihre Backups von dieser Kopie nehmen, damit keine vollständigen Backups über das Kabel kopiert werden müssen.

Lassen Sie uns einige Ihrer Schwachstellen wissen und wir können andere Optionen durchgehen.

Lesen Sie auch unbedingt diese hervorragenden Whitepaper von MS, wenn Sie sich für die Replikation entscheiden:

Leistungssteigerungen bei der Georeplikation mit Microsoft SQL Server 2008 unter Windows Server 2008