Sofortige Synchronisation mehrerer SQL Server

Zunächst einmal tut es mir leid, wenn dies ein Duplikat ist. Ich konnte niemanden finden, der diese spezielle Frage ansprach, oder ich hätte sie beim Lesen möglicherweise nicht erkannt. Höchstwahrscheinlich habe ich die falschen Suchbegriffe verwendet, da ich mit der Terminologie nicht allzu vertraut bin.

Wir haben 3 Server:

A . SQL Server

B . Alarmsystem

C . Website + API + Andere

Server B und C müssen ständig eine Verbindung zu Server A herstellen , und es gab mehrere Fälle von Ausfallzeiten, die zu großer Unzufriedenheit der Kunden geführt haben.

Wir möchten Folgendes haben: (verschiedene Buchstaben, um das Kommentieren zu erleichtern, obwohl dies möglicherweise nicht der Fall ist: p)

W . Alarmsystem (mit SQL-Server)

X . Website + API (mit SQL-Server)

Y . Website + API (mit SQL-Server)

Z . Andere (mit SQL-Server)

BEARBEITEN: X und Y sind technisch identisch, aber X hostet normalerweise die Website, und unsere Apps und Lösungen von Drittanbietern stellen normalerweise eine Verbindung zur API auf Server Y her , um sicherzustellen, dass ein Hickup nur über einen Kanal zu spüren ist . Wenn X abstürzen würde, würde Y sowohl die Website als auch die API bedienen, bis X wieder online war und umgekehrt.

Es ist wichtig, dass die SQL-Server synchronisiert sind. Wenn ein Client über die Website (Server X ) eine Änderung in der Datenbank vornimmt und dann das Alarmsystem W aktiviert (für das die Änderung von Bedeutung ist), muss es bereits synchronisiert worden sein.

~~Jedes System verwendet nur einige der Datenbanken und Tabellen. Um Ressourcen zu sparen, konnten wir nur die wichtigen Daten sofort und den Rest etwa alle paar Stunden synchronisieren.~~ Bearbeiten: keine Option

Wir werden SQL Server 2014 auf allen Servern verwenden (sofern mich nicht jemand anders überzeugt)

Benötigen wir dazu Software von Drittanbietern ?
Wir sind offensichtlich daran interessiert, die kostengünstigste Lösung zu verwenden, sowohl in Bezug auf Geld als auch in Bezug auf Ressourcen, aber die Unzufriedenheit unserer Kunden muss um jeden Preis enden. Wir haben nie einen Kunden verloren und beabsichtigen nicht, einen zu verlieren, weil er billig war .
Müssten wir Trigger für die wichtigen Tabellen verwenden oder sollten wir dies tun?
Könnten wir Ansichten verwenden ?
- Das heißt; Erstellen Sie auf allen SQL-Servern, die von jedem Server geladen werden, der den neuesten Zeitstempel für diese bestimmte Tabelle hat, die gleichen Ansichten, so dass eine sofortige Synchronisierung erfolgt. Eine echte Synchronisierung wäre immer noch notwendig, aber weniger häufig.
- Ich bin mir nicht sicher, wie das funktionieren würde, aber ich wäre nicht überrascht, wenn jemand dies irgendwann getan und eine Lösung für alle offensichtlichen und weniger offensichtlichen Probleme gefunden hätte.
Wir haben verschiedene Funktionen , Prozeduren und Jobs , die von Zeit zu Zeit geändert werden. Können diese synchronisiert werden oder muss ich sie manuell aktualisieren (was keine große Sache ist)?

AKTUALISIEREN:

Wir haben Kontakt zu einem Unternehmen aufgenommen, das uns in der Vergangenheit beim Einrichten von Servern und beim Abrufen der richtigen Versionen und Lizenzen geholfen hat. Ihr Vorschlag war der folgende:

Geben Sie jedem SQL Server eine Kopie der Tabellen, in die Daten gelesen und geschrieben werden.
Haben repliziert alle Tabellen von den anderen Servern auf jedem Server; von dem es nur lesen kann .

Auf diese Weise kann jeder Server unabhängig arbeiten und auf alle Änderungen zugreifen, die auf den anderen Servern vorgenommen wurden.

Ich bin nicht ganz sicher, wie ich das Löschen von Zeilen erkennen soll , außer durchzugehen und zu sehen, was fehlt, es sei denn, TRIGGERS arbeiten post-synchron in replizierten Tabellen.

EDIT: Ein weiteres Anliegen von mir ist , was etwas ist in der gleichen Tabelle eingefügt passieren würde, auf verschiedenen Servern, während die Replikation nach unten aufgrund von Netzwerkproblemen oder was auch immer. Dann hätten wir 2 Zeilen mit derselben ID , und wir hätten keinen Grund anzunehmen, dass die letztere keine Bearbeitung der ersteren ist (abgesehen von der Tatsache, dass sich die ID nur in 2 von 4 Servern befindet, aber es könnte gut sein in allen 4 sein, wenn das Netzwerk für längere Zeit ausgefallen ist)

Diese Probleme alle ny werden könnten gelöst mehr colums zum Hinzufügen Erstellungsdatum , zuletzt Datum , Insert-ID und global-ID . Aber dann müssten wir auf unserer Website und auch in anderen Systemen so viel ändern, dass wir es vorziehen würden, dies zu vermeiden.

Gibt es noch andere Hindernisse, denen wir mit dieser Lösung begegnen könnten?
Irgendwelche besseren Ideen?

sql-server sql-server-2014 data-synchronization

— Levi Johansen
quelle

Befinden sich alle 4 Server im selben Rechenzentrum? Wie häufig ändert sich das Schema in der Hauptdatenbank und wie groß sind die Datenbanken?

— Kin Shah

Gibt es einen Grund, warum sich diese nicht einfach auf demselben SQL Server befinden? Scheint eine große Teilung innerhalb der Datenschicht zu sein, die Probleme verursacht, anstatt sie zu lösen.

— Dave

Verwenden Sie eine einzelne, hochverfügbare SQL Server-Datenbank, die möglicherweise mit einer Verfügbarkeitsgruppe oder zumindest einem Spiegelungspartner konfiguriert ist. Dies führt zu einer sehr geringen Ausfallzeit (in der Größenordnung von 10 bis 20 Sekunden), falls der SQL Server aus irgendeinem Grund ausfällt und alle Daten automatisch und kontinuierlich "synchronisiert" werden.

— Max Vernon

@kin Sie befinden sich nicht im selben Zentrum. Die Datenbanken sind 500 MB, 200 MB und einige mehr mit weniger als 50 MB. Ich bin mir nicht sicher, was Sie mit der Häufigkeit von Schemaänderungen meinen, aber wir fügen einige Spalten und Tabellen hinzu, die jeder kennt, und dann zur weiteren Entwicklung der Dienste, wahrscheinlich alle 3-4 Monate.

— Levi Johansen

@ Dave Es ist sehr wichtig, dass diese Systeme niemals ausfallen. Wenn die Website nicht verfügbar ist, sollten die Benutzer sie weiterhin über die API (mit einer App auf ihrem Smartphone) usw. verwenden können. Der Alarmserver ist der wichtigste, und ein entfernter SQL-Server hat viele Probleme verursacht. Das Alarmsystem benötigt also einen lokalen SQL-Server, und wenn dies der einzige SQL-Server ist, würde bei einem Absturz nichts funktionieren.

— Levi Johansen

Antworten:

Ich verstehe das vielleicht etwas falsch, also entschuldige ich mich, wenn ich es bin.

Wenn Sie zwei Datenbanken haben, die identisch sein müssen und sich im Jahr 2014 befinden, verwenden Sie die AlwaysOn-Hochverfügbarkeitsgruppe.

Da sich Ihre Rechenzentren an verschiedenen Standorten befinden, verwenden Sie den Async-Modus

Dies bedeutet, dass die Datenbank vollständig auf dem neuesten Stand gehalten wird (möglicherweise mit einer Verzögerung von einigen Sekunden) und Sie den sekundären Knoten als schreibgeschütztes Replikat verwenden können. Dies bedeutet, dass Ihr Alarmsystem alle Daten in diese Datenbank einlesen kann Schecks usw. würden Sie normalerweise.

Das Always-on-System hält alles auf dem neuesten Stand. Wenn die Verbindung unterbrochen wird, werden alle Änderungen zusammengeführt, wenn sie wieder online sind

Wenn Ihr Hauptcenter ausfällt, können Sie es so einstellen, dass es automatisch auf das sekundäre Failover umschaltet. Wenn das Hauptdatencenter wieder online ist, wird es erneut mit dem (jetzt) primären Knoten synchronisiert. An diesem Punkt können Sie ein Failover durchführen zu Ihrem Hauptzentrum.

Sie können dies auf mehreren Datenbanken ausführen, sodass unsere Hauptdatenbank und unsere Verwaltungsdatenbank auf unseren Knoten synchronisiert sind. Was jedoch alle Jobs und direkten Aktionen auf jeder Seite ausführt, wird nicht repliziert und kann daher unabhängig voneinander bleiben

— Ste Bov
quelle

Für uns ist es sehr wichtig, dass der Synchronisierungsprozess nicht auf einen einzelnen Server angewiesen ist. Wenn der Hauptserver ausfällt, arbeitet der andere Server unabhängig voneinander, synchronisiert sich jedoch erst, wenn der Hauptserver wieder online ist. Ermöglicht einer Ihrer Vorschläge den Servern die Synchronisierung von Nomatter, wenn die Hauptleitung ausgefallen ist?

— Levi Johansen

Wenn Sie mehrere sekundäre Knoten haben, repliziert derjenige, der die Rolle des primären Knotens übernimmt, während der Hauptknoten inaktiv ist, alles, was er tut, auf alle anderen sekundären Knoten. Wenn Ihr Hauptknoten zurückkehrt, handelt es sich um einen sekundären Knoten, der bis zu den meisten synchronisiert wird Aktueller Status, an dem Sie manuell ein Failback durchführen oder ein Skript einrichten können, das automatisch ein Failback ausführt, wenn der Hauptknoten als online, aber nicht als primärer Knoten erkannt wird

— Ste Bov

Klingt gut! Würde die Rolle als Primärknoten an einen dritten Knoten weitergegeben, wenn die Sekundärrolle ausfallen würde? Systeme nicht müssen die Verwendung primäres Recht, - wir einige weniger kritische Systeme aufbauen könnten die lokalen SQL Server zu benutzen?

— Levi Johansen

Das ist es, worüber Sie sprechen: https://msdn.microsoft.com/en-us/library/ff877931.aspx richtig?

— Levi Johansen

Wenn der primäre Knoten ausfällt, wird einer der sekundären Knoten zum primären Knoten, sodass Sie darauf schreiben können (siehe msdn.microsoft.com/en-us/library/hh270280.aspx Quorum für das, was hier vor sich geht) im Allgemeinen nie ohne eine Primärdatenbank, es sei denn, eine ist gerade ausgefallen und Sie warten auf die Übernahme einer anderen, im Allgemeinen kein langer Prozess, sobald die Abgabe erkannt wurde)

— Ste Bov

Es scheint, dass Sie die Replikation zusammenführen zwischen Servern verwenden können. Bei Objekten, die Sie benötigen, können Sie die Replikation alle 1 Minute synchronisieren, sodass jede Änderung in weniger als einer Minute übermittelt wird. (nicht in Echtzeit, aber sehr effizient) Es kann andere Objekte als Tabellen synchronisieren. Wenn Sie kein sehr kompliziertes Datenbankdesign haben, ist keine große Wartung erforderlich. Sie können Aktualisierungen sogar für denselben Datensatz gleichzeitig in verschiedenen Datenbanken durchführen. Merge Replication verfügt über einen Konfliktlösungsmechanismus, der Konflikte in Ihrem Unternehmen nach Möglichkeit auf der Grundlage der von Ihnen definierten Priorität löst. Da Änderungen erfasst und dann synchronisiert werden, funktionieren andere Server problemlos, selbst wenn ein Server ausfällt, und erfassen Änderungen. Wenn der Server zurück ist, wird alles synchronisiert.

— Sina Hassanpour
quelle

Könnte es öfter als jede Minute synchronisiert werden? Benötigt diese Methode viel Kraft?

— Levi Johansen

Wenn Sie den fortlaufenden Zeitplan verwenden, wird er jede Minute synchronisiert. Sie können jedoch die Methode "Geplant" verwenden. Technisch gesehen können Sie die Zeitplanung in Sekunden festlegen. Die effektive Zeitdistanz hängt jedoch von der Anzahl der Änderungen in den Datenbanken und der Verbindungsbandbreite ab Ich glaube nicht, dass der Verarbeitungsaufwand bei dieser Lösung eine große Rolle spielt. Ich habe ihn für Datenbanken mit mehr als 500 GB und etwa 1 GB Änderung verwendet, und die Verarbeitungsleistung war kein Problem. Sie können jedoch einen anderen Server als Verteiler verwenden, um den Overhead zu verschieben, wenn Sie möchten.

— Sina Hassanpour

Aber wenn der Hauptserver ausfällt, werden die anderen nicht miteinander synchronisiert, bis der Hauptserver wieder online ist?

— Levi Johansen

Es ist wahr. Der Publisher ist das Herzstück dieser Infrastruktur und sollte sorgfältiger behandelt werden.

— Sina Hassanpour