Vor beinahe zwei Jahren habe ich einen Eintrag verfasst, wie ich unsere Master-Slave-Replikation aufgesetzt habe. Seit kurzem läuft nun unsere neue Replikation. Natürlich möchte ich auch diese Lösung wieder vorstellen.

Unser Projekt picload.org verursacht pro Sekunde durchschnittlich 300 Schreib-Zugriffe auf eine InnoDB Tabelle. Da dieses transaktionssichere Schreiben sehr rechenintensiv ist, kommt es gerade in der Peaktime zu Asynchronität der Master-Slave-Replikation. Eine temporäre Lösung war deshalb das deaktivieren der Replikation für die entsprechende Tabelle. In den BinLog des Masters kamen die Inserts allerdings trotzdem und der Traffic entstand also auch, da erst der Slave nach dem Holen des Logs entscheidet, welche Einträge er ignoriert.

Also mussten wir eine Möglichkeit finden, um die Last noch optimaler zu verteilen. So kamen wir um eine Master-Master-Replikation also nicht rum. Und da ich eine schnelle Skalierbarkeit bevorzuge, habe ich die Replikation bereits so vorbereitet, dass weitere Slaves hinzugeschalten werden können. Derzeit laufen bei uns insgesamt vier dedizierte Server - zwei Master und zwei Slaves.


Im Folgenden werde ich unsere Änderungen an der Konfiguration vorstellen, basierend auf der Konfiguration der Master-Slave-Replikation. Dieser Beitrag ist also unverzichtbare Lektüre.

Ich habe zur Veranschaulichung noch eine Grafik erstellt. Die roten Markierungen zeigen die Verbindungen der Replikation. Die grünen und blauen Markierungen sind die Lese- und Schreibvorgänge der Clients.


Master 1:

code:

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: server-id = 1 replicate-same-server-id = 0 auto-increment-increment = 2 auto-increment-offset = 1 log-slave-updates log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 1 max_binlog_size = 100M binlog_do_db = datenbank # Slave config slave-skip-errors = 1060,1061,1062 master-host = 10.0.0.1 master-user = slaveuser master-password = passwort master-connect-retry = 60 replicate-do-db = datenbank

Master 2:

code:

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: server-id = 2 replicate-same-server-id = 0 auto-increment-increment = 2 auto-increment-offset = 2 log-slave-updates log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 1 max_binlog_size = 100M binlog_do_db = datenbank # Slave config slave-skip-errors = 1060,1061,1062 master-host = 10.0.0.2 master-user = slaveuser master-password = passwort master-connect-retry = 60 replicate-do-db = datenbank

Slave n:

code:

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: server-id = n # Slave config slave-skip-errors = 1060,1061,1062 master-host = 10.0.0.1 master-user = slaveuser master-password = passwort master-connect-retry = 60 replicate-do-db = datenbank

Zur Erklärung der neuen Parameter:
replicate-same-server-id - Um Schleifen zu verhindern.
auto-increment-increment - Steuert Intervall zwischen Auto-Increment-Werten. Ist die Anzahl der Server im Verbund. mehr...
auto-increment-offset - Startwert des Auto-Increment-Wertes.mehr...
log-slave-updates - Schreibt empfangene Updates in eigenes Binärlog. Dient dazu, dass zusätzliche Slaves dieses Masters auch die Updates der anderen Master bekommt.
slave-skip-errors - Der Slave Thread ignoriert die angegebenen Fehlercodes. Ab und zu kann es zu Increment-Fehlern kommen, die durch einen Bug verursacht werden. Dies ist der bisherige Workaround dafür.

Damit Slave 2 auch die Updates von Master 1 bekommt, muss Master 2 die Updates von Master 1 in seinen BinLog schreiben (vgl. log-slave-updates). Natürlich können an beide Master beliebig viele Slaves gebunden werden. Im Falle eines Ausfalls eines Masters werden die Slaves dieses Masters einfach an den verbleibenden Master gebunden.

Auf allen Servern muss noch der Slave-Thread gestartet werden. Dies geht wie üblich per "CHANGE MASTER TO ..."-Query. Zu beachten ist, dass die Konfiguration die Überkreuz-Replikation beinhaltet (Master 1 ist Slave von Master 2; Master 2 ist Slave von Master 1). Sofern weitere Slaves eingesetzt werden, sollten diese auf beide Master-Server gleichermaßen aufgeteilt werden.