[Szenario] DB Replikartion bei nicht dauerhafter, aber immer wiederkehrender Internetverbindung

moinmoin

Neuer Benutzer
Beiträge
4
Guten Tag zusammen,

ich möchte mich kurz vorstellen: Ich
bin seit vielen Jahren in der IT als WebDeveloper tätig.
Habe aber nun ein ehrenamtliches Projekt an der "Backe" (absichtlich als persönliche Herausforderung),
dass meinen Wissenslevel zwar "etwas" übersteigt
und ich nun in der Situation bin, das ich wieder mal etwas Neues dazu lernen darf und will ;-).

Mein Motto: Keep it simple! und Aufgeben ist - zumindest für mich persönlich - keine Lösung.

Naja, nun genug Geplänkel.
Folgendes Szenario ist gegeben, für das ich nun Denkanstöße benötige.
Ist also erstmal nur "laut" Denken. Ist so was überhaupt so möglic, usw.

Also nehmen wir mal folgendes an ...

Server Szenario:
  • Server 1 (LAMP)
    in Deutschland
  • Server 2 (LAMP)
    irgendwoanders, mit nicht dauerhafter aber immer - zu unterschiedlicher Zeit - wiederkehrender Internetverbindung. Heißt immer mal wieder 1 Min- 1 Tag offline.
Daten Szenario
Das Team 1 ist dauerhaft per WLAN mit Server 1 verbunden
und bearbeitet dortDaten auf einer php/mysql Webseite.

Der Team 2 ist dauerhaft mit Server 2 verbunden
und bearbeitet dort Daten auf einer php/mysql Webseite.

Wenn es nun Internet gibt, sollen sich die aufgelaufenen Änderungen der zwei mySQL/MariaDBs so abgleichen, das die Informationen vom Team2/Server 2 auf den Server 1 repliziert werden und somit für Team 1 zur Verfügung stehen.

Umgekehrt sollen auch die Daten die das Team1 auf Server 1 bearbeitet hat, auf den Server 2 repliziert werden und so für TEAM 2 zur Verfügung stehen.

Theoretisch wären dann die Informationen auf beiden Servern gleich,
natürlich um die Zeit des "Offline Seins" verschoben/versetzt.
Das ist insofern aber nicht schlimm, da eine bestimmte Tabelle nur in eine Richtung repliziert werden soll, zB.:
Tbl1: Srv1 → Srv2
Tbl2: Srv2 → Srv1
(!) Es gibt also keine Tabelle die in beide Richtungen repliziert werden muss.

Ein Datenabgleich von Dateisystemen (Ablage) ist über rsync ja problemlos möglich.
Meine frage bezieht sich nur auf den Abgleich, die Replikation der zwei Datenbanken.

Satelliten Internet ist auch schon in der Abklärung,
es ist aber ja immer mal mit Netzausfällen zu rechnen,
deshalb meine Szenario Anfrage.

Fragen
  • Ist so etwas mit Replikation / DB Clustermöglich, wenn ja wie?
  • Master/Master, Master/Slave, ...
  • Wenn nein, mit welcher anderen Technik oder welchem anderen System wäre so etwas möglich?
  • Was habe ich, Eurer Meinung nach übersehen?
  • Was is an meinem Denkansatz vielleicht nicht so optimal?
Ich bin gespannt auf Eure Ideen!

Grüße,
derPeter
 
Werbung:
Was Du suchst, ist asynchrone Multi-Master. Exakt dafür haben wir BDR entwickelt. Das könnte man auch zwischen Erde, Mond und Mars betreiben, mit hohen Latenzen dazwischen bzw. auch Ausfällen der Leistung, es resynchronisiert sich wieder wenn die Verbindung steht. Aber auch ohne Verbindung können alle jederzeit arbeiten.
 
Guten Tag akretschmer,

vielen Dank für die schnelle Antwort.

Haben Sie mir einen Link zu dieser Software, damit ich mich noch weiter in die Materie einlesen kann?
Wo und unter welchen Bedingungen kann ich diese bekommen & nutzen?

Grüße,
derPeter
 
Hallo zusammen,

ich stehe vor einer ähnlichen Aufgabe. Momentan nutze eine reine Single-Master- Multi-Slave-Replikation. Schreibvorgänge werden nur auf einem Server, dem einzigen Master vorgenommen, die anderen dienen nur für schnellere redundante Lesevorgänge. Nachteil ist natürlich: Ist der Master nicht erreichbar, können keine Datenbank-Veränderungen stattfinden. Aber eine andere (schnelle) Lösung habe ich mit MariaDB leider auch noch nicht gefunden. Falls Du was findest, sag hier gerne Bescheid, könnte mir in Zukunft auch noch nützlich sein. ;)

Aktuell läuft es wohl für mein Projekt darauf hinaus, dass ich eine "Zwischendatenbank" aufsetzen werden und auf dem Master in meiner .Net-Anwendung den Abgleich "händisch" durchführen werde (also etwas selber programmiere)... Eine DB-eigene Lösung wäre mir natürlich auch lieber... :)

Gruß,
Andi
 
Versteh' ich nicht. Der Sinn einer Replikation ist doch das der Standby beim Ausfall des Primary nahtlos übernehmen kann.
 
Die Herausforderung besteht bei verteilten Schreibzugriffen, während die Verbindung zwischen den Datenbanken "getrennt ist": Wird z.B. ein und derselbe Datensatz verändert oder neue "Auto-Increment"- Datensätze angelegt - welcher hat dann Gültigkeit, wenn die Replikation wieder startet? Das ist nicht so einfach, dabei entstehen ganz schnell Inkonsistenzen bzw. Replikations-Konflikte... Master-Slave-Replikation: Immer vom Master zum Slave. Es handelt sich dabei nicht wirklich um ein Redundantes System!

Maybe it's possible - keine Ahnung. Ich habe mich da nicht ran getraut, das zu versuchen: Meine Master-Slave-"Redundanz" besteht daher nur für Lesezugriffe. Datensätze schreiben oder verändern: nur auf dem Master. Fällt dieser aus, können noch alle Datensätze gelesen werden. Es ist praktisch als Backup anzusehen. (Aber Vorsicht, dieses Backup hilft nur gegen Ausfälle, nicht gegen falsche Datensätze oder versehentliches Löschen, da diese Anweisungen ja auch auf den Replikationsservern passieren!)

Hier habe ich ein Beispiel gefunden für das Aufsetzen einer Master-to-Master-Replikation: https://www.vpsserver.com/community/tutorials/9/setup-a-master-to-master-replication-between-two-maria-db-servers/

Was aber passiert, wenn die Verbindung zwischen beiden Mastern getrennt ist, (Kommunikationsausfall, Netzausfall), aber auf beiden Servern ein und derselbe Datensatz verändert wird? Wenn dann die Verbindung wieder hergestellt wird, was wird nach wo repliziert? Das gibt ein Konflikt - wer mag, kann das ja mal testen... Wie gesagt, ich habe mich für mein Produktiv-System da nicht ran getraut und mangels Zeit auch kein Test-System gestartet...

Eine Master-Slave-Replikation "könnte" man sicherlich auch so aufsetzen, dass der Slave beim Ausfall des Masters diesen automatisch "nahtlos" übernehmen kann - aber zurück muss das dann händisch passieren. Datensätze des Slaves werden meines Wissens nach nicht wieder zum Master "zurück" übertragen... ( (???? -> lasse mich hier gerne eines besseren belehren!)

Gruß,
Andi
 
Die Herausforderung besteht bei verteilten Schreibzugriffen, während die Verbindung zwischen den Datenbanken "getrennt ist": Wird z.B. ein und derselbe Datensatz verändert oder neue "Auto-Increment"- Datensätze angelegt - welcher hat dann Gültigkeit, wenn die Replikation wieder startet? Das ist nicht so einfach, dabei entstehen ganz schnell Inkonsistenzen bzw. Replikations-Konflikte.

Exakt das addressiert BDR. Das ist in der Tat kein leichtes Thema, die Doku dazu (BDR 3.7 EE) hat einige hundert Seiten, mit Themen wie "Sequences", "Column-Level Conflict Resolution", "Commit at Most Once", "Conflict-free Replicated Data Types", "DDL Replication" und sehr viel mehr. Darin stecken definitiv eine mind. 2-stellige Anzahl von Entwickler-Jahren, mit entsprechenden Kosten. Die Tatsache, daß es wirklich große Kunden nutzen, spricht für sich ...
 
Werbung:
Diverse NoSql Datenbanken haben das Problem mit Multi-Master und getrennten Verbindungen gelöst, mit anderen Nachteilen. Hier wird z.B. auf ACID verzichtet.
Aber wie immer, es kommt auf die Anforderungen an.
 
Zurück
Oben