MySQL kann keine Master <-> Master Replikation. Wir machen das trotzdem mal mit Ubuntu 12.04 und MySQL 5.5 und hoffen, dass es funktioniert und wir in keine Split Brain Situation laufen. Wir sprechen der Einfachheit halber von db1 und db2 als unterschiedliche MySQL Server Instanzen.
Wir legen auf db1 einen Benutzer mit Replikationsrechten an
GRANT REPLICATION SLAVE , REPLICATION CLIENT ON * . * TO 'repuser'@'%' IDENTIFIED BY 'superpassword';
Jetzt passen wir die beiden MySQL Konfigurationen an. log_bin muss auf beiden natürlich aktiviert sein.
my.cnf auf db1:
server-id = 1 log_bin = /var/log/mysql/mysql-bin.log auto-increment-increment = 2 auto-increment-offset = 2
my.cnf auf db2:
server-id = 2 log_bin = /var/log/mysql/mysql-bin.log auto-increment-increment = 1 auto-increment-offset = 2
Diese auto-increment Optionen dienen dazu, dass es keine Probleme bei Primärschlüsseln, die automatisch hochgezählt werden, gibt.
Jetzt sind wir Faul. Wir stoppen MySQL auf db1 und db2.
$ service mysql stop
Dann löschen oder verschieben wir das MySQL Datadir auf db2. Default liegt das in /var/lib/.
Dann auf db1 als root:
$ rsync -avh --progress --stats /var/lib/mysql db2:/var/lib/
Fein, damit haben jetzt beide Instanzen den gleichen Datenbestand. Da wir als root kopiert haben sollten die Dateirechte stimmen.
Nun starten wir beide Instanzen
$ service mysql start
Wir connecten uns via mysql auf db1 und db2 und schauen mit
mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000003
Position: 107
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
an welcher Stelle sich db1 und db2 befinden und merken uns das. Es sollte zu der Zeit niemand anderes auf db1 und db2 arbeiten. Dann gehen wir via mysql auf db1 und tippen folgendes ein
CHANGE MASTER TO MASTER_HOST='db2', MASTER_USER='repuser', MASTER_PASSWORD='superpassword', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;
bei den Daten MASTER_LOG_FILE und MASTER_LOG_POS geben wir die Daten ein, die wir vorher bei db2 ausgelesen haben.
Dann sind wir mutig und machen ein
mysql> start slave;
mit
mysql> show slave status\G
schauen wir ob die Replikation läuft. Da sollte dann
Slave_IO_Running: Yes Slave_SQL_Running: Yes
auftauchen. Nun gehen wir via mysql auf db2 und machen dort das gleiche
CHANGE MASTER TO MASTER_HOST='db1', MASTER_USER='repuser', MASTER_PASSWORD='superpassword', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;
MASTER_LOG_FILE und MASTER_LOG_POS ist der „SHOW MASTER STATUS\G“ von db1.
dann starten wir auch dort den slave mit
mysql> start slave;
und schauen mit
mysql> show slave status\G
ob die Slave Prozesse laufen
Slave_IO_Running: Yes Slave_SQL_Running: Yes
Fertig, jetzt testen wir ein bisschen und legen auf beiden MySQL Instanzen Datenbanken und Benutzer und und schauen ob diese repliziert werden.
Bemerkungen:
So geht das theoretisch. Auf Sicherheit wurde kein Wert gelegt, da geht eh jeder einen anderen Weg. Slave_IO_Running, Slave_SQL_Running und Seconds_Behind_Master sollte muss man mit Nagios & Co überwachen. Geschrieben werden sollte immer nur auf eine MySQL Instanz, nicht auf die Idee kommen mit mysql-proxy oder so was ein write scale out umsetzen zu wollen. Man kann eine Instanz auf read only setzen so verhindert man ungewollte Manipulation auf dem „Slave“. Der Replikationsuser und root dürfen aber schreiben, sollte man im Hinterkopf behalten. Davor am besten noch pacemaker packen, so das im Notfall problemlos auf den „Slave“ geschwenkt werden kann. Ist man sich sicher was man da tut kann man auch das read only weg lassen. Sollten die Datenbanken irgendwie Inkonsitent werden ist das der Replikation egal solange kein Replikationsfehler geworfen wird.
Mir ist bekannt das es andere und bessere Lösungen gibt, ich wollt es nur mal aufgeschrieben haben.