Ich versuche gerade eine MySql Replikation durchzuführen.

D.h. ich habe zwei identische Linux Suse 9.2 Server.
Wenn bei einem der Server ein neuer Datenbank eintrag gemacht wird, soll unmittelbar die Info an den zweiten Server übermittelt, repliziert werden.

Dabei sollen beide Master als auch Slave sein, d.h. egal auf welchem Server ich den Eintrag mache oder die Löschung, beide sollen immer die selbe Datenbank haben.

Nach dem Lesen der offiziellen MySql Hilfe dazu als auch einigen toll aufgemachten Hilfen, will es immernoch nicht so recht mit der Replikation klappen.
Hab jetzt erstmal versucht, es hinzukriegen, dass EINER der Server Master spielt und seine Datenbank auf den zweiten repliziert. Irgendwo is der Wurm drin.

Hat jemand ein brauchbares HowTo und hats auch selber mal aufgesetzt?

Kann dir das helfen?
http://dev.mysql.com/doc/mysql/de/re...ion-howto.html

Ich hab sowas selber noch nie gemacht und kenne es nur aus der Theorie, aber was genau geht denn nicht?
Arbeitest du mit Binary-Logs?

bis bald
Kermit

Tja, diese Webseite kann ich fast schon auswendig.

Auch noch einige andere, die es etwas anders, aber ähnlich erklären.

Irgendwo hab ich nen Haken. Entweder ein Berechtigungsproblem, oder die Binären Log Dateien sind inkonsistent oder meine Oma ist inkontinent oder Erdstrahlen oder weiss der Geier.
Bin leider auch nicht der DB-Guru und hangel mich so durch. Naja, ich bin sicher, die nächsten Tage krieg ichs raus, dann melde ich woran es lag.

juchheee!!
Das Problem waren die übriggebliebenen Replikations-Leichen, bin-log Dateien sowie Einträge in master.info und relay-log.info. Die musste ich entfernen u. noch fummeln bis der arzt kommt. Aber jezz läufts wie frisch geölt!!! Redundanz ohne gleichen. Wenn der erste Server abkakkt, gehts ohne Pause auf dem zweiten weiter, und der User merkt garnix.

Teile der Doku hier:

My SQL Replication (automatischer Abgleich)

Der Slave-Server sendet eine Anfrage an den Master-Server (I/O-Thread). Der Master-Server startet den Binlog-Dump Thread und sendet seine binäre Logdatei an den Slave-Server. Der Slave-Server startet den SQL--Thread, welcher aus der relay-bin.log Datei des Masters die aktuellen MySql-Anweisungen übernimmt.
Die Dateien master.info und relay-bin.info im Verzeichnis /var/lib/mysql geben darüber Auskunft, bis zu welcher der Bin-Log-Dateien und Relay-Log Dateien und welcher Position bereits repliziert bzw. aktualisiert wurde und knüpfen beim nächsten Replikations Durchlauf daran an. Die Eintragungen macht der MySql Server automatisch und sie dürfen nicht manuell geändert werden.
Sind beide Server gleichzeitig Master und Slave, machen dies alles beide.

Auf beiden Servern steht in der Datei /etc/my.cnf folgendes:
master-host = 192.168.0.1(=entfernter Server)
beim Remote Server steht stattdessen: 192.168.0.2
master-user = repl
master-password= <passwort>
bin-log
log-slave-update

master-host = Hostname oder IP des entfernten Master-Servers
master-user= MySql-User, der die Replikation durchführen darf
master-password=Passwort für die Replikation
bin-log = schaltet das binäre Loggen ein
log-slave-updates = Schaltet das Loggen der Slave-Updates an

Wir legen auf einem Server, zb. mysql.flutsch.de einen MySql User namens repl an, der das „File“ –Recht sowie das „Repl_slave_priv“ Recht bekommt, um die Replikation durchführen zu können. Da später die kompl. Datenbank von mysql.flutsch.de im weiteren Verlauf manuell auf den zweiten Server kopiert wird, muessen wir dies nur auf dem einen Server tun.
mysql –u root –p<passwort> mysql;
mysql>GRANT FILE ON *.* TO repl@192.168.0.1 IDENTIFIED BY ‘passwort’;
mysql>GRANT FILE ON *.* TO repl@192.168.0.2 IDENTIFIED BY ‘passwort’;
mysql>update user set Repl_slave_priv =’Y’ where User= ‘repl‘;
mysql>flush privileges;

Eigentlich würde es reichen, dem User repl nur auf dem gegenüberliegenden Server das Recht zugewähren. Da dies gegenseitig geschehen muss, und wir die DB auf den anderen Server kopieren werden, kann man auch die Berechtigung für beide Server auf einmal geben.
Nun geht die Party richtig los:

1.Auf BEIDEN Servern den mysql Dienst anhalten
/etc/init.d/mysql stop
2.Von einem der beiden Server im Verzeichnis
/var/lib/mysql alle bin-log, relay-bin.log sowie master.info und relay-log.info Dateien
die von eventuellen vorherigen Replikations-Versuchen übrig sind, löschen.
In der Datei /etc/my.cnf den Eintrag bin-log sowie log-slave-updates auskommentieren
(# davorstellen!)
3.Vom mysql.flutsch.de das Verzeichnis /var/lib/mysql packen mit
tar czf mysql.tgz /var/lib/mysql
und auf den anderen Server kopieren mit
scp mysql.tgz root@mysql2.flutsch.de
4. Auf dem anderen Server (mysql2.flutsch.de) das Verzeichnis /var/lib/mysql umbenennen mit
mv /var/lib/mysql /var/lib/mysql.original
5. Auf mysql2.flutsch.de das mysql.tgz entpacken (wir sind im „/“ Verzeichnis!!!)
tar xzvf mysql.tgz
Es wird automatisch ins Verzeichnis /var/lib/ entpackt!!!
6. beide mysql Server starten mit
/etc/init.d/mysql start
7. beide mysql Server stopen mit
/etc/init.d/mysql stop
8. In der Datei
/etc/my.cnf
das Kommentarzeichen vor „bin-log“ und „log-slave-updates“ wieder entfernen.
(auf beiden)
9. Beide MySql Server wieder starten
/etc/init.d/mysql start
10. Mit den MySql Datenbanken verbinden auf beiden Servern
mysql –u root –p<passwort>;
11. Reset von Master und Slave auf beiden Servern durchführen mit
mysql>slave stop;
mysql>reset slave;
mysql>reset master;
mysql>slave start;
mysql>show master status;
mysql>show slave status;
12. Eventuell mysql Dienst nochmals neustarten
/etc/init.d/mysql restart
13. Einen Kaffee trinken;

Danke für diese Anleitung! <img src="http://informatikboard.ch/images/icons/icon14.gif">

Zusammenfassend muss man bei der Replikation folgendes beachten:

1. Vor start des binären loggings müssen die DBs der beiden Server absolut identisch sein.
2. binäres loggen erstmal abschalten (in my.cnf), server starten und beenden und DANN erst wieder einschalten
in my.cnf
3. in der /var/lib/mysql/mysqld.log nach fehlern guggen und im Bedarfsfall Tante Google um Hilfe bitten
4. mit RESET MASTER; SLAVE STOP; RESET SLAVE; SLAVE START; die Repl. auf einen konsistenten Zustand bringen, mit SHOW MASTER STATUS; SHOW SLAVE STATUS; guggen ob die notwenigen threads laufen