✔ MySQL8-GROUP REPLICATION

[Zvoni]

Hallo zusammen,
dachte ich frage mal hier, bevor ich mich in einem MySQL-Forum registriere.
Kennt sich hier jemand mit der GROUP REPLICATION von MySQL8 aus?

Vorweg: Ja, ich habe die Manuals auf dev.mysql.com zu dem Thema gelesen, aber ich konnte nirgends eine definitive Antwort finden.
Szenario:
ich weiss dass ich für GR unter MySQL8 mindestens drei Server (-Instanzen) benötige. Die habe ich auch (bzw. die werde ich haben --> Zukunft). Gleiche MySQL-Version auf allen 3 Servern setze ich voraus. Variante ist "multi-primary"
Das ganze Setup und die config ist soweit klar,
ABER (und darauf konnte ich keine definitive Antwort finden):
Die Manuals besagen, dass wenn ein GR-Verbund feststellt, dass ein Server nicht mehr antwortet (weil die Putzfrau die Steckdose gebraucht hat...), die verbleibenden Server nach einer gewissen Zeit eventuell zu einem Konsens kommen, und den "fehlenden" Server aus dem Verbund kicken.
Wenn dieser Server nach gewisser Zeit (wie lange auch immer) wieder zurückkommt ("Hi Jungs, i'm back"), besagen die Manuals auch, dass von den verbleibenden Servern ein "donor" gewählt wird, und den Rückkehrer "updatet"

Was ist aber, wenn es genau anderst herum ist?

Hintergrund (Alles explizit/exklusiv in lokalem LAN - nix Internet)
Wir haben (bzw. werden haben) im Einsatz drei MySQL-Server/Instanzen:
S2 und S3 im Serverraum, laufen 24/7, 1 Laptop (=S1)
Auf S2 verbinden sich zwei Kunden-Clients per Intranet-Webseite (Apache etc. lauft auf S2). an S2 finden gemeinhin nur INSERTS statt.
Auf S3 verbinden sich Windows-Clients per propriertärer Software. Nur Lesen (Ist für unsere Anzeige-Tafel)
Auf S1 findet der meiste Traffic statt: Auf S1 (=Laptop) haben wir eine kommerzielle Client-Server-Software, welche auf die lokale ( !! ) MySQL-Instanz des Laptops zugreift, und zwar das volle Brett (CRUD).
Die Idee hinter der GROUP-REPLICATION war, den Traffic für den Laptop zu verringern bzw. auch Backups der Daten zu haben.

Und jetzt der Knackpunkt: Wie es die Natur eines Laptops nunmal ist, wird dieser an Feierabend heruntergefahren, in die Tasche gesteckt, und mit nach Hause genommen (BANG --> S2+S3: "huh? Wo ist Kollege S1?"...*Zeitvergeht*....S2+S3: "OK. Der antwortet nicht mehr." *rauskick*)
Jetzt wird jedoch in dieser "off"-Zeit (die zum Teil mal auch mehr als eine Woche sein kann), Datensätze auf S1 weiter generiert, verändert, gelöscht, das volle Programm.
In dieser "off"-Zeit besteht keinerlei Kontakt zwischen S1 und seinen beiden anderen Kollegen.
Jetzt kommt nach der Off-Zeit Kollege S1 wieder zurück, und meldet sich bei den anderen beiden "Hi, bin wieder da" (Wie macht er das?).
Verstehen S2+S3 jetzt, dass S1 die aktuellsten Daten hat?
Hinweis: Während der Off-Zeit findet absolut keine Veränderung am Datenbestand von S2+S3 statt.
Die Frage also: Ist die GR so intelligent, zu merken, dass eigentlich S1 seine beiden Kollegen updaten muss, und nicht anderst herum?

ich hoffe ich war verständlich!

P.S.: Mir ist natürlich klar, dass ich dass in einem Testsetup auch testen könnte (per try and error), aber fragen kostet nix, und wenn es mir so die ein oder andere Sackgasse erspart habe ich nur gewonnen

 

[Zvoni]

Hallo zusammen,

nach langem hin- und herprobieren, lesen diverser manuals und Foren, mangelnder Antwort hier, bin ich zu folgender Erkenntnis gekommen:

In meinem o.g. Szenario scheint Gourp-Replication das falsche Hilfsmittel zu sein.

Problem: In dem Moment, wo der Laptop heruntergefahren wird, werfen ihn die 2 verbliebenen Server aus der Gruppe. Die MySQL-Instanz auf dem Laptop merkt dann (wenn der Laptop zuhause gestartet wird, und er die beiden Server nicht erreichen kann), dass er nicht mehr in der Gruppe ist, und geht in Super-Read-Only-Mode, da er feststellt, dass er keine "Stimmen-Mehrheit" der Gruppe hat.

OK, sagte ich mir, dann lassen wir auf dem Laptop eben 3 "sandboxed" Instanzen von MySQL laufen (und erzeugen somit eine 5er-Gruppe), dann hat der Laptop definitiv jedesmal die Mehrheit, jedoch mit dem Umstand, dass die Haupt-Instanz von MySQL die Gruppe jedesmal boot-strappen muss (Einstellung in my.ini).

Hier bin ich dann ins nächste Problem gelaufen: Wechselnde IP-Adressen bzw. Netzwerke.

Hat der Laptop im lokalen LAN die Adresse 192.168.3.52, hat er zuhause 192.168.87.36 (oder was auch immer). Und schon finden sich die 3 Instanzen auf dem Laptop gegenseitig nicht mehr, da man in der my.ini für jede Instanz die Local-Address als auch die group-seeds angeben muss, welches per expliziter IP, oder eben hostnamen erfolgen kann. Wobei ich mir da sicher bin, dass es mit der Namensauflösung auf dem Laptop zu tun hat, warum es nicht funktionierte. Klar könnte ich den Adress-Bereich auf dem Router zuhause das auf das gleiche Subnetz 192.168.3.0/24 biegen, aber nu mal wirklich?

Nächstes Problem: Sagen wir, die 3-er-Gruppe des Laptops hat funktioniert, es wurden Datensätze verändert, gelöscht, hinzugefügt, und am nächsten Wochenende wird der Laptop wieder im lokalen LAN gestartet, wo die anderen beiden Server warten.

Die beiden wartenden Server werden von der 3-er-Gruppe nicht wieder automatisch in die 5er-Gruppe zurückgeholt (und anderstherum auch nicht). Ging nur per manuellem Neustart der beiden Server.
Zu umständlich!
Klar hätte ich ein kleines Tool schreiben können, welches auf dem Laptop im Autostart sitzt, um per SSH einen Service-Restart an die beiden Server abzufeuern, aber dazu hätte ich Root im SSH enablen müssen wegen sudo-PW-Abfrage (und über diesen Sicherheits-Aspekt brauchen wir nicht zu diskuttieren).

Wie habe ich es also letztendlich gelöst?
Asynchrone Master-Master-Replikation.
MySQL-Instanz auf Laptop (nur 1 Instanz) ist Master als auch Slave für S2
S2 ist Master als auch Slave für S1 (=Laptop)
S3 ist Slave für S2
Hat den Vorteil, dass die Replikation automatisch gestartet wird, wenn der Laptop zurück ins LAN kommt, und alle "offline" Änderungen an den Daten auf dem Laptop auf S2 und S3 übermittelt werden.
Auch von Vorteil, dass in den my.ini's keinerlei IP-Adressen oder Hostnamen angegeben werden müssen, da die Master/Slave-Definition in den MySQL-Instanzen selbst gespeichert ist (Per CHANGE MASTER-Befehl)

Mir ist natürlich klar, dass diese Variante nicht unbedingt die stabilste ist, und dazu gab es im Netz genug Hinweise und Diskussionen, aber es ist die, welche am besten funktioniert, da es auch funktioniert, wenn S2 und S3 abrauchen sollten (es müssten dann nur die Kunden-Terminals umgebogen werden auf den Laptop)