MS SQL Mischung mit MS SQL Express über 2 Standorte ratsam?

[Candy 27]

Hallo MCSEboard Community,

 

im Vorfeld schon einmal ein großes Danke für Eure Unterstützung.

 

Folgende Umsetzung ist bei uns in Planung bzw. Überlegung:

Prüfstand 1 lokal
Prüfstand 2 lokal
Prüfstand 3 lokal ....an einem Standort

Alle drei Prüfstände verfügen über performante u moderne Win11 Pro Kisten.

 

Wir möchten nun in einer bestehenden colocation in einem RZ einen neuen MS SQL Server aufsetzen. Zusätzlich noch einen WEB-Server für spätere Darstellungen.
Alle Server im RZ sind VM basiert.

Zwischen dem lokalen Standort und der colocation RZ besteht eine 1Gbit Site to Site VPN.

 

Folgendes haben wir nun theoretisch geplant.

Jeder der 3 Messprüfstände soll eine SQL-Datenbank von min. 3 Monaten vorhalten. Die Master DB liegt auf dem MS SQL Server im RZ und es ist gewünscht das eine, ich nenne es mal Master u. Slave Synchronisierung zwischen „Master MS SQL RZ“ und „Slave 3x Prüfstände“ alle 15min stattfindet.
Hintergrund dabei ist, dass die Ausfallzeiten noch weiter reduziert werden sollen. Als Beispiel, Internet ausgefallen, aber drei Prüfstände können mit der lokalen DB weiterarbeiten.

Nun ist unsere theoretische Überlegung auf den Prüfständen MS SQL Express 2025 einzusetzen und den „richtigen“ MS SQL Server im RZ voll zu lizenzieren.
Ist die Mischung mit Express ratsam? Die Hardwarebegrenzungen wären für uns verschmerzbar. Die Datenbankgrößen für 3 Monate absolut ausreichend.
Oder kommt es schon durch die angedachte Synchronisierung zu so weiten technischen Problemen das es kein Sinn ergibt?

Der Einsatz von MS SQL Express hat natürlich immer mit Lizenzkosten zu tun. 😊

 

Danke u. ein schönes Wochenende.....

[mwiederkehr 419]

Wie soll die Replikation ablaufen? Scriptet ihr das selbst? Reicht "read-only" für die Server in den Aussenstellen? Oder müssen auch Daten geschrieben werden können?

 

Bezüglich Lizenz ist zu erwähnen, dass bei einer Lizenzierung mit CALs der Server selbst nicht extrem teuer ist. Und die CALs müsst ihr ja nur einmal kaufen.

[NilsK 3.140]

Moin,

 

wie wollt ihr das bauen? Soll es mit der SQL-Server-Replikation laufen, oder gibt es eine Applikation, die den Abgleich steuert?

 

SQL-Replikation war ein großes Thema in den Neunzigern, und auf ziemlich genau dem Stand ist die Technik auch. Heute will man sowas nicht mehr bauen, weil es in der Breite nicht ausreichend zuverlässig funktioniert, wenn es keine Applikationsschicht gibt, die sich darum kümmert. 

 

Gruß, Nils

 

bearbeitet 13. April von NilsK

[Candy 27]

Moin,

nein, es gibt noch keine SQL-Server- Replikation. Es ist von uns noch eine rein "theoretische Denkweise".

 

Zu Zeit arbeiten alle Prüfstände direkt auf dem MS SQL Server im RZ.

Es gibt nun eine komplette Umstellung der Mess-Software durch ein Programmierer Team. Da sich die Software- Anforderungen geändert haben.
Dem Programmierer Team ist es egal auf welche neue Datenbank Engine wir aufsetzen wollen. Wir möchten gerne bei Microsoft SQL bleiben.

Wir stellen nur den "Unterbau" zur Verfügung. Datenbank Server u. Web-Server die im RZ gehostet sind (colocation, eigene Hardware).

Die drei Messprüfstände sind neu, aber noch mit der alten Mess-Software.

Um die ganze Performance, wie auch Ausfallsicherheit/ Redundanz noch besser zu gestalten, kam uns die oben genannte Idee.
Die Messprüfstände müssen einfach laufen, weil dort Geld verdient wird. :)

Deswegen unser theoretischer Ansatz, jeden der Drei mit einer lokalen Datenbank laufen zu lassen und zusätzlich eine Synchronisierung der Datenbank ins RZ umzusetzen.
Also 3 lokale Datenbanken synchronisieren sich in eine Datenbank im RZ.

 

Aber wenn ich dich jetzt richtig verstanden habe, ist das leider nicht so sinnvoll?!

 

Danke.

[mwiederkehr 419]

Das kann schon sinnvoll sein, allerdings meiner Meinung nach nicht als automatische Replikation.

 

Wenn ihr für den Fall "lokaler Server geht kaputt" die Möglichkeit haben wollt, über einen Server im RZ zu arbeiten, ist es nicht so komplex. Dann reicht es, regelmässig Sicherungen von Datenbank und Logdateien ins RZ zu übertragen. Die Umschaltung wäre dann ein manueller (dokumentierter und getesteter) Prozess.

 

Das ist wesentlich einfacher als "ich will für Wartungsarbeiten flexibel zwischen den Servern umschalten können".

[NilsK 3.140]

Moin,

 

zusätzlich zu dem, was @mwiederkehr sagt:

 

vor 27 Minuten schrieb Candy:

Also 3 lokale Datenbanken synchronisieren sich in eine Datenbank im RZ.

 

genau das ist der Use Case, der nur in der Theorie auf der Datenbankebene funktioniert. In der Praxis wird man die Applikation mit einbinden müssen, damit es robust wird. Simpel gesagt, die Applikation muss davon wissen, dass repliziert wird. Das geht bei so simplen Dingen los wie Datensatz-Kennungen, die pro Replikat eindeutig sein müssen, aber ggf. auch eine Sortierung/Auswahl/was auch immer über den ganzen Bestand zulassen. Weiter geht es bei der Frage, was mit Löschungen und nachträglichen Änderugen passiert. Lustiger wird es dann bei der Frage, was passiert, wenn an Standort A die Daten bearbeitet werden, die von Standort B kommen - und was das für abgeleitete Funktionen bedeutet.

 

Und, noch wichtiger: die Applikation sollte Mechanismen vorsehen, um Fehler zu korrigieren oder auszugleichen.

 

Wenn ihr ohnehin gerade Developer da dran habt, dann sprecht mit denen darüber.

 

Gruß, Nils

 

[Candy 27]

Alles klar.

 

Danke und viele Grüße....

[t-sql 22]

vor 2 Stunden schrieb NilsK:

Moin,

 

zusätzlich zu dem, was @mwiederkehr sagt:

 

 

genau das ist der Use Case, der nur in der Theorie auf der Datenbankebene funktioniert. In der Praxis wird man die Applikation mit einbinden müssen, damit es robust wird. Simpel gesagt, die Applikation muss davon wissen, dass repliziert wird. Das geht bei so simplen Dingen los wie Datensatz-Kennungen, die pro Replikat eindeutig sein müssen, aber ggf. auch eine Sortierung/Auswahl/was auch immer über den ganzen Bestand zulassen. Weiter geht es bei der Frage, was mit Löschungen und nachträglichen Änderugen passiert. Lustiger wird es dann bei der Frage, was passiert, wenn an Standort A die Daten bearbeitet werden, die von Standort B kommen - und was das für abgeleitete Funktionen bedeutet.

 

Und, noch wichtiger: die Applikation sollte Mechanismen vorsehen, um Fehler zu korrigieren oder auszugleichen.

 

Wenn ihr ohnehin gerade Developer da dran habt, dann sprecht mit denen darüber.

 

Gruß, Nils

 

Du redest von sowas hier Peer-to-Peer Transactional Replication - SQL Server | Microsoft Learn. Aber das ist für diesen trivialen Fall ganz sicher nicht gedacht. Warum Standortdaten an anderen Standorten geändert werden sollten erschließt sich mir nicht.