MariaDB Replikation geht nur zum ersten Slave, der zweite bekommt nichts

[QuarzSnoopy]

Hallo Leute,

ich hoffe hier kann mir einer weiter helfen.

Ich habe auf 3 Knoten Ubuntu 16.04 mit MariaDB 10.0.
Alle drei sind hintereinander (wie eine Kette) für die Replikation verbunden, zusätzlich hat der 1. Knoten aber den 2. auch als Master.

Für eine besseres Verständnis:

• 1. Knoten hat als Master: 2. Knoten
• 2. Knoten hat als Master: 1. Knoten
• 3. Knoten hat als Master: 2. Knoten

Wenn ich auf dem 1. Knoten eine DB anlege, dann erscheint sie nur auf dem 2. Knoten noch aber nicht auf dem 3. Knoten.

Mit MySQL funktioniert es, aber mit MariaDB geht das bei mir nicht.
Weiß einer worann das liegen kann?
Oder ist das so Absicht? (kann ich mir nicht vorstellen)

Gruß
Snoopy

 

[akretschmer]

Für eine besseres Verständnis:

• 1. Knoten hat als Master: 2. Knoten
• 2. Knoten hat als Master: 1. Knoten
• 3. Knoten hat als Master: 2. Knoten

Wenn ich auf dem 1. Knoten eine DB anlege, dann erscheint sie nur auf dem 2. Knoten noch aber nicht auf dem 3. Knoten.

Mit MySQL funktioniert es, aber mit MariaDB geht das bei mir nicht.

Ich hätte starke Zweifel, daß das mit MySQL *stabil* funktioniert. Was passiert bei Konflikten? Also, schon die gegenseitige Replikation...

 

[QuarzSnoopy]

Hallo akretschmer,
doch das funktioniert gut, es nennt sich Multi-Master-Replikation:
Learn the difference between Multi-Master and Multi-Source replication
Man muss nur ein paar Dinge beachten, z.B. müssen die auto-increment-Variablen richtig gesetzt werden und man darf immer nur in einem Master schreiben.

Aber das spielt bei meinem Problem keine Rolle, auch wenn ich auf dem 1. Knoten den Master-Eintrag lösche, dass es nur eine "Chain" ist, wie hier auf Seite 13 beschrieben:
http://www.oracle.com/technetwork/community/developer-day/mysql-replication-scalability-403030.pdf
... dann habe ich das selbe Problem:

Die Daten gehen nur einen Hop, bis zum ersten Slave, der liefert sie nicht weiter an den letzten in der Kette. :-(

Auch wenn ich die Knoten untereinander tausche, geht es nur einen Hop weit, auch wenn es dann andere Knoten sind...

 

[QuarzSnoopy]

...bei MySQL ist es wichtig, in der Konfiguration die Option log-slave-updates zu setzen...
Bei MariaDB scheint das nicht der Fall zu sein.

Nur was muss man bei MariaDB ersatzweise tun?

Gruß
Snoopy

 

[QuarzSnoopy]

...laut Doku soll es bei MariaDB genauso gehen:
Replication and Binary Log Server System Variables
:-(
...hat einer ne Idee?

 

[QuarzSnoopy]

...ein Anhaltspunkt gefunden:

Nur weil etwas in der CFG eingetragen wurde, muss es noch lange nicht aktiv sein...:-(

ich hab mir mal den aktuellen Wert der Variable ausgeben lassen... und ...
...sie ist nicht gesetzt! :-(
# echo "SELECT @@GLOBAL.LOG_SLAVE_UPDATES;" | mysql -t
+----------------------------+
| @@GLOBAL.LOG_SLAVE_UPDATES |
+----------------------------+
| 0 |
+----------------------------+

Das ist zwar nicht gut aber ich hab jetzt wenigstens einen Anhaltspunkt...

 

[QuarzSnoopy]

Hi,

die Variable "LOG_SLAVE_UPDATES" lässt sich einfach nicht aktivieren...!?
Ich kann die eintragen wo ich will, nichts hilft.
Die anderen Parameter werden entsprechend gesetzt, wie ich sie in der CFG eintrage, nur LOG_SLAVE_UPDATES und SYNC_BINLOG nicht.

Weiß einer woran das liegt?

Gruß
Snoopy

 

[QuarzSnoopy]

...kein Datenbank-Guru da, der mir helfen kann?

 

[QuarzSnoopy]

Ha!
Ich hab die Ursache gefunden.

Für alle, die es interressiert:

In der MariaDB 10.0.31 auf Ubuntu 16.04 (ich weiß nicht in wie weit das auch für andere MarisDBs gilt) herscht in der Standardinstallation folgender Zustand:
- root hat kein Passwort
- root kann nur von localhost aus auf die DB zugreifen
- beim Start wird die Datei /etc/mysql/debian-start ausgeführt
- in der Datei /etc/mysql/debian-start wird die Datei /etc/mysql/debian.cnf benutzt um Benutzer+Passwort für die Initialisierung zu bekommen
- root wird in der Datei für die Initialisierung beim DBMS-Start verwendet (das ist die Voreinstellung in der Datei /etc/mysql/debian.cnf)

Jetzt hatte ich aber dem Benutzer root ein Passwort gegeben.
Damit konnte die Datei /etc/mysql/debian-start nicht mehr richtig arbeiten...

Lösung:
In der Datei /etc/mysql/debian.cnf das root-Passwort eintragen.

Gruß
Snoopy

 

[akretschmer]

doch das funktioniert gut, es nennt sich Multi-Master-Replikation:
Man muss nur ein paar Dinge beachten, z.B. müssen die auto-increment-Variablen richtig gesetzt werden und man darf immer nur in einem Master schreiben.

Hrm. MultiMaster wäre für mich, daß ich auf beiden Seiten schreiben kann. So wie bei BDR, der Multi-Master-Lösung für PostgreSQL, da kann man bis zu 48 aktive Master haben (derzeit)

 

[QuarzSnoopy]

Hrm. MultiMaster wäre für mich, daß ich auf beiden Seiten schreiben kann. So wie bei BDR, der Multi-Master-Lösung für PostgreSQL, da kann man bis zu 48 aktive Master haben (derzeit)

Ja, das ist hier aber MariaDB/MySQL... jeder vergibt halt seine Produktnamen wie er will...
So wie ich das Beschrieben habe (mit Increment-Variable) kann man auch in beide Knoten gleichzeitig rein schreiben... machen wir aber lieber nicht, weil es nur Semi-Synchron ist.
Eine Synchrone Lösung gibt es für MySQL/MariaDB auch, die heißt Galera (WSREP), da kann man bedenkenlos in alle Master gleichzeitig reinschreiben.

Leider hat PostgreSQL sich mit ihrer Chluster-Lösung viel zu lange Zeit gelassen!
Zu Zeiten von PostgreSQL 7 hatte MySQL bereits eine einfach aufzusetzende Lösung... PostgreSQL hat es derzeit noch (von Seiten der Führung) beukottiert und sagte, dass dafür 3rt-Party-Lösungen eingesetzt werden sollen... Dumme Entscheidung!
Vielleicht wäre ich sonst jetzt mit PostgreSQL beschäftigt (hatte mir damals sonst auch viel besser gefallen).

Wie sagte Gorbatschow schon: "Wer zu spät kommt, den bestraft das Leben!".

In dem Sinne.
Gruß
Snoopy

 

[akretschmer]

Nun ja. PostgreSQL 7 ist wie lange her? 8.0 kam 2005. Replikation (in core) kam mit 9.0, also 2010. Aber da gab es schon Lösungen für Replikation: Slony, Londiste, Burardo und wohl noch weitere.


Na egal. Viel Erfolg noch mit MySQL/MariaDB/Galera etc.