Inhalt. Vorwort... XI

Transkript

1

2 Inhalt Vorwort XI 1 Die MySQL-Architektur Die logische Architektur von MySQL Nebenläufigkeitskontrolle Transaktionen Multi-Version Concurrency Control Die Storage-Engines von MySQL Engpässe finden: Benchmarking und Profiling Wozu Benchmarks? Benchmarking-Strategien Benchmarking-Taktiken Benchmarking-Werkzeuge Benchmarking-Beispiele Profiling Profiling des Betriebssystems Schema-Optimierung und Indizierung Optimale Datentypen auswählen Grundlagen der Indizierung Indizierungsstrategien für High Performance Indizierung eine Fallstudie Index- und Tabellenpflege Normalisierung und Denormalisierung ALTER TABLE beschleunigen Hinweise zu Storage-Engines V

3 4 Optimierung der Abfrageleistung Grundlagen langsamer Abfragen: Datenzugriff optimieren Methoden zum Umstrukturieren von Abfragen Grundlagen der Abfrageverarbeitung Grenzen des MySQL-Abfrageoptimierers Bestimmte Arten von Abfragen optimieren Hinweise für den Abfrageoptimierer Benutzerdefinierte Variablen Erweiterte MySQL-Funktionen Der MySQL-Abfrage-Cache Code in MySQL speichern Cursor Vorbereitete Anweisungen Benutzerdefinierte Funktionen Sichten Zeichensätze und Sortierreihenfolgen Volltextsuche Fremdschlüsselbeschränkungen Merge-Tabellen und Partitionierung Verteilte (XA-) Transaktionen Die Servereinstellungen optimieren Grundlagen der Konfiguration Allgemeines Tuning Das Ein-/Ausgabeverhalten von MySQL anpassen Die MySQL-Nebenläufigkeit anpassen Lastbasierte Anpassungen Verbindungsbezogene Werte anpassen Betriebssystem- und Hardwareoptimierung Was beschränkt die Leistung von MySQL? Wie Sie CPUs für MySQL auswählen Speicher- und Festplattenressourcen abwägen Hardware für einen Slave wählen RAID-Leistungsoptimierung Storage Area Networks und Network-Attached Storage Mehrere Festplatten-Volumes benutzen Die Netzwerkkonfiguration VI Inhalt

4 Ein Betriebssystem wählen Ein Dateisystem wählen Threading Swapping Der Betriebssystemstatus Replikation Replikation im Überblick Die Replikation einrichten Replikation näher betrachtet Replikationstopologien Replikation und Kapazitätsplanung Replikationsadministration und -wartung Replikationsprobleme und Lösungen Wie schnell ist die Replikation? Die Zukunft der MySQL-Replikation Skalierung und Hochverfügbarkeit Terminologie MySQL skalieren Lastausgleich Hochverfügbarkeit Optimierung auf Anwendungsebene Überblick über die Anwendungsleistung Webserverprobleme Caching MySQL erweitern Alternativen zu MySQL Backup und Wiederherstellung Überblick Überlegungen und Kompromisse Binärlogs organisieren und sichern Daten in einem Backup sichern Wiederherstellung aus einem Backup Backup- und Wiederherstellungsgeschwindigkeit Backup-Werkzeuge Backups mit Skripten Inhalt VII

5 12 Sicherheit Terminologie Account-Grundlagen Betriebssystemsicherheit Netzwerksicherheit Datenverschlüsselung MySQL in einer chroot-umgebung Der MySQL-Serverstatus Systemvariablen SHOW STATUS SHOW INNODB STATUS SHOW PROCESSLIST SHOW MUTEX STATUS Status der Replikation INFORMATION_SCHEMA Werkzeuge für High Performance Schnittstellenwerkzeuge Überwachungswerkzeuge Analysewerkzeuge MySQL-Dienstprogramme Weitere Informationsquellen A Große Dateien übertragen B EXPLAIN benutzen C Sphinx mit MySQL benutzen D Sperren debuggen Index VIII Inhalt

6 KAPITEL 8 Replikation Die in MySQL integrierte Fähigkeit zur Replikation ist die Grundlage für den Aufbau großer, leistungsstarker Anwendungen auf MySQL-Basis. Die Replikation erlaubt es Ihnen, einen oder mehrere Server als Slaves oder Repliken eines anderen Servers zu konfigurieren. Das ist nicht nur für High-Performance-Anwendungen sinnvoll, sondern auch für viele andere Aufgaben, wie etwa das gemeinsame Benutzen von Daten mit einem externen Büro, das Vorhalten eines»hot Spare«oder das Betreiben eines Servers mit einer Kopie der Daten zu Test- oder Schulungszwecken. Wir untersuchen in diesem Kapitel alle Aspekte der Replikation. Wir beginnen mit einem Überblick über die Funktionsweise, schauen uns dann die grundlegenden Servereinstellungen, die Gestaltung aufwendigerer Replikationskonfigurationen sowie die Verwaltung und Optimierung der replizierten Server an. Obwohl wir uns in diesem Buch im Allgemeinen vor allem auf die Performance konzentrieren, kümmern wir uns in Bezug auf die Replikation auch um die Korrektheit und die Zuverlässigkeit. Außerdem schauen wir uns einige künftige Änderungen und Verbesserungen bei der MySQL-Replikation an, wie etwa interessante Patches, die von Google geschaffen wurden. Replikation im Überblick Das Grundproblem, das mithilfe der Replikation gelöst wird, ist Folgendes: Wie hält man die Daten eines Servers synchron zu den Daten eines anderen? Viele Slaves können sich mit einem einzigen Master verbinden, und ein Slave kann wiederum als Master auftreten. Sie können Master und Slaves in vielen unterschiedlichen Topologien anordnen. Sie können den gesamten Server oder nur bestimmte Datenbanken replizieren oder sogar wählen, welche Tabellen Sie replizieren wollen. MySQL unterstützt zwei Arten der Replikation: anweisungsbasierte Replikation und zeilenbasierte Replikation. Die anweisungsbasierte (oder»logische«) Replikation gibt es seit MySQL Sie wird von den meisten Leuten heutzutage in der Praxis eingesetzt. Zeilenbasierte Replikation ist dagegen neu in MySQL 5.1. Bei beiden Arten werden Änderungen 373

7 im Binärlog des Masters 1 aufgezeichnet, und das Log wird dann auf dem Slave wieder abgespielt. Beide sind asynchron d.h., es gibt keine Garantie, dass die Kopie der Daten auf dem Slave in jedem Moment auf dem neuesten Stand ist. 2 Es gibt keine Gewähr, wie groß die Latenz auf dem Slave sein könnte. Große Abfragen könnten dafür sorgen, dass der Slave Sekunden, Minuten oder sogar Stunden hinter den Master zurückfällt. Die Replikation ist in MySQL meist abwärtskompatibel. Das heißt, dass ein neuerer Server normalerweise ohne Probleme der Slave eines älteren Servers sein kann. Ältere Versionen des Servers dagegen sind oft nicht in der Lage, als Slaves der neueren Versionen zu dienen: Sie verstehen möglicherweise neue Funktionen oder die SQL-Syntax nicht, die neuere Server benutzen, außerdem können sich die bei der Replikation verwendeten Dateiformate unterscheiden. So können Sie z.b. nicht von einem MySQL-5.0-Master zu einem MySQL-4.0-Slave replizieren. Testen Sie auf jeden Fall Ihre Replikationseinstellung, bevor Sie von einer Hauptversion auf eine andere wechseln, also etwa von 4.1 auf 5.0 oder von 5.0 auf 5.1. Die Replikation erhöht im Allgemeinen den Aufwand auf dem Master nicht sehr. Auf dem Master muss das binäre Logging aktiviert sein, das recht aufwendig sein kann, allerdings brauchen Sie das sowieso für ordentliche Backups. Abgesehen vom Binär-Logging bringt beim normalen Betrieb auch jeder angeschlossene Slave eine gewisse zusätzliche Last auf dem Master mit sich (hauptsächlich Netzwerk-Ein-/Ausgaben). Replikation eignet sich relativ gut zum Skalieren von Leseoperationen, die Sie an einen Slave umleiten können, ist allerdings nur dann eine gute Methode zum Skalieren von Schreibvorgängen, wenn Sie sie richtig gestaltet haben. Beim Anschließen vieler Slaves an einen Master werden die Schreiboperationen lediglich viele Male, nämlich einmal auf jedem Slave, ausgeführt. Das gesamte System ist auf die Anzahl der Schreiboperationen beschränkt, die der schwächste Teil ausführen kann. Auch wenn man mehr als nur ein paar Slaves hat, ist eine Replikation eine Verschwendung, weil dabei im Prinzip eine Menge Daten unnötigerweise dupliziert werden. So besitzt z.b. ein einziger Master mit 10 Slaves 11 Kopien derselben Daten und dupliziert den größten Teil dieser Daten in 11 unterschiedliche Caches. Das ist analog zu einem 11- fachen RAID 1 auf der Serverebene. Es ist keine ökonomische Anwendung der Hardware, kommt aber überraschend oft vor. Wir werden in diesem Kapitel Methoden vorstellen, um dieses Problem zu umgehen. 1 Wenn das Binärlog neu für Sie ist, finden Sie in Kapitel 6, in diesem Kapitel und in Kapitel 11 weitere Informationen. 2 Mehr dazu finden Sie in»synchrone MySQL-Replikation«auf Seite Kapitel 8: Replikation

8 Probleme, die durch die Replikation gelöst werden Hier sind einige der gebräuchlichsten Anwendungsfälle für die Replikation: Datenverteilung Die Replikation von MySQL ist normalerweise nicht sehr bandbreitenintensiv, 3 und Sie können sie nach Belieben stoppen und starten. Sie eignet sich daher, um eine Kopie Ihrer Daten an einem räumlich entfernten Ort anzulegen, wie etwa in einem anderen Rechenzentrum. Der entfernte Slave kann sogar über eine Verbindung agieren, die nur sporadisch existiert (ob absichtlich oder nicht). Falls Ihre Slaves allerdings nur eine geringe Verzögerung bei der Replikation haben sollen, brauchen Sie eine stabile Verbindung mit geringer Latenz. Lastausgleich Die MySQL-Replikation kann Ihnen dabei helfen, Leseabfragen über mehrere Server zu verteilen, was auch gut für leseintensive Anwendungen funktioniert. Mit einigen einfachen Codeänderungen erreichen Sie sogar einen einfachen Lastausgleich. In kleinem Maßstab benutzen Sie vereinfachte Ansätze, wie fest kodierte Hostnamen oder Lastverteilung per DNS (bei dem ein Hostname auf mehrere IP-Adressen zeigt). Sie können auch raffiniertere Ansätze verfolgen. Normale Lösungen zum Lastausgleich, wie etwa Produkte zum Lastausgleich in Netzwerken, können die Last zwischen MySQL-Servern verteilen. Auch das LVS-Projekt (Linux Virtual Server) funktioniert ganz gut. Wir befassen uns in Kapitel 9 mit Lastausgleich. Backups Replikation bietet eine wertvolle Technik zum Unterstützen von Backups. Allerdings stellt ein Slave weder ein Backup noch einen Ersatz für Backups dar. Hochverfügbarkeit und Failover Mithilfe der Replikation können Sie vermeiden, dass MySQL der einzige Schwachpunkt in Ihrer Anwendung ist. Mit einem guten Failover-System (System zur Ausfallsicherung) mit replizierten Slaves können Sie die Ausfallzeiten drastisch verringern. Failover behandeln wir ebenfalls in Kapitel 9. Testen von MySQL-Upgrades Es ist üblich, einen Slave-Server mit einer aufgerüsteten MySQL-Version auszustatten und mit seiner Hilfe zu überprüfen, ob die Abfragen erwartungsgemäß funktionieren, bevor man alle anderen Server umrüstet. Wie die Replikation funktioniert Bevor wir uns detailliert damit befassen, wie man die Replikation einrichtet, wollen wir uns anschauen, wie MySQL tatsächlich Daten repliziert. Global gesehen, handelt es sich bei der Replikation um einen einfachen dreiteiligen Vorgang: 3 Obwohl, wie wir später sehen werden, die zeilenbasierte Replikation, die in MySQL 5.1 eingeführt wurde, viel mehr Bandbreite benutzen könnte als die traditionellere, anweisungsbasierte Replikation. Replikation im Überblick 375

9 1. Der Master zeichnet die Änderungen an seinen Daten in seinem Binärlog auf. (Diese Aufzeichnungen werden als Binärlog-Events bezeichnet.) 2. Der Slave kopiert die Binärlog-Events des Masters in sein Relay-Log. 3. Der Slave spielt die Ereignisse im Relay-Log noch einmal ab und wendet damit die Änderungen auf seine eigenen Daten an. Das ist nur der Überblick die einzelnen Schritte sind relativ komplex. Abbildung 8-1 verdeutlicht die Replikation im Detail. Master Binärlog Lesen Abbildung 8-1: Wie die MySQL-Replikation funktioniert Datenänderungen Ein/Ausgabe- Thread Schreiben Der erste Teil dieses Vorgangs ist das Schreiben in das Binärlog auf dem Master (wir zeigen Ihnen später, wie Sie das einrichten). Direkt, bevor eine Transaktion, die Daten auf dem Master aktualisiert, fertig wird, schreibt der Master die Änderungen in sein Binärlog. MySQL schreibt die Transaktionen seriell in das Binärlog, auch wenn die Anweisungen in den Transaktionen während der Ausführung verschachtelt wurden. Nachdem die Events in das Binärlog geschrieben wurden, weist der Master die Storage-Engine(s) an, die Transaktionen zu bestätigen. Im nächsten Schritt muss der Slave das Binärlog des Masters auf seine eigene Festplatte kopieren, und zwar in das sogenannte Relay-Log. Zuerst startet er einen Arbeits-Thread, den Ein-/Ausgabe-Slave-Thread. Der Ein-/Ausgabe-Thread öffnet eine normale Clientverbindung zum Master und startet dann einen speziellen Binlog-Dump-Prozess (es gibt dazu keinen SQL-Befehl). Der Binlog-Dump-Prozess liest die Events aus dem Binärlog des Masters. Er fragt nicht nach Events. Wenn er mit dem Master fertig ist, wird er zurückgestellt und wartet auf das Signal des Masters, das besagt, dass es wieder neue Events gibt. Der Ein-/Ausgabe-Thread schreibt die Events in das Relay-Log des Slaves. Slave Lesen Relay- Log SQL-Thread Wiederabspielen 376 Kapitel 8: Replikation

10 Vor MySQL 4.0 funktionierte die Replikation in vielen Aspekten ganz anders. Zum Beispiel verwendete die erste Replikationsfunktionalität von MySQL kein Relay-Log, so dass bei der Replikation nur zwei Threads zum Einsatz kamen und nicht drei. Die meisten Leute verwenden inzwischen aber neuere MySQL-Versionen, wir werden uns daher in diesem Kapitel nicht über die sehr alten Versionen von MySQL auslassen. Der SQL-Slave-Thread erledigt den letzten Teil des Vorgangs. Dieser Thread liest die Events aus dem Relay-Log und spielt sie wieder ab, wobei er die Daten des Slaves aktualisiert, damit sie schließlich denen des Masters entsprechen. Solange dieser Thread mit dem Ein-/Ausgabe-Thread Schritt hält, bleibt das Relay-Log normalerweise im Cache des Betriebssystems, Relay-Logs verursachen also einen sehr geringen Overhead. Die Events, die der SQL-Thread ausführt, können optional in das Slave-eigene Binärlog übernommen werden. Wir kommen später auf Szenarien zurück, bei denen sich das als sinnvoll erweist. Abbildung 8-1 zeigte nur zwei Replikations-Threads auf dem Slave. Es gibt aber außerdem einen Thread auf dem Master: Wie jede Verbindung zu einem MySQL-Server startet die Verbindung, die der Slave zum Master öffnet, einen Thread auf dem Master. Diese Replikationsarchitektur koppelt die Vorgänge des Holens und des Abspielens von Events auf dem Slave voneinander ab, wodurch sie asynchron ausgeführt werden können. Das heißt, der Ein-/Ausgabe-Thread kann unabhängig vom SQL-Thread arbeiten. Sie erlegt dem Replikationsprozess außerdem Beschränkungen auf, von denen die wichtigste lautet, dass die Replikation auf dem Slave serialisiert wird. Das bedeutet, dass Aktualisierungen, die auf dem Master möglicherweise parallel (in unterschiedlichen Threads) ausgeführt wurden, auf dem Slave nicht parallelisiert werden können. Wie wir später sehen werden, ist das für viele Lasten ein möglicher Performance-Engpass. Die Replikation einrichten Das Einrichten der Replikation ist in MySQL ein relativ einfacher Vorgang, es gibt für die grundlegenden Schritte allerdings viele Variationen, die vom jeweiligen Szenario abhängen. Das einfachste Szenario sind frisch installierte Master und Slaves. Auf einer höheren Ebene sieht das Vorgehen so aus: 1. einrichten der Replikations-Accounts auf jedem Server 2. konfigurieren von Master und Slave 3. den Slave anweisen, eine Verbindung zum Master herzustellen und ihn zu replizieren Hier wird davon ausgegangen, dass viele Standardeinstellungen ausreichen, was in der Tat zutrifft, wenn Sie den Master und den Slave gerade installiert haben und sie die gleichen Daten aufweisen (die vorgegebene mysql-datenbank). Wir zeigen Ihnen, wie Sie die einzelnen Schritte ausführen. Dabei nehmen wir an, dass Ihre Server server1 (IP-Adresse ) und server2 (IP-Adresse ) heißen. Anschließend erläutern wir, wie man einen Slave von einem Server aus initialisiert, der bereits läuft, und untersuchen die empfohlene Replikationskonfiguration. Die Replikation einrichten 377

11 Replikations-Accounts anlegen MySQL verfügt über einige besondere Berechtigungen, die den Replikationsprozessen die Ausführung erlauben. Der Slave-Ein-/Ausgabe-Thread, der auf dem Replikations- Slave-Server läuft, stellt eine TCP/IP-Verbindung zum Master her. Sie müssen also einen Benutzer-Account auf dem Master anlegen und diesem die richtigen Berechtigungen verleihen, damit der Ein-/Ausgabe-Thread sich als dieser Benutzer anmelden und das Binärlog des Masters lesen kann. Wir erzeugen hier einen Benutzer-Account namens repl: mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* -> TO IDENTIFIED BY 'p4ssword'; Diesen Account legen wir sowohl auf dem Master als auch auf dem Slave an. Beachten Sie, dass wir den Benutzer auf das lokale Netzwerk beschränkt haben, weil der Replikations-Account unsicher ist. (In Kapitel 12 erfahren Sie mehr über die Sicherheit.) Der Replikationsbenutzer benötigt eigentlich nur die Berechtigung REPLI- CATION CLIENT auf dem Master; die Berechtigung REPLICATION SLAVE auf beiden Servern ist nicht erforderlich. Weshalb also gewähren wir diese Berechtigungen auf beiden Servern? Das hat zwei Gründe: Der Account, den Sie benutzen, um die Replikation zu überwachen und zu verwalten, braucht die Berechtigung REPLICATION SLAVE. Es ist einfacher, den gleichen Account für beide Zwecke einzusetzen, anstatt einen eigenen Benutzer für diese Aufgabe anzulegen. Wenn Sie den Account auf dem Master einrichten und dann den Slave vom Master klonen, wird der Slave korrekterweise so eingerichtet, dass er als Master agiert, falls Sie irgendwann einmal die Rollen von Master und Slave vertauschen wollen. Master und Slave konfigurieren Der nächste Schritt besteht darin, einige Einstellungen auf dem Master zu aktivieren, der bei uns den Namen server1 tragen soll. Sie müssen das Binär-Logging einschalten und eine Server-ID angeben. Setzen Sie die folgenden Zeilen in die my.cnf-datei des Masters (oder überprüfen Sie, ob diese Zeilen vorhanden sind): log_bin = mysql-bin server_id = 10 Die exakten Werte müssen Sie selbst einsetzen. Wir nehmen hier den einfachsten Weg, Sie können natürlich etwas Raffinierteres verwenden. Sie müssen explizit eine eindeutige Server-ID festlegen. Wir haben beschlossen, 10 anstelle von 1 zu nehmen, weil 1 die Vorgabe ist, die ein Server typischerweise wählt, wenn kein Wert angegeben wurde. (Das ist versionsabhängig; manche MySQL-Versionen funktionieren dann einfach nicht.) Die 1 kann deshalb leicht zu Verwirrung und Konflikten mit Servern führen, die keine expliziten Server-IDs besitzen. Oft wird das letzte Oktett der IP- Adresse des Servers benutzt, vorausgesetzt natürlich, dass die Adresse sich nicht ändert und eindeutig ist (d.h., dass die Server nur zu einem Subnetz gehören). 378 Kapitel 8: Replikation

12 Wenn das Binär-Logging noch nicht in der Konfigurationsdatei des Masters angegeben war, müssen Sie MySQL neu starten. Um sicherzustellen, dass die Binärlog-Datei auf dem Master angelegt wurde, führen Sie SHOW MASTER STATUS aus und überprüfen, ob Sie eine Ausgabe erhalten, die der folgenden Ausgabe ähnelt. (MySQL hängt einige Ziffern an den Dateinamen an, Sie sehen daher bei der Datei nicht exakt den Namen, den Sie angegeben haben.) mysql> SHOW MASTER STATUS; File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin row in set (0.00 sec) Der Slave verlangt in seiner my.cnf-datei eine Konfiguration ähnlich der des Masters, außerdem müssen Sie MySQL auf dem Slave neu starten: log_bin = mysql-bin server_id = 2 relay_log = mysql-relay-bin log_slave_updates = 1 read_only = 1 Technisch gesehen, sind einige dieser Optionen nicht erforderlich, und für einige geben wir einfach nur explizit die Vorgabewerte an. Tatsächlich wird auf einem Slave nur der Parameter server_id verlangt, wir haben aber auch log_bin aktiviert und der Binärlog- Datei einen expliziten Namen gegeben. Standardmäßig wird sie nach dem Hostnamen des Servers benannt, das kann aber zu Problemen führen, wenn sich der Hostname ändert. Außerdem wollen wir, dass die Logs jedes Servers gleich heißen, um eine einfache Slave-zu-Master-Umwandlung zu erlauben. Das heißt, nicht nur der Replikationsbenutzer auf Master und Slave ist gleich, sondern auch die Einstellungen für beide. Wir haben außerdem zwei weitere optionale Konfigurationsparameter hinzugefügt: relay_log (um die Lage und den Namen des Relay-Logs anzugeben) und log_slave_ updates (damit der Slave die replizierten Events in sein eigenes Binärlog schreiben kann). Die zweite Option verursacht auf den Slaves zusätzliche Arbeit, doch wie Sie später sehen werden, haben wir gute Gründe dafür, diese optionalen Einstellungen auf jedem Slave hinzuzufügen. Manche Leute aktivieren nur das Binärlog und nicht log_slave_updates, so dass sie es merken, ob irgendetwas, wie etwa eine fehlkonfigurierte Anwendung, Daten auf dem Slave modifiziert. Falls möglich sollten Sie die Konfigurationseinstellung read_only benutzen, die verhindert, dass andere als die besonders berechtigten Threads Daten ändern. (Gewähren Sie Ihren Benutzern nicht mehr Berechtigungen als nötig!) Allerdings ist read_only oft nicht praktisch, vor allem nicht für Anwendungen, die in der Lage sein müssen, Tabellen auf Slaves zu erzeugen. Die Replikation einrichten 379

13 Setzen Sie die Replikationskonfigurationsoptionen, wie etwa master_host und master_port, nicht in die my.cnf-datei des Slaves. Diese alte Methode der Konfiguration eines Slaves wird nicht mehr empfohlen. Sie kann Probleme verursachen und bringt keine Vorteile mit sich. Den Slave starten Der nächste Schritt besteht darin, dass man dem Slave mitteilt, wie er sich mit dem Server verbinden und seine Binärlogs abspielen soll. Benutzen Sie dafür nicht die Datei my.cnf, sondern nehmen Sie die Anweisung CHANGE MASTER TO. Diese Anweisung ersetzt die entsprechenden my.cnf-einstellungen komplett. Sie erlaubt es Ihnen auch, den Slave in Zukunft auf einen anderen Master zu richten, ohne den Server zu stoppen. Hier ist die Anweisung, die Sie zum Start der Replikation auf dem Slave ausführen müssen: mysql> CHANGE MASTER TO MASTER_HOST='server1', -> MASTER_USER='repl', -> MASTER_PASSWORD='p4ssword', -> MASTER_LOG_FILE='mysql-bin ', -> MASTER_LOG_POS=0; Der Parameter MASTER_LOG_POS ist auf 0 gesetzt, weil dies der Anfang des Logs ist. Nachdem Sie dies ausgeführt haben, sollten Sie anhand der Ausgabe von SHOW SLAVE STATUS feststellen können, dass die Einstellungen des Slaves korrekt sind: mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin Read_Master_Log_Pos: 4 Relay_Log_File: mysql-relay-bin Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin Slave_IO_Running: No Slave_SQL_Running: No...omitted... Seconds_Behind_Master: NULL Die Spalten Slave_IO_State, Slave_IO_Running und Slave_SQL_Running zeigen, dass die Slave-Prozesse nicht laufen. Scharfsinnige Leser werden auch bemerken, dass die Log- Position 4 anstelle von 0 ist. Das liegt daran, dass 0 eigentlich keine Log-Position ist; sie bedeutet nur»am Anfang der Log-Datei«. MySQL weiß, dass das erste Event tatsächlich an Position 4 kommt. 4 4 Wie Sie an der früheren Ausgabe von SHOW MASTER STATUS erkennen können, befindet es sich tatsächlich an Position 98. Master und Slave machen das miteinander aus, sobald der Slave sich mit dem Master verbunden hat, was noch nicht geschehen ist. 380 Kapitel 8: Replikation

14 Um die Replikation zu starten, führen Sie folgenden Befehl aus: mysql> START SLAVE; Dieser Befehl erzeugt keine Fehlermeldungen oder Ausgaben. Untersuchen Sie jetzt noch einmal SHOW SLAVE STATUS: mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin Read_Master_Log_Pos: 164 Relay_Log_File: mysql-relay-bin Relay_Log_Pos: 164 Relay_Master_Log_File: mysql-bin Slave_IO_Running: Yes Slave_SQL_Running: Yes...omitted... Seconds_Behind_Master: 0 Sie sehen, dass sowohl die Slave-Ein-/Ausgabe- als auch die SQL-Threads laufen und dass Seconds_Behind_Master nicht mehr NULL ist (wir untersuchen später, was Seconds_Behind_Master bedeutet). Der Ein-/Ausgabe-Thread wartet auf ein Event vom Master, was bedeutet, dass er alle Binärlogs des Masters geholt hat. Die Log-Positionen haben sich erhöht, es wurden also einige Events geholt und ausgeführt (Ihre Ergebnisse werden anders aussehen). Wenn Sie auf dem Master eine Änderung vornehmen, sollten Sie sehen, dass sich die verschiedenen Datei- und Positionseinstellungen auf dem Slave erhöhen. Sie sollten auch Änderungen an den Datenbanken auf dem Slave feststellen können! Sie erkennen auch die Replikations-Threads in den jeweiligen Prozesslisten auf dem Master und dem Slave. Auf dem Master sollten Sie eine Verbindung sehen, die vom Ein-/Ausgabe-Thread des Slaves erzeugt wurde: mysql> SHOW PROCESSLIST\G *************************** 1. row *************************** Id: 55 User: repl Host: slave1.webcluster_1:54813 db: NULL Command: Binlog Dump Time: State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL Auf dem Slave müssen Sie zwei Threads sehen. Einer ist der Ein-/Ausgabe-Thread, der andere ist der SQL-Thread: Die Replikation einrichten 381

15 mysql> SHOW PROCESSLIST\G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 2 User: system user Host: db: NULL Command: Connect Time: 33 State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL Die gezeigte Beispielausgabe stammt von Servern, die schon lange laufen, weshalb die Time-Spalten der Ein-/Ausgabe-Threads auf dem Master und dem Slave große Werte zeigen. Der SQL-Thread auf dem Slave war 33 Sekunden lang untätig, was bedeutet, dass 33 Sekunden lang keine Events eingespielt wurden. Diese Prozesse laufen immer unter dem Benutzer-Account»system user«, die anderen Spalten zeigen bei Ihnen dagegen andere Werte. Wenn z.b. der SQL-Thread ein Event auf dem Slave abspielt, zeigt die Info-Spalte, dass die Abfrage ausgeführt wird. Falls Sie ein bisschen mit der MySQL-Replikation herumspielen wollen, dann kann Giuseppe Maxias MySQL-Sandbox-Skript ( net/projects/mysql-sandbox/) eine»spielinstallation«aus einer frisch heruntergeladenen MySQL-tar-Datei starten. Es sind nur einige Tastendrücke und etwa 15 Sekunden nötig, um einen Master und zwei Slaves zum Laufen zu bringen: $./set_replication.pl ~/mysql linux-x86_64-glibc23.tar.gz Einen Slave von einem anderen Server aus initialisieren Die gerade gezeigten Hinweise zur Einrichtung gingen davon aus, dass Sie Master und Slave nach einer Neuinstallation mit den vorgegebenen Anfangsdaten gestartet haben, so dass Sie implizit die gleichen Daten auf beiden Servern hatten und die Binärlog-Koordinaten des Masters kannten. Das ist nicht unbedingt der typische Fall. Normalerweise werden Sie bereits einen Master am Laufen haben und wollen einen neu installierten Slave mit diesem synchronieren, obwohl dieser nicht die Daten des Masters besitzt. Es gibt verschiedene Möglichkeiten, einen Slave von einem anderen Server aus zu initialisieren oder zu»klonen«. Dazu gehört das Kopieren der Daten vom Master, das Klonen eines Slaves von einem anderen Slave aus und das Starten eines Slaves aus einem aktuellen Backup. Sie brauchen drei Dinge, um einen Slave mit einem Master zu synchronisieren: 382 Kapitel 8: Replikation

16 Einen Schnappschuss der Daten des Masters zu einem bestimmten Zeitpunkt. Die aktuelle Log-Datei des Masters und den Byte-Offset innerhalb dieses Logs zu dem exakten Zeitpunkt, zu dem Sie den Schnappschuss erzeugt haben. Wir bezeichnen diese beiden Werte als Log-Datei-Koordinaten, weil sie zusammen eine Binärlog-Position kennzeichnen. Sie können die Log-Datei-Koordinaten des Masters mit dem Befehl SHOW MASTER STATUS ermitteln. Die Binärlog-Dateien des Masters von diesem Zeitpunkt bis zu Gegenwart. Dies sind Methoden, um einen Slave von einem anderen Server zu klonen: Mit einer kalten Kopie Eine der einfachsten Methoden, um einen Slave zu starten, besteht darin, den potenziellen Master herunterzufahren und seine Dateien auf den Slave zu kopieren (in Anhang A erfahren Sie, wie Sie Dateien effizient kopieren). Sie können dann den Master wieder starten, der dann ein neues Binärlog beginnt, und CHANGE MASTER TO einsetzen, um den Slave am Anfang dieses Binärlogs zu starten. Der Nachteil dieser Technik ist offensichtlich: Sie müssen den Master herunterfahren, während Sie die Kopie anlegen. Mit einer warmen Kopie Wenn Sie nur MyISAM-Tabellen benutzen, können Sie die Dateien mit mysqlhotcopy kopieren, während der Server läuft. Näheres erfahren Sie in Kapitel 11. Mittels mysqldump Falls Sie nur InnoDB-Tabellen verwenden, können Sie den folgenden Befehl verwenden, um alles vom Master zu speichern, es in den Slave zu laden und die Koordinaten des Slaves auf die entsprechende Position im Binärlog des Masters zu ändern: $ mysqldump --single-transaction --all-databases --master-data=1 --host=server1 mysql --host=server2 Die Option --single-transaction veranlasst den Dump, die Daten so zu lesen, wie sie am Anfang der Transaktion vorlagen. Diese Option kann auch bei anderen transaktionsfähigen Storage-Engines funktionieren, wir haben sie aber nicht getestet. Falls Sie keine transaktionsfähigen Tabellen verwenden, können Sie die Option --lock-alltables einsetzen, um einen konsistenten Dump aller Tabellen zu bekommen. Mit einem LVM-Schnappschuss oder einem Backup Wenn Sie die entsprechenden Binärlog-Koordinaten kennen, können Sie einen LVM-Schnappschuss vom Master oder einem Backup benutzen, um den Slave zu initialisieren (falls Sie ein Backup verwenden, dann verlangt diese Methode, dass Sie alle Binärlogs des Masters seit dem Zeitpunkt des Backups aufbewahrt haben). Stellen Sie einfach das Backup oder den Schnappschuss auf dem Slave wieder her, und benutzen Sie dann die passenden Binärlog-Koordinaten in CHANGE MASTER TO. Mehr dazu erfahren Sie in Kapitel 11. InnoDB Hot Backup, das ebenfalls in Kapitel 11 behandelt wird, ist eine gute Methode, um einen Slave zu initialisieren, falls Sie nur InnoDB-Tabellen benutzen. Die Replikation einrichten 383

17 Von einem anderen Slave Mit einer der erwähnten Schnappschuss- oder Klontechniken können Sie einen Slave aus einem anderen klonen. Falls Sie allerdings mysqldump verwenden, funktioniert die Option --master-data nicht. Anstatt SHOW MASTER STATUS zu benutzen, um die Binärlog-Koordinaten des Masters zu erhalten, müssen Sie SHOW SLAVE STATUS einsetzen, damit Sie die Position finden, an der der Slave auf dem Master ausgeführt wurde, als Sie den Schnappschuss erzeugt haben. Der größte Nachteil beim Klonen eines Slaves von einem anderen Slave besteht darin, dass Sie schlechte Daten klonen, falls Ihr Slave aus irgendeinem Grund nicht synchron mit dem Master ist. Benutzen Sie nicht LOAD DATA FROM MASTER oder LOAD TABLE FROM MASTER! Diese Befehle sind veraltet, langsam und sehr gefährlich. Außerdem funktionieren sie nur mit MyISAM. Machen Sie sich mit der Technik vertraut, für die Sie sich letztendlich entscheiden, und dokumentieren Sie sie, oder schreiben Sie sich ein Skript. Sie werden diesen Vorgang mit hoher Wahrscheinlichkeit mehr als einmal durchführen und müssen dazu in der Lage sein, ihn zu wiederholen, falls etwas schiefgeht. Die empfohlene Replikationskonfiguration Es gibt viele Replikationsparameter, und die meisten von ihnen haben wenigstens eine gewisse Wirkung auf die Datensicherheit und die Performance. Wir erläutern später, welche Regeln Sie wann brechen sollten. In diesem Abschnitt zeigen wir eine empfohlene,»sichere«replikationskonfiguration, die die Gelegenheiten zum Auftreten von Problemen minimiert. Die wichtigste Einstellung für das Führen eines Binärlogs auf dem Master ist sync_binlog: sync_binlog=1 Sie veranlasst MySQL, den Inhalt des Binärlogs bei jedem Bestätigen einer Transaktion auf die Festplatte zu synchronisieren, damit Sie im Falle eines Absturzes keine Log- Events verlieren. Wenn Sie diese Option deaktivieren, hat der Server zwar etwas weniger Arbeit, aber die Binärlog-Einträge könnten nach einem Serverabsturz beschädigt werden oder verlorengehen. Auf einem Slave, der nicht als Master auftreten muss, verursacht diese Option unnötigen Overhead. Sie gilt nur für das Binärlog, nicht für das Relay-Log. Wir empfehlen außerdem die Verwendung von InnoDB, falls Sie beschädigte Tabellen nach einem Absturz nicht tolerieren können. MyISAM ist in Ordnung, falls die Beschädigung der Tabelle keine große Sache ist, MyISAM-Tabellen dagegen gelangen wahrscheinlich in einen inkonsistenten Zustand, wenn ein Slave-Server abstürzt. Es kommt mit großer Sicherheit dazu, dass eine Anweisung unvollständig auf eine oder mehrere Tabel- 384 Kapitel 8: Replikation

18 len angewandt wurde und die Daten auch dann inkonsistent bleiben, nachdem Sie die Tabellen repariert haben. Falls Sie InnoDB benutzen, empfehlen wir Ihnen unbedingt, die folgenden Optionen auf dem Master einzustellen: innodb_flush_logs_at_trx_commit=1 # Uebertraegt alle Log-Schreibvorgaenge innodb_support_xa=1 # Nur MySQL 5.0 und neuere Versionen innodb_safe_binlog # Nur MySQL 4.1, ist in etwa aequivalent # zu innodb_support_xa Das sind die Standardeinstellungen in MySQL 5.0. Auf dem Slave sollten Sie die folgenden Konfigurationsoptionen aktivieren: skip_slave_start read_only Die Option skip_slave_start verhindert, dass der Slave nach einem Absturz automatisch wieder startet, wodurch Sie die Möglichkeit haben, einen Server zu reparieren, falls er Probleme hat. Wenn der Slave nach einem Absturz automatisch startet und in einem inkonsistenten Zustand ist, kann er weitere Schäden anrichten, so dass Sie unter Umständen seine Daten wegwerfen und von vorn beginnen müssen. Selbst wenn Sie alle empfohlenen Optionen aktiviert haben, kann ein Slave nach einem Absturz noch kaputtgehen, weil die Relay-Logs und die Datei master.info nicht absturzsicher sind. Sie werden nicht einmal auf die Festplatte übertragen, und es gibt keine Konfigurationsoption, mit der man dieses Verhalten kontrollieren könnte. (Die Google-Patches, auf die wir später noch kommen, befassen sich mit diesem Problem.) Die Option read_only hält die meisten Benutzer davon ab, nichttemporäre Tabellen zu ändern. Ausgenommen sind der Slave-SQL-Thread und Threads mit der Berechtigung SUPER. Dies ist einer der Gründe dafür, weshalb Sie Ihren normalen Accounts nicht die Berechtigung SUPER geben sollten (mehr zu Berechtigungen erfahren Sie in Kapitel 12). Wenn ein Slave weit hinter seinem Master zurückliegt, dann kann der Slave-Ein-/Ausgabe-Thread viele Relay-Logs schreiben. Der Slave-SQL-Thread entfernt sie, sobald er damit fertig ist, sie abzuspielen (das können Sie mit der Option relay_log_purge ändern). Falls er aber weit hinterher ist, füllt der Ein-/Ausgabe-Thread möglicherweise die Festplatte. Die Lösung für dieses Problem ist die Konfigurationsvariable relay_log_space_ limit. Übersteigt die Gesamtgröße aller Relay-Logs die Größe dieser Variablen, stoppt der Ein-/Ausgabe-Thread und wartet darauf, dass der SQL-Thread etwas mehr Festplattenplatz freigibt. Das klingt zwar alles gut und schön, kann aber insgeheim problematisch sein. Wenn der Slave noch nicht alle Relay-Logs vom Master geholt hat, sind diese Logs vielleicht für immer verloren, falls der Master abstürzt. Es ist sicher keine schlechte Idee, wenn Sie den Slave so viel Platz wie nötig für die Relay-Logs benutzen lassen (es sei denn, Sie haben mit dem Festplattenplatz etwas Besseres vor). Deswegen haben wir die Einstellung relay_log_space_limit nicht in unsere empfohlene Konfiguration aufgenommen. Die Replikation einrichten 385

19 Replikation näher betrachtet Nachdem wir einige der Grundlagen der Replikation erläutert haben, wollen wir sie uns genauer anschauen. Wir untersuchen, wie Replikation wirklich funktioniert, welche Stärken und Schwächen sie mitbringt und welche erweiterten Konfigurationsoptionen es für die Replikation gibt. Anweisungsbasierte Replikation MySQL 5.0 und frühere Versionen unterstützen nur anweisungsbasierte Replikation (auch als logische Replikation bezeichnet). Das ist in der Datenbankwelt ungewöhnlich. Bei der anweisungsbasierten Replikation wird die Abfrage aufgezeichnet, die die Daten auf dem Master geändert hat. Wenn der Slave das Event aus dem Relay-Log liest und es ausführt, führt er die tatsächliche SQL-Abfrage noch einmal aus, die der Master ausgeführt hat. Dieses Vorgehen bringt sowohl Vor- als auch Nachteile mit sich. Der offensichtlichste Vorteil besteht darin, dass es relativ einfach zu implementieren ist. Durch das einfache Aufzeichnen und erneute Abspielen aller Anweisungen, die Daten ändern, bleibt der Slave theoretisch synchron mit dem Master. Ein weiterer Vorteil der anweisungsbasierten Replikation besteht darin, dass die Binärlog-Events in der Regel ausgesprochen kompakt sind. Anweisungsbasierte Replikation benötigt also relativ wenig Bandbreite eine Abfrage, die Gigabytes an Daten aktualisiert, belegt möglicherweise nur einige Dutzend Bytes im Binärlog. Darüber hinaus funktioniert das erwähnte Werkzeug mysqlbinlog mit anweisungsbasiertem Logging am besten. In der Praxis ist die anweisungsbasierte Replikation jedoch nicht ganz so einfach, wie es scheinen mag, weil viele Änderungen auf dem Master noch von anderen Faktoren als nur dem Abfragetext abhängen können. Beispielsweise werden die Anweisungen auf dem Master und dem Slave zu mehr oder weniger unterschiedlichen Zeiten ausgeführt. Daraus folgt, dass das Binärlog-Format von MySQL mehr als nur den Abfragetext enthält; es überträgt auch mehrere Bits mit Metadaten, wie etwa den aktuellen Zeitstempel. Außerdem gibt es Anweisungen, die MySQL nicht korrekt replizieren kann, wie etwa Abfragen mit der Funktion CURRENT_USER( ). Auch gespeicherte Routinen und Trigger werfen bei der anweisungsbasierten Replikation Probleme auf. Ein weiteres Problem bei der anweisungsbasierten Replikation besteht darin, dass die Modifikationen serialisierbar sein müssen. Das erfordert erhebliche Mengen an Spezialcode, Konfigurationseinstellungen und zusätzliche Serverfunktionen, einschließlich der Next-Key-Locks von InnoDB und automatisch inkrementierender Sperren. Nicht alle Storage-Engines funktionieren mit anweisungsbasierter Replikation, obwohl es diejenigen tun, die in der offiziellen MySQL-Serverdistribution bis einschließlich MySQL 5.1 enthalten sind. Im MySQL-Handbuch finden Sie im Kapitel über die Replikation eine vollständige Liste mit den Nachteilen der anweisungsbasierten Replikation. 386 Kapitel 8: Replikation

20 Zeilenbasierte Replikation MySQL 5.1 bietet Unterstützung für zeilenbasierte Replikation, bei der die tatsächlichen Datenänderungen im Binärlog aufgezeichnet werden. Ihre Implementierung ähnelt der anderer Datenbankprodukte. Dieses Vorgehen bringt einige Vor- und Nachteile mit sich. Der größte Vorteil besteht darin, dass MySQL jede Anweisung korrekt replizieren kann; einige Anweisungen werden sogar noch effizienter repliziert. Die wichtigsten Nachteile sind, dass das Binärlog viel größer werden kann und dass nicht so klar ist, welche Anweisungen die Daten aktualisiert haben, so dass sich das Binärlog nicht für eine Prüfung mit mysqlbinlog eignet. Zeilenbasiertes Logging ist nicht abwärtskompatibel. Das Dienstprogramm mysqlbinlog, das mit MySQL 5.1 vertrieben wird, kann Binärlogs lesen, die Events im zeilenbasierten Format aufzeichnen (sie sind nicht vom Menschen lesbar, der MySQL-Server kann sie allerdings interpretieren). mysqlbinlog-versionen aus früheren MySQL-Distributionen dagegen erkennen solche Log-Events nicht und beenden sich mit einer Fehlermeldung, wenn sie sie bemerken. MySQL kann manche Änderungen mithilfe der zeilenbasierten Replikation effizienter replizieren, weil der Slave die Abfragen nicht noch einmal wiedergeben muss, mit denen die Zeilen auf dem Master geändert wurden. Das erneute Abspielen einiger Abfragen kann sehr teuer sein. Hier sehen Sie z.b. eine Abfrage, die Daten aus einer sehr großen Tabelle in einer kleineren Tabelle zusammenfasst: mysql> INSERT INTO summary_table(col1, col2, sum_col3) -> SELECT col1, col2, sum(col3) -> FROM enormous_table -> GROUP BY col1, col2; Stellen Sie sich vor, dass es nur drei eindeutige Kombinationen aus col1 und col2 in der enormous_table-tabelle gibt. Diese Abfrage scannt viele Zeilen in der Quelltabelle, ergibt aber nur drei Zeilen in der Zieltabelle. Durch das Replizieren dieses Events muss der Slave die ganze Arbeit wiederholen, um nur wenige Zeilen zu generieren. Eine zeilenbasierte Replikation ist dagegen auf dem Slave unwahrscheinlich billig und damit viel effizienter. Andererseits lässt sich das folgende Event mit einer anweisungsbasierten Replikation billiger replizieren: mysql> UPDATE enormous_table SET col1 = 0; Die Verwendung der zeilenbasierten Replikation wäre in diesem Fall viel teurer, weil sie jede Zeile ändert: Jede Zeile müsste in das Binärlog geschrieben werden, wodurch dieses außerordentlich anwachsen würde. Sowohl durch das Logging als auch durch die Replikation würde die Last auf dem Master stark ansteigen, und das langsamere Logging würde in der Folge die Nebenläufigkeit herabsetzen. Replikation näher betrachtet 387