- 6 Replikation bei MySQL
- 6.1 Einführung in die Replikation
- 6.2 Replikation: Implementation
- 6.3 Zeilenbasierte Replikation
- 6.4 Replikation: Implementationsdetails
- 6.5 Wie man eine Replikation aufsetzt
- 6.6 Replikation: Kompatibilität zwischen MySQL-Versionen
- 6.7 Upgrade eines Replikationssetups
- 6.8 Replikation: Features und bekannte Probleme
- 6.9 Replikationsoptionen in my.cnf
- 6.10 Wie Server Replikationsregeln auswerten
- 6.11 Replikation: häufig gestellte Fragen
- 6.12 Vergleich zwischen anweisungsbasierter und zeilenbasierter Replikation
- 6.13 Replikation: Problemlösungen
- 6.14 Berichten von Replikationsfehlern und -problemen
- 6.15 Auto-Increment in der Multi-Master-Replikation
MySQL unterstützt die unidirektionale, asynchrone Replikation, bei der ein Server als Master agiert, während mehrere andere Server die Rolle der Slaves erfüllen. Dies steht im Gegensatz zur synchronen Replikation, die ein Kennzeichen von MySQL Cluster ist (siehe auch Kapitel 16, MySQL Cluster).
Bei der Single-Master-Replikation schreibt der Master-Server Updates in seine Binärlogdateien und führt zudem einen Index dieser Dateien, um den Überblick über die Logrotation zu behalten. Die Binärlogdateien dienen als Datenspeicher für Updates, die an alle Slave-Server gesendet werden. Wenn ein Slave eine Verbindung zu seinem Master herstellt, nennt er dem Master die Position, bis zu der er die Logdateien beim letzten erfolgreichen Update gelesen hat. Der Slave empfängt daraufhin alle Änderungen, die seit jenem Zeitpunkt durchgeführt wurden. Nachfolgend wechselt er in den Leerlauf und wartet darauf, dass der Master ihn über neue Aktualisierungen in Kenntnis setzt.
Ein Slave-Server kann seinerseits als Master agieren, um beispielsweise eine Verkettung von Replikationsservern realisieren zu können.
Die Multi-Master-Replikation ist zwar auch möglich, aber hierbei können Probleme auftreten, die bei der Single-Master-Replikation ausgeschlossen sind. Siehe auch Abschnitt 6.15, „Auto-Increment in der Multi-Master-Replikation“.
Sofern Sie die Replikation verwenden, sollten alle Änderungen an Tabellen, die repliziert werden, auf dem Master-Server durchgeführt werden. Andernfalls müssen Sie nämlich immer sorgfältig darauf achten, Konflikte zwischen von Benutzern vorgenommenen Änderungen an den Tabellen auf dem Master und solchen Änderungen zu vermeiden, die an Tabellen auf dem Slave vorgenommen werden. Beachten Sie ferner, dass Updates auf der Slave-Seite abhängig davon, ob Sie eine anweisungs- oder eine datensatzbasierte Replikation verwenden, unterschiedlich verarbeitet werden können. Betrachten Sie einmal das folgende Szenario, bei dem ein Datensatz auf dem Slave eingefügt wird, gefolgt von einer Anweisung auf Master-Seite, die die Tabelle leert:
slave>INSERT INTO tbl VALUES (1);master>DELETE FROM tbl;
Der Master weiß nichts über die
INSERT-Operation auf dem Slave-Server. Bei der
anweisungsbasierten Replikation wird tbl auf
dem Master und dem Slave geleert, sobald der Slave auf den Stand
des Masters gebracht wird, weil der Master seine
DELETE-Anweisung dann an den Slave sendet.
Infolgedessen hat tbl nachfolgend auf beiden
Servern den gleichen Inhalt. Bei der datensatzbasierten
Replikation ist die Wirkung von DELETE auf den
Slave eine andere. Der Master schreibt nämlich jeden aus der
Tabelle zu löschenden Datensatz in sein Binärlog. Der Slave
löscht daraufhin nur diejenigen Datensätze, die dort erscheinen
– und nicht denjenigen, der direkt auf dem Slave eingefügt
worden war. Hieraus ergeben sich unterschiedliche Inhalte der
Tabellen auf dem Master und dem Slave, was zu
Replikationsproblemen führen kann.
Informationen zur datensatzbasierten Replikation finden Sie in Abschnitt 6.3, „Zeilenbasierte Replikation“.
Die Replikation bietet Vorteile in puncto Robustheit, Geschwindigkeit und Systemadministration:
Die Robustheit wird durch eine Master/Slave-Konfiguration erhöht. Im Fall von Problemen auf dem Master können Sie auf den Slave als Sicherungskopie umschalten.
Eine verbesserte Reaktionszeit lässt sich für Clients erzielen, indem die Last bei der Verarbeitung von Clientabfragen auf die Master- und Slave-Server verteilt wird.
SELECT-Abfragen können an einen Slave geschickt werden, um die Verarbeitungsbelastung des Masters zu senken. Allerdings sollten Anweisungen, die Daten verändern, in jedem Fall an den Master geschickt werden, damit die Synchronisation zwischen Master und Slaves erhalten bleibt. Die Lastverteilungsstrategie ist effizient, wenn in erster Linie nichtändernde Abfragen abgesetzt werden – aber dies ist auch der Normalfall.Ein weiterer Vorteil der Replikation besteht darin, dass Sie Datenbanksicherungen über einen Slave-Server durchführen können, ohne den Master zu stören. Der Master verarbeitet dann weiterhin alle Aktualisierungen auch während der Erstellung des Backups. Siehe auch Abschnitt 5.10.1, „Datenbank-Datensicherungen“.
Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.
