Frage, MySQL Replikation

D

Domi

Member
Hallo Leute, ich habe mal eine kleine Frage an Euch.
Ich habe mir mal lokal zwei virtuelle Maschinen aufgesetzt zum Testen. Dort habe ich mir dann eine Master-Master Replikation aufgebaut. Funktioniert auch soweit... bei mir geht es jetzt eher um Verständnis und Klarstellung.

Das Master-System gibt die Veränderungen vor und teilt sie mit den anderen Systemen. Ein Slave-System empfängt oder nimmt die Veränderungen nur entgegen. Sollte dort etwas verändert werden, ändert sich dieses aber nicht auf anderen Systemen. Soweit korrekt?

Wenn ich mich nun am MySQL Server mit "mysql -u root -p" anmelde und dort "show master status" eingebe, bekomme ich ja die Information welche Datenbank im Binlog_Do_DB hinterlegt ist und die Positions Nummer. Anhand dieser zwei Daten muss ich ja dann dem anderen Server mit dem Befehl "change master" sagen welche Datei und Position er ansprechen soll.

Jetzt kommt der für mich etwas komische Faktor... Ich glaube, wenn ich den SQL Server neu starte, schreibt er mir diese Informationen anschließend in eine neue Datei und an eine neue Position. Kann das sein?

Wenn der Dienst oder der gesamte Server mal einen Reboot bekommt muss ich doch dem anderen Server wieder mit "change master" die neuen Daten übermitteln, oder irre ich mich da?

Gruß, Domi
 
Korrekt, wenn etwas auf dem Slave geändert wird, erfährt der Master nichts davon. In dem Moment hast du aber grundsätzlich erstmal inkonsistente Datenstände (was man ohnehin immer vermeiden will) und es kann sogar dazu kommen, dass die Replikation früher oder später stehenbleibt.
Nämlich dann, wenn es plötzlich Kollisionen bei PRIMARY- oder UNIQUE-Indizes gibt.
Grundsätzlich sollte man daher den Slave nach Möglichkeit gegen Änderungen schützen. MySQL hat dafür bereits die Konfigurationsmöglichkeit "read-only" in der my.cnf, mit denen alle Tabellen schreibgeschützt werden (auch für root).
Und natürlich die Replikation auf dem Slave überwachen, um mitzubekommen, wenn sie stehengeblieben ist.

Der Master beginnt nach dem Start immer ein frisches Binlog, du fängst also bei jedem Restart mit einer neuen Datei an Position 1 an.
Sobald der Slave sich wieder verbunden hat, versucht er natürlich die Replikation ab der zuletzt verarbeiteten Stelle fortzusetzen. Ist die Datei dort zu Ende, wird automatisch in der nächsten Datei fortgesetzt.
Du brauchst also keinen CHANGE MASTER durchzuführen, wenn du wirklich nichts an der Replikation ändern willst.
 
Alles klärchen.. Dann weiß ich soweit schon mal bescheid und bedanke mich für die Informationen :) Ich hatte nur etwas bedenken, was passiert wenn einer der Server mal einen Reboot aufgrund von Updates etc. macht. Aber dann ist das ja schon mal geklärt und ich bedanke mich.

Gruß, Domi
 
Wenn Du eine Master-Master-Replikation hast fällt auch das RO auf dem Slave weg - weil der seine Änderungen ja auch den Master repliziert.

Solltest Du aber wirklich vorhaben, auf beide DBs schreiben zuzugreifen würde ich da sehr vorsicht sein - am ehesten davon Abstand nehmen. Master-Master ist aus meiner Sicht gut geeignet, eine einfaches Fail-Over-System zu realisieren, bei dem beide Datenbanken die komplette Funktion haben und man im Fall des Falles einfach nur den DB-Host schwenken muss - die Repliaktion ist aber nicht sonderlich robust, wenn auf beide DBs geschrieben wird (bzw. die meisten Anwendungen, die man so gegen MySQL-DBs laufen lässt sind nicht dafür geeignet, das auf beiden Master einer Master-Master-Replikation zu tun)
 
Hm.. Ist ja schon wieder doof.. Aber ja, ein Fail-Over-System war der Grund für die Planung. Wenn mal eine SQL Datenbank nicht erreichbar ist, soll die andere verwendet werden können.

Ich hatte ja gerade erst das Thema Verfügbarkeit in einem anderen Topic angesprochen. Und parallel mit einem Kumpel darüber gesprochen, da er auch einen root-Server hat. Da fragte er mich, ob man mit einer Master-Master Replikation nicht schon mal die DB etwas Verfügbarer machen könne. Und da teste ich das einfach mal aus um ihm am Ende ein paar Infos dazu zu geben.

Aber wenn das nicht so sinnvoll ist, bräuchte ich gar nicht groß weiter testen und könnte ihm das mitteilen.
 
Sinnvoll ist es schon - Du musst Dir nur über die Einschränkungen bzw. Problemfälle der Master-Master-Replikation im Klaren sein.

Solange Du aber immer nur auf eine schreibst und dann im Fall des Falles dann einfach wechselst geht im Normalfall nicht viel schief.
 
Genau so ist eigentlich der Plan... Die Datenbank von Server 1 soll so etwas wie die permanent aktive Datenbank sein. Wenn diese gerade ausfällt (warum auch immer), soll Datenbank 2 mit den gespiegelten Daten angesprochen werden.

Allerdings ist mir vorhin eingefallen... Sollte in Datenbank 2 dann ein UPDATE, INSERT oder ähnliches auftauchen, kann dieses ja nicht an DB1 repliziert werden und wird vermutlich auch nicht nachgetragen, oder irre ich mich da?

Gruß, Domi
 
Domi said:
Allerdings ist mir vorhin eingefallen... Sollte in Datenbank 2 dann ein UPDATE, INSERT oder ähnliches auftauchen, kann dieses ja nicht an DB1 repliziert werden und wird vermutlich auch nicht nachgetragen, oder irre ich mich da?
Click to expand...
warum?

Bei Master-Master wird alles, was auf einem der beiden Master passiert auf den jeweiligen Slave (also "den anderen Master") repliziert.

... zumindest, solange es auf dem Slave keinen SQL-Error erzeugt. Wenn das der Fall wäre (und was man recht einfach provozieren kann) - dann bleibt die Replikation halt stehen.

Steht aber eigentlich auch alles recht gut erklärt in der MySQL-Doku und in dev. HowTos zu dem Thema.
 
You must log in or register to reply here.
Back
Top