Muster für die Aktualisierung von Slave-SQL-Server 2008-Datenbanken von einem Master während Störung minimiert

Question

Wir haben eine ASP.NET Web-Anwendung, die von einer Web-Farm von vielen Fällen unter Verwendung von SQL Server 2008 gehostet, in dem wir die Aggregation und Vorverarbeitung von Daten aus mehreren Quellen in ein Format für die schnelle Endbenutzers Abfrageleistung optimiert (Herstellung 5 -10000000 Reihen in einigen Tabellen). Die Aggregation und Optimierung wird von einem Dienst auf einem Back-End-Server durchgeführt, die wir dann nur vorne lesen, um mehr verteilen wollen Kopien von den Web-Anwendungsinstanzen verwendeten beenden maximale Skalierbarkeit zu erleichtern.

Meine Frage ist, über den besten Weg, um diese Daten von einem Back-End-Datenbank, um den Nur-Lese-Front-End-Kopien in einer solchen Art und Weise zu erhalten, die ihre Leistung nicht während des Prozesses töten. Die Front-End Web-Anwendungsinstanzen unter konstant hohen Belastung sein und müssen jederzeit gutes Ansprechverhalten haben.

Die Back-End-Datenbank wird ständig aktualisiert, so dass ich die Transaktionsreplikation der beste Ansatz, wie der konstanten Strom von Aktualisierungen der Kopien wird nicht vermuten, dass ihre Leistung schaden.

Abgestandenheit von Daten ist kein großes Problem so Snapshot-Replikation der richtigen Weg sein könnte zu gehen, aber dies zu einer schlechten Leistung während der Perioden der Replikation führen wird.

Doing einen Tropfen und Masseneinsatz wird in Perioden ohne Daten für Benutzerabfragen zur Folge hat.

mir wirklich keine komplexen Cluster in dem Schreiben Ansatz zu bekommen, wo uns Kopien aus dem Cluster fallen während der Aktualisierung - gibt es etwas in diese Richtung, die wir ohne allzu viel Aufwand tun können, oder gibt es eine bessere Alternative?

Answer 1

Es gibt tatsächlich eine Technologie in SQL Server gebaut 2005 (und 2008), die ausgelegt ist, diese Art von Problemen zu lösen. Service Broker (Ich werde weiter beziehen SSB). Das Problem ist, dass es eine sehr steile Lernkurve hat.

Ich weiß, dass MySpace ging an die Öffentlichkeit, wie SSB nutzt ihren Park von SQL Server zu verwalten: MySpace Verwendet SQL Server Service Broker Integrität von 1 Petabyte von Daten zu schützen. Ich kenne einige mehr (major) Websites, die ähnliche Muster verwenden, aber leider haben sie nicht die Öffentlichkeit gegangen, so kann ich nicht Namen beziehen. Ich war persönlich bei einigen Projekten um diese Technologie beteiligt (Ich bin ein ehemaliges Mitglied des SQL Server-Teams).

tragen nun daran, dass SSB ist kein dedicate Datenübertragungstechnologie wie Replikation. Als solche werden Sie nicht anyhting ähnlich wie die Veröffentlichung von Assistenten und einfachen Bereitstellungsoptionen von Replikation finden (eine Tabelle überprüfen und es wird übertragen). SSB ist eine zuverlässige Messaging-Technologie und als solche seine Primitiven auf der Ebene des Nachrichtenaustausches stoppen, würden Sie den Code schreiben, der die Datenänderungserfassung , packt es als Nachrichten und auch das Auspacken der Nachricht in relationale Tabellen am Bestimmungsort.

Warum immer noch einige Unternehmen preffer SSB über Replikation bei einer Aufgabe, wie Sie beschreiben, ist, weil SSB eine viel bessere Geschichte, wenn es um Zuverlässigkeit und Skalierbarkeit kommt. Ich weiß von Projekten, die Daten zwischen 1500 Websites, die weit über die Möglichkeiten der Replikation auszutauschen. SSB ist auch von der physikalischen Topologie abstrahiert: Sie Datenbanken bewegen können, Maschinen umbenennen, neu erstellen, alle Server, ohne die Anwendung zu ändern. Da Datenfluss über auftritt logische Routen die Anwendung kann addapt neue Topologien on-the-fly. SSB ist auch robust zu lange Zeiträume disocnnect und Ausfallzeiten, in der Lage, den Datenfluss nach Stunden wieder aufnehmen, Tage und sogar Monate trennen. Hohe troughput durch Motor Integration erreicht (SSB Teil der SQL-Engine selbst ist, ist nicht eine Sammlung von Satelliten-Anwendungen und Prozessen wie Replikation) bedeutet, dass der Rückstand bei den Änderungen Prozesse zu angemessenen Zeiten sein kann (ich weiß von Websites, die über die Hälfte gehen a Millionen Transaktionen pro Minute). SSB-Anwendungen beruhen typischerweise auf interne Aktivierung incomming Daten zu verarbeiten. SSB hat auch einige einzigartige Features wie eingebaute in Load Balancing (über Routen) mit klebriger Sitzung Semantik, die Unterstützung für freie anwendungsspezifische korrelierte Verarbeitung Deadlock, Prioritätsdaten Lieferung, spezifische Unterstützung für die Datenbankspiegelung, Zertifikat basierte Authentifizierung für Cross-Domain-Operationen, built-in beharrte Timer und viele mehr.

Dies ist keine spezifische Antwort ‚wie die Daten von der Tabelle T auf Server A nach Server B zu bewegen.‘ Ist mehr eine allgemeine Technik, wie man ‚exhange Daten zwischen Server A und Server B‘.

Answer 2

Ich habe noch nie zuvor mit diesem Szenario zu behandeln, sondern habe mit einer möglichen Lösung für diese kommen. Grundsätzlich wäre es eine Veränderung in Ihrer Haupt-Datenbankstruktur erforderlich. Statt die Daten zu speichern, würden Sie Aufzeichnungen über Änderungen dieser Daten halten. Wenn also ein Datensatz hinzugefügt wird, speichern Sie „Tabelle X eingefügt neuen Datensatz mit diesen Werten: ...“ Mit Änderungen, speichern nur die Tabelle, Feld und verändern Wert. Mit Deletionen, nur speichern, welcher Datensatz gelöscht wird. Jede Änderung wird mit einem Zeitstempel gespeichert werden.

Ihre Client-Systeme würden ihre lokalen Kopien der Datenbank halten und werden für alle Datenbankänderungen nach einer bestimmten Datum / Zeit regelmäßig fragen. Sie dann diese Änderungen in der lokalen Datenbank ausführen und es wird wieder up-to-date sein.

Und das Back-End? Nun, es wäre nur eine Liste von Änderungen behalten und vielleicht eine Tabelle mit den Basisdaten. auch nur die Änderungen zu halten bedeutet, dass Sie den Überblick über die Geschichte zu halten, so dass Sie das System fragen, wie es vor einem Jahr sah.

Wie gut das funktionieren würde, hängt von der Anzahl der Änderungen auf der Back-End-Datenbank. Aber wenn Sie die Änderungen alle 15 Minuten verlangen, sollte es nicht, dass viele Daten werden jedes Mal.

Aber noch einmal, ich hatte nie die Chance, diese in einer realen Anwendung heraus zu arbeiten, so ist es noch ein theoretisches Prinzip für mich. Es scheint, schnell, aber eine Menge Arbeit erforderlich sein wird.

Answer 3

Option 1 : eine App schreibt die Daten mit Zeilenebene Transaktionen zu übertragen. Es könnte länger dauern, aber in keiner Unterbrechung der Website unter Verwendung der Daten zur Folge haben würde, weil die Reihen gibt es vor und nach dem Lesen auftritt, nur mit neuen Daten. Diese Verarbeitung auf einem separaten Server passieren würde Belastung zu minimieren.

In SQL Server 2008 Sie READ_COMMITTED_SNAPSHOT können festlegen ON, um sicherzustellen, dass die Zeile aktualisiert wird blockiert nicht verursacht wird.

Aber im Grunde alle diese App die neuen Daten gelesen haben werden, wie es aus einer Datenbank heraus verfügbar ist und in die andere.

Option 2 : Verschieben Sie die Daten (Tabellen oder gesamte Datenbank) aus dem Aggregationsserver an den Front-End-Server. Automatisieren Sie dies, wenn möglich. Dann schalten Sie Ihre Web-Anwendung in die neue Datenbank oder Tabellen für zukünftige Anforderungen zu zeigen. Dies funktioniert aber erfordert die Kontrolle über den Web-App, die Sie möglicherweise nicht haben.

Option 3 : Wenn Sie über eine einzelne Tabelle sprechen (oder dies mit vielen arbeiten könnte), was Sie können eine Ansicht Swap zu tun ist. So schreiben Sie Ihren Code gegen eine SQL-Ansicht, die A. verweist auf Tabelle Sie Sie in Tabelle B funktionieren und wenn es fertig ist, aktualisieren Sie die Ansicht auf Tabelle B zeigen Sie können sogar eine Funktion schreiben, die die aktive Tabelle bestimmt und automatisieren die gesamte Swap-Sache.

Option 4 : Sie könnten in der Lage sein, so etwas wie Byte-Level-Replikation des Servers zu verwenden. Das klingt zwar beängstigend. Welches ist das Kopieren im Grunde den Servers von Punkt A nach Punkt B genau bis zu dem sehr Bytes. Es ist vor allem in DR Situationen verwendet, die das klingt wie es ein bisschen / sorta DR Situation sein könnte, aber nicht wirklich.

Option 5 : Aufgeben und lernen, wie Versicherungen zu verkaufen. :)