Multiple Master-Master Design mit MySQL, MariaDB oder PostgreSQL möglich?

[maen007]

Ich möchte zu Testzwecken versuchen, eine Art geteilte DB zu erschaffen.
Sinn:
Lokale Applikation mit lokaler DB, die sich mit anderen lokalen DBs über eine im Internet befíndliche DB jeweils synchronisiert, falls verfügbar.
Anwendungsgebiet:
Ersatz für Access et al., welche im Team nur dann funktionieren, wenn das benötigte Netzwerk zur Verfügung steht.
Wunsch:
Wie bei MySQL zum Thema grouping und gtid gelesen, sollte es möglich sein, dass sich verschiedene Instanzen automatisch mittels master-master replizieren.
Schema siehe Anhang...
Problem:
Soll laut meiner Recherche unsicher sein!? Da lokale Arbetsplätze gewöhnlich nicht immer verfügbar sind und es mir scheint (meine Iterpretation) dass es zu Fehlern führt wenn ich MySQL8.0 oder MySQL5.7 mit entsprechenden plugins verwende, um besgtes grouing einzuführen, so wäre die nächste Möglichkeit nur, dies üner http statt über sockets zu bauen,

Hat da jemand Erfahrung?

BG
Marc

 

[dabadepdu]

Nein, nicht mit mySQL.

Das Problem, dass unterschiedliche Clients nicht über das gleiche Setup verfügen (könne), ist aber unabhängig von der Datenbank-Software an sich ein Problem. Also will man vielleicht eine "leichtfüßige" Lösung..

Ich habe mal an einem System mitgearbeitet, dass manuelle Replikation durchführt, also SQL Statements auf dem Master generiert und den Clients zur Verfügung stellt (Hauptsächlich SQLite Clients). Änderungen (Die nicht vom Master kommen) werden von dort per Rest API an den Master geschickt.
Das war mit Postgres als Server umgesetzt.

 

[maen007]

Und wenn im setup (bspw. über docker) das gleiche setup drin ist? Also bspw. der host per IP inkl. der credentials angegeben ist, da ändert sich ja nichts!??? Durch die group replication müsste dann doch jeweils alles ohne manuelle transaktion quasi per start, also wenn die lokale master loslegt, synchronisiert werden!???

 

[akretschmer]

Community PostgreSQL kann keine Multi-Master-Replikation. Aber unser BDR kann das. Wir haben 2 Gruppen von Kunden, die das einsetzen:

• absolute Hochverfügbarkeit ohne Umschaltzeiten. Geht ein Server down, kann die Applikation SOFORT auf einen der anderen Master schreiben, ohne erst zu prüfen, ob der bisherige Primary wirklich down ist, ohne Gefahr eine 'Split Brain' etc. Mit repmgr etc. hat man immer bis zu Minuten Ausfall, mit BDR faktisch NULL.
• Replikation über lange Leitungen, die auch mal ausfallen können. Typische Anwender sind weltweite Konzerne mit Standorten überall auf der Erde. Mit nur einem Primary, z.B. in den USA Ostküste, hätten Anwender USA Westküste, Asien, Europa, Südamerika entsprechend hohe Latenzen.

BDR ist normalerweise asynchron, für die erste genannte Anwendungsruppe kann es auch synchron laufen. Dazu kommen Features wie CAMO (Commit at most Once), Timeshared und globally-allocated range Sequences, CRDT Datentypen, Konflikthandling und so weiter. Jedenfalls kann es gut mit Ausfall von Leitungen und Nodes umgehen, es repariert sich von selber wieder.

Allerdings nicht frei. Im Preis der Nutzungslizenz ist aber auch ein DIAMOND-Support enthalten.

tl;dr

BDR funktioniert super, wir haben diverse große Kunden, die es einsetzen. In beiden genannten Szenarien.