Inhalt - bücher.de · 2020-01-30 · |V Inhalt Vorwort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

| V

Inhalt

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

1 Die MySQL-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Die logische Architektur von MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Nebenläufigkeitskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Multi-Version Concurrency Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Die Storage-Engines von MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Engpässe finden: Benchmarking und Profiling. . . . . . . . . . . . . . . . . . . . . . . . . . . 35Wozu Benchmarks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Benchmarking-Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Benchmarking-Taktiken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Benchmarking-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Benchmarking-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Profiling des Betriebssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3 Schema-Optimierung und Indizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Optimale Datentypen auswählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Grundlagen der Indizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Indizierungsstrategien für High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Indizierung – eine Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Index- und Tabellenpflege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Normalisierung und Denormalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149ALTER TABLE beschleunigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Hinweise zu Storage-Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

VI | Inhalt

4 Optimierung der Abfrageleistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Grundlagen langsamer Abfragen: Datenzugriff optimieren . . . . . . . . . . . . . . . . . 163Methoden zum Umstrukturieren von Abfragen. . . . . . . . . . . . . . . . . . . . . . . . . . 169Grundlagen der Abfrageverarbeitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Grenzen des MySQL-Abfrageoptimierers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Bestimmte Arten von Abfragen optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Hinweise für den Abfrageoptimierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Benutzerdefinierte Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

5 Erweiterte MySQL-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Der MySQL-Abfrage-Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Code in MySQL speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Cursor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Vorbereitete Anweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Benutzerdefinierte Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Zeichensätze und Sortierreihenfolgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Volltextsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Fremdschlüsselbeschränkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Merge-Tabellen und Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Verteilte (XA-) Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

6 Die Servereinstellungen optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Grundlagen der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Allgemeines Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Das Ein-/Ausgabeverhalten von MySQL anpassen . . . . . . . . . . . . . . . . . . . . . . . 304Die MySQL-Nebenläufigkeit anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Lastbasierte Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Verbindungsbezogene Werte anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

7 Betriebssystem- und Hardwareoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Was beschränkt die Leistung von MySQL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Wie Sie CPUs für MySQL auswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Speicher- und Festplattenressourcen abwägen. . . . . . . . . . . . . . . . . . . . . . . . . . . 336Hardware für einen Slave wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345RAID-Leistungsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Storage Area Networks und Network-Attached Storage . . . . . . . . . . . . . . . . . . . 354Mehrere Festplatten-Volumes benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355Die Netzwerkkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Inhalt | VII

Ein Betriebssystem wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Ein Dateisystem wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Threading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Der Betriebssystemstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

8 Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Replikation im Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Die Replikation einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Replikation näher betrachtet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Replikationstopologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Replikation und Kapazitätsplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Replikationsadministration und -wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410Replikationsprobleme und Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Wie schnell ist die Replikation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Die Zukunft der MySQL-Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

9 Skalierung und Hochverfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446MySQL skalieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448Lastausgleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Hochverfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

10 Optimierung auf Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498Überblick über die Anwendungsleistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498Webserverprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505MySQL erweitern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512Alternativen zu MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

11 Backup und Wiederherstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516Überlegungen und Kompromisse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521Binärlogs organisieren und sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531Daten in einem Backup sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534Wiederherstellung aus einem Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546Backup- und Wiederherstellungsgeschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . 558Backup-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558Backups mit Skripten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

VIII | Inhalt

12 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570Account-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571Betriebssystemsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592Netzwerksicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593Datenverschlüsselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601MySQL in einer chroot-Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

13 Der MySQL-Serverstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608Systemvariablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608SHOW STATUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609SHOW INNODB STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616SHOW PROCESSLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631SHOW MUTEX STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Status der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633INFORMATION_SCHEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634

14 Werkzeuge für High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636Schnittstellenwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636Überwachungswerkzeuge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638Analysewerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649MySQL-Dienstprogramme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652Weitere Informationsquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

A Große Dateien übertragen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

B EXPLAIN benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661

C Sphinx mit MySQL benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

D Sperren debuggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R

eplikation und Lastverteilung", ISB

N 978-3-89721-889-5

http://ww

w.oreilly.de/catalog/hpm

ysql2ger/ D

ieser Auszug unterliegt dem

Urheberrecht. ©

O’R

eilly Verlag 2009

| 373

KAPITEL 8

Replikation

Die in MySQL integrierte Fähigkeit zur Replikation ist die Grundlage für den Aufbaugroßer, leistungsstarker Anwendungen auf MySQL-Basis. Die Replikation erlaubt esIhnen, einen oder mehrere Server als Slaves oder Repliken eines anderen Servers zu konfi-gurieren. Das ist nicht nur für High-Performance-Anwendungen sinnvoll, sondern auchfür viele andere Aufgaben, wie etwa das gemeinsame Benutzen von Daten mit einemexternen Büro, das Vorhalten eines »Hot Spare« oder das Betreiben eines Servers miteiner 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 Servereinstel-lungen, die Gestaltung aufwendigerer Replikationskonfigurationen sowie die Verwaltungund Optimierung der replizierten Server an. Obwohl wir uns in diesem Buch im Allge-meinen vor allem auf die Performance konzentrieren, kümmern wir uns in Bezug auf dieReplikation auch um die Korrektheit und die Zuverlässigkeit. Außerdem schauen wir unseinige künftige Änderungen und Verbesserungen bei der MySQL-Replikation an, wieetwa interessante Patches, die von Google geschaffen wurden.

Replikation im ÜberblickDas Grundproblem, das mithilfe der Replikation gelöst wird, ist Folgendes: Wie hältman die Daten eines Servers synchron zu den Daten eines anderen? Viele Slaves könnensich mit einem einzigen Master verbinden, und ein Slave kann wiederum als Master auf-treten. Sie können Master und Slaves in vielen unterschiedlichen Topologien anordnen.Sie können den gesamten Server oder nur bestimmte Datenbanken replizieren oder sogarwählen, welche Tabellen Sie replizieren wollen.

MySQL unterstützt zwei Arten der Replikation: anweisungsbasierte Replikation und zei-lenbasierte Replikation. Die anweisungsbasierte (oder »logische«) Replikation gibt es seitMySQL 3.23. Sie wird von den meisten Leuten heutzutage in der Praxis eingesetzt. Zeilen-basierte Replikation ist dagegen neu in MySQL 5.1. Bei beiden Arten werden Änderungen

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

374 | Kapitel 8: Replikation

im Binärlog des Masters1 aufgezeichnet, und das Log wird dann auf dem Slave wieder abge-spielt. Beide sind asynchron – d.h., es gibt keine Garantie, dass die Kopie der Daten auf demSlave in jedem Moment auf dem neuesten Stand ist.2 Es gibt keine Gewähr, wie groß dieLatenz auf dem Slave sein könnte. Große Abfragen könnten dafür sorgen, dass der SlaveSekunden, Minuten oder sogar Stunden hinter den Master zurückfällt.

Die Replikation ist in MySQL meist abwärtskompatibel. Das heißt, dass ein neuerer Ser-ver normalerweise ohne Probleme der Slave eines älteren Servers sein kann. Ältere Ver-sionen des Servers dagegen sind oft nicht in der Lage, als Slaves der neueren Versionen zudienen: Sie verstehen möglicherweise neue Funktionen oder die SQL-Syntax nicht, dieneuere Server benutzen, außerdem können sich die bei der Replikation verwendetenDateiformate unterscheiden. So können Sie z.B. nicht von einem MySQL-5.0-Master zueinem MySQL-4.0-Slave replizieren. Testen Sie auf jeden Fall Ihre Replikationseinstel-lung, bevor Sie von einer Hauptversion auf eine andere wechseln, also etwa von 4.1 auf5.0 oder von 5.0 auf 5.1.

Die Replikation erhöht im Allgemeinen den Aufwand auf dem Master nicht sehr. Aufdem Master muss das binäre Logging aktiviert sein, das recht aufwendig sein kann, aller-dings brauchen Sie das sowieso für ordentliche Backups. Abgesehen vom Binär-Loggingbringt beim normalen Betrieb auch jeder angeschlossene Slave eine gewisse zusätzlicheLast auf dem Master mit sich (hauptsächlich Netzwerk-Ein-/Ausgaben).

Replikation eignet sich relativ gut zum Skalieren von Leseoperationen, die Sie an einenSlave umleiten können, ist allerdings nur dann eine gute Methode zum Skalieren vonSchreibvorgängen, wenn Sie sie richtig gestaltet haben. Beim Anschließen vieler Slaves aneinen Master werden die Schreiboperationen lediglich viele Male, nämlich einmal aufjedem Slave, ausgeführt. Das gesamte System ist auf die Anzahl der Schreiboperationenbeschränkt, die der schwächste Teil ausführen kann.

Auch wenn man mehr als nur ein paar Slaves hat, ist eine Replikation eine Verschwen-dung, weil dabei im Prinzip eine Menge Daten unnötigerweise dupliziert werden. Sobesitzt z.B. ein einziger Master mit 10 Slaves 11 Kopien derselben Daten und dupliziertden 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 Hard-ware, kommt aber überraschend oft vor. Wir werden in diesem Kapitel Methoden vor-stellen, 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 Informa-tionen.

2 Mehr dazu finden Sie in »Synchrone MySQL-Replikation« auf Seite 492.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikation im Überblick | 375

Probleme, die durch die Replikation gelöst werdenHier sind einige der gebräuchlichsten Anwendungsfälle für die Replikation:

DatenverteilungDie Replikation von MySQL ist normalerweise nicht sehr bandbreitenintensiv,3 undSie können sie nach Belieben stoppen und starten. Sie eignet sich daher, um eineKopie Ihrer Daten an einem räumlich entfernten Ort anzulegen, wie etwa in einemanderen Rechenzentrum. Der entfernte Slave kann sogar über eine Verbindung agie-ren, die nur sporadisch existiert (ob absichtlich oder nicht). Falls Ihre Slaves aller-dings nur eine geringe Verzögerung bei der Replikation haben sollen, brauchen Sieeine stabile Verbindung mit geringer Latenz.

LastausgleichDie MySQL-Replikation kann Ihnen dabei helfen, Leseabfragen über mehrere Ser-ver zu verteilen, was auch gut für leseintensive Anwendungen funktioniert. Mit eini-gen einfachen Codeänderungen erreichen Sie sogar einen einfachen Lastausgleich.In kleinem Maßstab benutzen Sie vereinfachte Ansätze, wie fest kodierte Hostna-men oder Lastverteilung per DNS (bei dem ein Hostname auf mehrere IP-Adressenzeigt). Sie können auch raffiniertere Ansätze verfolgen. Normale Lösungen zumLastausgleich, wie etwa Produkte zum Lastausgleich in Netzwerken, können dieLast zwischen MySQL-Servern verteilen. Auch das LVS-Projekt (Linux Virtual Ser-ver) funktioniert ganz gut. Wir befassen uns in Kapitel 9 mit Lastausgleich.

BackupsReplikation bietet eine wertvolle Technik zum Unterstützen von Backups. Aller-dings stellt ein Slave weder ein Backup noch einen Ersatz für Backups dar.

Hochverfügbarkeit und FailoverMithilfe der Replikation können Sie vermeiden, dass MySQL der einzige Schwach-punkt in Ihrer Anwendung ist. Mit einem guten Failover-System (System zur Aus-fallsicherung) mit replizierten Slaves können Sie die Ausfallzeiten drastischverringern. Failover behandeln wir ebenfalls in Kapitel 9.

Testen von MySQL-UpgradesEs ist üblich, einen Slave-Server mit einer aufgerüsteten MySQL-Version auszustat-ten und mit seiner Hilfe zu überprüfen, ob die Abfragen erwartungsgemäß funk-tionieren, bevor man alle anderen Server umrüstet.

Wie die Replikation funktioniertBevor wir uns detailliert damit befassen, wie man die Replikation einrichtet, wollen wiruns anschauen, wie MySQL tatsächlich Daten repliziert. Global gesehen, handelt es sichbei 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, vielmehr Bandbreite benutzen könnte als die traditionellere, anweisungsbasierte Replikation.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


1. Der Master zeichnet die Änderungen an seinen Daten in seinem Binärlog auf. (DieseAufzeichnungen 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-1verdeutlicht die Replikation im Detail.

Der erste Teil dieses Vorgangs ist das Schreiben in das Binärlog auf dem Master (wir zei-gen Ihnen später, wie Sie das einrichten). Direkt, bevor eine Transaktion, die Daten aufdem 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 Anweisungenin den Transaktionen während der Ausführung verschachtelt wurden. Nachdem dieEvents 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 Festplattekopieren, 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 Clientver-bindung zum Master und startet dann einen speziellen Binlog-Dump-Prozess (es gibtdazu keinen SQL-Befehl). Der Binlog-Dump-Prozess liest die Events aus dem Binärlogdes Masters. Er fragt nicht nach Events. Wenn er mit dem Master fertig ist, wird erzurückgestellt und wartet auf das Signal des Masters, das besagt, dass es wieder neueEvents gibt. Der Ein-/Ausgabe-Thread schreibt die Events in das Relay-Log des Slaves.

Abbildung 8-1: Wie die MySQL-Replikation funktioniert

Master Slave

Daten-änderungen

Lesen

Ein/Ausgabe-Thread

SQL-Thread

Lesen

Binärlog Relay- Log

Schreiben Wieder-abspielen

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Die Replikation einrichten | 377

Vor MySQL 4.0 funktionierte die Replikation in vielen Aspekten ganzanders. Zum Beispiel verwendete die erste Replikationsfunktionalität vonMySQL kein Relay-Log, so dass bei der Replikation nur zwei Threads zumEinsatz kamen und nicht drei. Die meisten Leute verwenden inzwischenaber neuere MySQL-Versionen, wir werden uns daher in diesem Kapitelnicht über die sehr alten Versionen von MySQL auslassen.

Der SQL-Slave-Thread erledigt den letzten Teil des Vorgangs. Dieser Thread liest dieEvents aus dem Relay-Log und spielt sie wieder ab, wobei er die Daten des Slaves aktuali-siert, damit sie schließlich denen des Masters entsprechen. Solange dieser Thread mit demEin-/Ausgabe-Thread Schritt hält, bleibt das Relay-Log normalerweise im Cache desBetriebssystems, 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 übernommenwerden. 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ßer-dem einen Thread auf dem Master: Wie jede Verbindung zu einem MySQL-Server startetdie Verbindung, die der Slave zum Master öffnet, einen Thread auf dem Master.

Diese Replikationsarchitektur koppelt die Vorgänge des Holens und des Abspielens vonEvents auf dem Slave voneinander ab, wodurch sie asynchron ausgeführt werden kön-nen. 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 wich-tigste lautet, dass die Replikation auf dem Slave serialisiert wird. Das bedeutet, dass Aktu-alisierungen, die auf dem Master möglicherweise parallel (in unterschiedlichen Threads)ausgeführt wurden, auf dem Slave nicht parallelisiert werden können. Wie wir spätersehen werden, ist das für viele Lasten ein möglicher Performance-Engpass.

Die Replikation einrichtenDas Einrichten der Replikation ist in MySQL ein relativ einfacher Vorgang, es gibt für diegrundlegenden Schritte allerdings viele Variationen, die vom jeweiligen Szenario abhän-gen. Das einfachste Szenario sind frisch installierte Master und Slaves. Auf einer höherenEbene 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 derTat zutrifft, wenn Sie den Master und den Slave gerade installiert haben und sie die glei-chen Daten aufweisen (die vorgegebene mysql-Datenbank). Wir zeigen Ihnen, wie Sie dieeinzelnen Schritte ausführen. Dabei nehmen wir an, dass Ihre Server server1 (IP-Adresse192.168.0.1) und server2 (IP-Adresse 192.168.0.2) heißen. Anschließend erläutern wir,wie man einen Slave von einem Server aus initialisiert, der bereits läuft, und untersuchendie empfohlene Replikationskonfiguration.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Replikations-Accounts anlegenMySQL verfügt über einige besondere Berechtigungen, die den Replikationsprozessendie 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 einenBenutzer-Account auf dem Master anlegen und diesem die richtigen Berechtigungen ver-leihen, damit der Ein-/Ausgabe-Thread sich als dieser Benutzer anmelden und das Binär-log des Masters lesen kann. Wir erzeugen hier einen Benutzer-Account namens repl:

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*-> TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';

Diesen Account legen wir sowohl auf dem Master als auch auf dem Slave an. BeachtenSie, dass wir den Benutzer auf das lokale Netzwerk beschränkt haben, weil der Replika-tions-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 bei-den Servern ist nicht erforderlich. Weshalb also gewähren wir dieseBerechtigungen auf beiden Servern? Das hat zwei Gründe:

• Der Account, den Sie benutzen, um die Replikation zu überwachenund zu verwalten, braucht die Berechtigung REPLICATION SLAVE. Esist 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 denSlave vom Master klonen, wird der Slave korrekterweise so eingerich-tet, dass er als Master agiert, falls Sie irgendwann einmal die Rollenvon Master und Slave vertauschen wollen.

Master und Slave konfigurierenDer nächste Schritt besteht darin, einige Einstellungen auf dem Master zu aktivieren, derbei uns den Namen server1 tragen soll. Sie müssen das Binär-Logging einschalten undeine 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-binserver_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 anstellevon 1 zu nehmen, weil 1 die Vorgabe ist, die ein Server typischerweise wählt, wenn keinWert angegeben wurde. (Das ist versionsabhängig; manche MySQL-Versionen funktionie-ren dann einfach nicht.) Die 1 kann deshalb leicht zu Verwirrung und Konflikten mit Ser-vern 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 ändertund eindeutig ist (d.h., dass die Server nur zu einem Subnetz gehören).

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Wenn das Binär-Logging noch nicht in der Konfigurationsdatei des Masters angegebenwar, müssen Sie MySQL neu starten. Um sicherzustellen, dass die Binärlog-Datei aufdem Master angelegt wurde, führen Sie SHOW MASTER STATUS aus und überprüfen, ob Sieeine Ausgabe erhalten, die der folgenden Ausgabe ähnelt. (MySQL hängt einige Ziffernan den Dateinamen an, Sie sehen daher bei der Datei nicht exakt den Namen, den Sieangegeben haben.)

mysql> SHOW MASTER STATUS;+------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000001 | 98 | | |+------------------+----------+--------------+------------------+1 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-binserver_id = 2relay_log = mysql-relay-binlog_slave_updates = 1read_only = 1

Technisch gesehen, sind einige dieser Optionen nicht erforderlich, und für einige gebenwir einfach nur explizit die Vorgabewerte an. Tatsächlich wird auf einem Slave nur derParameter 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 Hostnamendes 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 einfacheSlave-zu-Master-Umwandlung zu erlauben. Das heißt, nicht nur der Replikationsbenut-zer 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 sehenwerden, haben wir gute Gründe dafür, diese optionalen Einstellungen auf jedem Slavehinzuzufügen.

Manche Leute aktivieren nur das Binärlog und nicht log_slave_updates, so dass sie esmerken, ob irgendetwas, wie etwa eine fehlkonfigurierte Anwendung, Daten auf demSlave modifiziert. Falls möglich sollten Sie die Konfigurationseinstellung read_onlybenutzen, die verhindert, dass andere als die besonders berechtigten Threads Datenändern. (Gewähren Sie Ihren Benutzern nicht mehr Berechtigungen als nötig!) Allerdingsist read_only oft nicht praktisch, vor allem nicht für Anwendungen, die in der Lage seinmüssen, Tabellen auf Slaves zu erzeugen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Setzen Sie die Replikationskonfigurationsoptionen, wie etwa master_hostund master_port, nicht in die my.cnf-Datei des Slaves. Diese alte Methodeder Konfiguration eines Slaves wird nicht mehr empfohlen. Sie kann Prob-leme verursachen und bringt keine Vorteile mit sich.

Den Slave startenDer nächste Schritt besteht darin, dass man dem Slave mitteilt, wie er sich mit dem Serververbinden 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 ent-sprechenden my.cnf-Einstellungen komplett. Sie erlaubt es Ihnen auch, den Slave inZukunft auf einen anderen Master zu richten, ohne den Server zu stoppen. Hier ist dieAnweisung, 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.000001',-> MASTER_LOG_POS=0;

Der Parameter MASTER_LOG_POS ist auf 0 gesetzt, weil dies der Anfang des Logs ist. Nach-dem Sie dies ausgeführt haben, sollten Sie anhand der Ausgabe von SHOW SLAVE STATUSfeststellen können, dass die Einstellungen des Slaves korrekt sind:

mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************

Slave_IO_State:Master_Host: server1Master_User: replMaster_Port: 3306

Connect_Retry: 60Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 4Relay_Log_File: mysql-relay-bin.000001Relay_Log_Pos: 4

Relay_Master_Log_File: mysql-bin.000001Slave_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 dieSlave-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; siebedeutet nur »am Anfang der Log-Datei«. MySQL weiß, dass das erste Event tatsächlichan 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 Posi-tion 98. Master und Slave machen das miteinander aus, sobald der Slave sich mit dem Master verbunden hat,was noch nicht geschehen ist.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Um die Replikation zu starten, führen Sie folgenden Befehl aus:

mysql> START SLAVE;

Dieser Befehl erzeugt keine Fehlermeldungen oder Ausgaben. Untersuchen Sie jetzt nocheinmal SHOW SLAVE STATUS:

mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send eventMaster_Host: server1Master_User: replMaster_Port: 3306

Connect_Retry: 60Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 164Relay_Log_File: mysql-relay-bin.000001Relay_Log_Pos: 164

Relay_Master_Log_File: mysql-bin.000001Slave_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 unddass Seconds_Behind_Master nicht mehr NULL ist (wir untersuchen später, wasSeconds_Behind_Master bedeutet). Der Ein-/Ausgabe-Thread wartet auf ein Event vomMaster, was bedeutet, dass er alle Binärlogs des Masters geholt hat. Die Log-Positionenhaben sich erhöht, es wurden also einige Events geholt und ausgeführt (Ihre Ergebnissewerden anders aussehen). Wenn Sie auf dem Master eine Änderung vornehmen, solltenSie sehen, dass sich die verschiedenen Datei- und Positionseinstellungen auf dem Slaveerhöhen. Sie sollten auch Änderungen an den Datenbanken auf dem Slave feststellenkönnen!

Sie erkennen auch die Replikations-Threads in den jeweiligen Prozesslisten auf dem Mas-ter und dem Slave. Auf dem Master sollten Sie eine Verbindung sehen, die vom Ein-/Aus-gabe-Thread des Slaves erzeugt wurde:

mysql> SHOW PROCESSLIST\G*************************** 1. row ***************************

Id: 55User: replHost: slave1.webcluster_1:54813

db: NULLCommand: Binlog Dump

Time: 610237State: Has sent all binlog to slave; waiting for binlog to be updatedInfo: NULL

Auf dem Slave müssen Sie zwei Threads sehen. Einer ist der Ein-/Ausgabe-Thread, derandere ist der SQL-Thread:

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


mysql> SHOW PROCESSLIST\G*************************** 1. row ***************************

Id: 1User: system userHost:

db: NULLCommand: Connect

Time: 611116State: Waiting for master to send eventInfo: NULL

*************************** 2. row ***************************Id: 2

User: system userHost:

db: NULLCommand: Connect

Time: 33State: Has read all relay log; waiting for the slave I/O thread to update itInfo: NULL

Die gezeigte Beispielausgabe stammt von Servern, die schon lange laufen, weshalb dieTime-Spalten der Ein-/Ausgabe-Threads auf dem Master und dem Slave große Werte zei-gen. Der SQL-Thread auf dem Slave war 33 Sekunden lang untätig, was bedeutet, dass 33Sekunden lang keine Events eingespielt wurden.

Diese Prozesse laufen immer unter dem Benutzer-Account »system user«, die anderenSpalten zeigen bei Ihnen dagegen andere Werte. Wenn z.B. der SQL-Thread ein Eventauf 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 (http://sourceforge.net/projects/mysql-sandbox/) eine »Spielinstallation« aus einer frisch herun-tergeladenen MySQL-tar-Datei starten. Es sind nur einige Tastendrückeund etwa 15 Sekunden nötig, um einen Master und zwei Slaves zum Lau-fen zu bringen:

$ ./set_replication.pl ~/mysql-5.0.45-linux-x86_64-glibc23.tar.gz

Einen Slave von einem anderen Server aus initialisierenDie gerade gezeigten Hinweise zur Einrichtung gingen davon aus, dass Sie Master undSlave nach einer Neuinstallation mit den vorgegebenen Anfangsdaten gestartet haben, sodass Sie implizit die gleichen Daten auf beiden Servern hatten und die Binärlog-Koordi-naten des Masters kannten. Das ist nicht unbedingt der typische Fall. Normalerweisewerden Sie bereits einen Master am Laufen haben und wollen einen neu installiertenSlave mit diesem synchronieren, obwohl dieser nicht die Daten des Masters besitzt.

Es gibt verschiedene Möglichkeiten, einen Slave von einem anderen Server aus zu initiali-sieren oder zu »klonen«. Dazu gehört das Kopieren der Daten vom Master, das Kloneneines Slaves von einem anderen Slave aus und das Starten eines Slaves aus einem aktuellenBackup. Sie brauchen drei Dinge, um einen Slave mit einem Master zu synchronisieren:

http://sourceforge.net/projects/mysql-sandbox/


Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


• Einen Schnappschuss der Daten des Masters zu einem bestimmten Zeitpunkt.

• Die aktuelle Log-Datei des Masters und den Byte-Offset innerhalb dieses Logs zudem exakten Zeitpunkt, zu dem Sie den Schnappschuss erzeugt haben. Wir bezeich-nen diese beiden Werte als Log-Datei-Koordinaten, weil sie zusammen eine Binär-log-Position kennzeichnen. Sie können die Log-Datei-Koordinaten des Masters mitdem 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 KopieEine der einfachsten Methoden, um einen Slave zu starten, besteht darin, den poten-ziellen Master herunterzufahren und seine Dateien auf den Slave zu kopieren (inAnhang A erfahren Sie, wie Sie Dateien effizient kopieren). Sie können dann denMaster wieder starten, der dann ein neues Binärlog beginnt, und CHANGE MASTER TOeinsetzen, um den Slave am Anfang dieses Binärlogs zu starten. Der Nachteil dieserTechnik ist offensichtlich: Sie müssen den Master herunterfahren, während Sie dieKopie anlegen.

Mit einer warmen KopieWenn Sie nur MyISAM-Tabellen benutzen, können Sie die Dateien mit mysqlhot-copy kopieren, während der Server läuft. Näheres erfahren Sie in Kapitel 11.

Mittels mysqldumpFalls Sie nur InnoDB-Tabellen verwenden, können Sie den folgenden Befehl verwen-den, um alles vom Master zu speichern, es in den Slave zu laden und die Koordina-ten 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 sieam Anfang der Transaktion vorlagen. Diese Option kann auch bei anderen transak-tionsfähigen Storage-Engines funktionieren, wir haben sie aber nicht getestet. FallsSie keine transaktionsfähigen Tabellen verwenden, können Sie die Option --lock-all-tables einsetzen, um einen konsistenten Dump aller Tabellen zu bekommen.

Mit einem LVM-Schnappschuss oder einem BackupWenn Sie die entsprechenden Binärlog-Koordinaten kennen, können Sie einenLVM-Schnappschuss vom Master oder einem Backup benutzen, um den Slave zuinitialisieren (falls Sie ein Backup verwenden, dann verlangt diese Methode, dass Siealle Binärlogs des Masters seit dem Zeitpunkt des Backups aufbewahrt haben). Stel-len Sie einfach das Backup oder den Schnappschuss auf dem Slave wieder her, undbenutzen Sie dann die passenden Binärlog-Koordinaten in CHANGE MASTER TO. Mehrdazu erfahren Sie in Kapitel 11.

InnoDB Hot Backup, das ebenfalls in Kapitel 11 behandelt wird, ist eine guteMethode, um einen Slave zu initialisieren, falls Sie nur InnoDB-Tabellen benutzen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Von einem anderen SlaveMit einer der erwähnten Schnappschuss- oder Klontechniken können Sie einenSlave aus einem anderen klonen. Falls Sie allerdings mysqldump verwenden, funktio-niert die Option --master-data nicht.

Anstatt SHOW MASTER STATUS zu benutzen, um die Binärlog-Koordinaten des Masterszu 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 Schnappschusserzeugt haben.

Der größte Nachteil beim Klonen eines Slaves von einem anderen Slave bestehtdarin, dass Sie schlechte Daten klonen, falls Ihr Slave aus irgendeinem Grund nichtsynchron 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 funk-tionieren sie nur mit MyISAM.

Machen Sie sich mit der Technik vertraut, für die Sie sich letztendlich entscheiden, unddokumentieren Sie sie, oder schreiben Sie sich ein Skript. Sie werden diesen Vorgang mithoher Wahrscheinlichkeit mehr als einmal durchführen und müssen dazu in der Lagesein, ihn zu wiederholen, falls etwas schiefgeht.

Die empfohlene ReplikationskonfigurationEs gibt viele Replikationsparameter, und die meisten von ihnen haben wenigstens einegewisse Wirkung auf die Datensicherheit und die Performance. Wir erläutern später,welche Regeln Sie wann brechen sollten. In diesem Abschnitt zeigen wir eine empfoh-lene, »sichere« Replikationskonfiguration, die die Gelegenheiten zum Auftreten von Pro-blemen 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 Transaktionauf die Festplatte zu synchronisieren, damit Sie im Falle eines Absturzes keine Log-Events verlieren. Wenn Sie diese Option deaktivieren, hat der Server zwar etwas wenigerArbeit, aber die Binärlog-Einträge könnten nach einem Serverabsturz beschädigt werdenoder verlorengehen. Auf einem Slave, der nicht als Master auftreten muss, verursachtdiese 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 Tabellennach einem Absturz nicht tolerieren können. MyISAM ist in Ordnung, falls die Beschädi-gung der Tabelle keine große Sache ist, MyISAM-Tabellen dagegen gelangen wahrschein-lich in einen inkonsistenten Zustand, wenn ein Slave-Server abstürzt. Es kommt mitgroßer Sicherheit dazu, dass eine Anweisung unvollständig auf eine oder mehrere Tabel-

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


len angewandt wurde und die Daten auch dann inkonsistent bleiben, nachdem Sie dieTabellen repariert haben.

Falls Sie InnoDB benutzen, empfehlen wir Ihnen unbedingt, die folgenden Optionen aufdem Master einzustellen:

innodb_flush_logs_at_trx_commit=1 # Uebertraegt alle Log-Schreibvorgaengeinnodb_support_xa=1 # Nur MySQL 5.0 und neuere Versioneninnodb_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 folgen-den Konfigurationsoptionen aktivieren:

skip_slave_startread_only

Die Option skip_slave_start verhindert, dass der Slave nach einem Absturz automatischwieder startet, wodurch Sie die Möglichkeit haben, einen Server zu reparieren, falls erProbleme hat. Wenn der Slave nach einem Absturz automatisch startet und in eineminkonsistenten Zustand ist, kann er weitere Schäden anrichten, so dass Sie unter Umstän-den seine Daten wegwerfen und von vorn beginnen müssen. Selbst wenn Sie alle empfoh-lenen 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 nichteinmal auf die Festplatte übertragen, und es gibt keine Konfigurationsoption, mit derman dieses Verhalten kontrollieren könnte. (Die Google-Patches, auf die wir später nochkommen, 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 BerechtigungSUPER. Dies ist einer der Gründe dafür, weshalb Sie Ihren normalen Accounts nicht dieBerechtigung 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-/Aus-gabe-Thread viele Relay-Logs schreiben. Der Slave-SQL-Thread entfernt sie, sobald erdamit 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 Fest-platte. 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, stopptder Ein-/Ausgabe-Thread und wartet darauf, dass der SQL-Thread etwas mehr Festplat-tenplatz freigibt.

Das klingt zwar alles gut und schön, kann aber insgeheim problematisch sein. Wenn derSlave noch nicht alle Relay-Logs vom Master geholt hat, sind diese Logs vielleicht fürimmer verloren, falls der Master abstürzt. Es ist sicher keine schlechte Idee, wenn Sie denSlave so viel Platz wie nötig für die Relay-Logs benutzen lassen (es sei denn, Sie haben mitdem Festplattenplatz etwas Besseres vor). Deswegen haben wir die Einstellungrelay_log_space_limit nicht in unsere empfohlene Konfiguration aufgenommen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Replikation näher betrachtetNachdem wir einige der Grundlagen der Replikation erläutert haben, wollen wir sie unsgenauer anschauen. Wir untersuchen, wie Replikation wirklich funktioniert, welche Stär-ken und Schwächen sie mitbringt und welche erweiterten Konfigurationsoptionen es fürdie Replikation gibt.

Anweisungsbasierte ReplikationMySQL 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 Datenauf dem Master geändert hat. Wenn der Slave das Event aus dem Relay-Log liest und esausführt, führt er die tatsächliche SQL-Abfrage noch einmal aus, die der Master ausge-fü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 deranweisungsbasierten Replikation besteht darin, dass die Binärlog-Events in der Regelausgesprochen kompakt sind. Anweisungsbasierte Replikation benötigt also relativwenig Bandbreite – eine Abfrage, die Gigabytes an Daten aktualisiert, belegt möglicher-weise nur einige Dutzend Bytes im Binärlog. Darüber hinaus funktioniert das erwähnteWerkzeug mysqlbinlog mit anweisungsbasiertem Logging am besten.

In der Praxis ist die anweisungsbasierte Replikation jedoch nicht ganz so einfach, wie esscheinen mag, weil viele Änderungen auf dem Master noch von anderen Faktoren als nurdem Abfragetext abhängen können. Beispielsweise werden die Anweisungen auf demMaster und dem Slave zu mehr oder weniger unterschiedlichen Zeiten ausgeführt. Dar-aus 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ßer-dem gibt es Anweisungen, die MySQL nicht korrekt replizieren kann, wie etwa Abfragenmit der Funktion CURRENT_USER( ). Auch gespeicherte Routinen und Trigger werfen beider anweisungsbasierten Replikation Probleme auf.

Ein weiteres Problem bei der anweisungsbasierten Replikation besteht darin, dass dieModifikationen serialisierbar sein müssen. Das erfordert erhebliche Mengen an Spezial-code, Konfigurationseinstellungen und zusätzliche Serverfunktionen, einschließlich derNext-Key-Locks von InnoDB und automatisch inkrementierender Sperren. Nicht alleStorage-Engines funktionieren mit anweisungsbasierter Replikation, obwohl es diejeni-gen tun, die in der offiziellen MySQL-Serverdistribution bis einschließlich MySQL 5.1enthalten sind.

Im MySQL-Handbuch finden Sie im Kapitel über die Replikation eine vollständige Listemit den Nachteilen der anweisungsbasierten Replikation.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikation näher betrachtet | 387

Zeilenbasierte ReplikationMySQL 5.1 bietet Unterstützung für zeilenbasierte Replikation, bei der die tatsächlichenDatenänderungen im Binärlog aufgezeichnet werden. Ihre Implementierung ähnelt deranderer 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 Nachteilesind, dass das Binärlog viel größer werden kann und dass nicht so klar ist, welche Anwei-sungen die Daten aktualisiert haben, so dass sich das Binärlog nicht für eine Prüfung mitmysqlbinlog eignet.

Zeilenbasiertes Logging ist nicht abwärtskompatibel. Das Dienstpro-gramm mysqlbinlog, das mit MySQL 5.1 vertrieben wird, kann Binärlogslesen, die Events im zeilenbasierten Format aufzeichnen (sie sind nichtvom Menschen lesbar, der MySQL-Server kann sie allerdings interpretie-ren). mysqlbinlog-Versionen aus früheren MySQL-Distributionen dagegenerkennen solche Log-Events nicht und beenden sich mit einer Fehlermel-dung, wenn sie sie bemerken.

MySQL kann manche Änderungen mithilfe der zeilenbasierten Replikation effizienterreplizieren, weil der Slave die Abfragen nicht noch einmal wiedergeben muss, mit denendie Zeilen auf dem Master geändert wurden. Das erneute Abspielen einiger Abfragenkann sehr teuer sein. Hier sehen Sie z.B. eine Abfrage, die Daten aus einer sehr großenTabelle 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 derenormous_table-Tabelle gibt. Diese Abfrage scannt viele Zeilen in der Quelltabelle, ergibtaber nur drei Zeilen in der Zieltabelle. Durch das Replizieren dieses Events muss derSlave die ganze Arbeit wiederholen, um nur wenige Zeilen zu generieren. Eine zeilenba-sierte Replikation ist dagegen auf dem Slave unwahrscheinlich billig und damit viel effizi-enter.

Andererseits lässt sich das folgende Event mit einer anweisungsbasierten Replikation bil-liger replizieren:

mysql> UPDATE enormous_table SET col1 = 0;

Die Verwendung der zeilenbasierten Replikation wäre in diesem Fall viel teurer, weil siejede Zeile ändert: Jede Zeile müsste in das Binärlog geschrieben werden, wodurch diesesaußerordentlich anwachsen würde. Sowohl durch das Logging als auch durch die Repli-kation würde die Last auf dem Master stark ansteigen, und das langsamere Loggingwürde in der Folge die Nebenläufigkeit herabsetzen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Da kein Format für alle Situationen perfekt geeignet ist, wechselt MySQL 5.1 dynamischzwischen anwendungsbasierter und zeilenbasierter Replikation. Standardmäßig verwen-det es die anwendungsbasierte Replikation. Wenn es allerdings ein Event bemerkt, dasmit einer Anweisung nicht korrekt repliziert werden kann, geht es zur zeilenbasiertenReplikation über. Sie können das Format bei Bedarf auch steuern, indem Sie die Sit-zungsvariable binlog_format einstellen.

Mit einem Binärlog, das Events im zeilenbasierten Format enthält, ist eine punktgenaueWiederherstellung schwieriger zu realisieren, aber nicht unmöglich. Ein Log-Server kanndabei helfen – mehr dazu später.

Theoretisch löst die zeilenbasierte Replikation verschiedene Probleme, auf die wir späternoch kommen. In der Praxis setzen jedoch die meisten Leute, von denen wir wissen, dasssie MySQL 5.1 im täglichen Betrieb benutzen, weiterhin auf die anweisungsbasierteReplikation. Es ist deshalb noch zu früh, etwas Abschließendes über die zeilenbasierteReplikation zu sagen.

ReplikationsdateienSchauen wir uns einige der Dateien an, die bei der Replikation verwendet werden. Siekennen bereits das Binärlog und das Relay-Log. Es gibt aber noch mehr Dateien. WoMySQL sie ablegt, hängt hauptsächlich von Ihren Konfigurationseinstellungen ab. Übli-cherweise legen unterschiedliche MySQL-Versionen sie in unterschiedliche Verzeich-nisse. Sie finden sie entweder im Datenverzeichnis oder in dem Verzeichnis, das die .pid-Datei des Servers enthält (auf Unix-artigen Systemen wahrscheinlich /var/run/mysqld/).Hier sind sie:

mysql-bin.indexEin Server, bei dem das Binär-Logging aktiviert ist, besitzt auch eine Datei, diegenauso heißt wie die Binärlogs, allerdings mit dem Suffix .index. Diese Datei ver-folgt die Binärlog-Dateien, die auf der Festplatte existieren. Es handelt sich nicht umeinen Index im Sinne eines Tabellenindex. Stattdessen enthält jede Zeile in der Dateiden Dateinamen einer Binärlog-Datei.

Vielleicht glauben Sie jetzt, dass diese Datei redundant ist und gelöscht werdenkann (schließlich könnte MySQL einfach auf der Festplatte nachschauen, um seineDateien zu finden), das sollten Sie aber unterlassen. MySQL verlässt sich auf dieseIndexdatei und kann eine Binärlog-Datei nicht erkennen, wenn sie hier nichterwähnt wird.

mysql-relay-bin.indexDiese Datei dient dem gleichen Zweck wie die Binärlog-Indexdatei, allerdings fürdie Relay-Logs.

master.infoDiese Datei enthält die Informationen, die ein Slave-Server benötigt, um eine Ver-bindung zu seinem Master herzustellen. Das Format ist einfacher Text (ein Wert proZeile) und kann zwischen den MySQL-Versionen variieren. Löschen Sie diese Datei

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


nicht, da Ihr Slave sonst nicht weiß, wie er sich nach einem Neustart mit dem Mas-ter verbinden soll. Diese Datei enthält das Passwort des Replikationsbenutzers imKlartext, so dass Sie ihre Berechtigungen einschränken müssen.

relay-log.infoDiese Datei enthält die aktuellen Binärlog- und Relay-Log-Koordinaten des Slaves(d.h. die Position des Slaves auf dem Master). Löschen Sie sie nicht, da der Slavesonst nach einem Neustart vergisst, woher er repliziert hat, und möglicherweise ver-sucht, Anweisungen noch einmal abzuspielen, die er bereits ausgeführt hat.

Diese Dateien bilden eine ziemlich plumpe Methode, den Replikations- und Logging-Zustand von MySQL aufzuzeichnen. Leider werden sie nicht synchron geschrieben. Fallsalso bei Ihrem Server der Strom ausfällt und die Dateien noch nicht auf die Festplatteübertragen waren, könnten sie nach einem Neustart fehlerhaft sein.

Standardmäßig tragen die Binärlogs den Hostnamen des Servers mit einem zusätzlichennumerischen Suffix, allerdings ist es besser, ihnen in my.cnf explizit einen Namen zugeben:

log_bin # Nicht so, sonst werden die Dateien mit dem Hostnamen benanntlog_bin = mysql-bin # Das ist sicher

Das ist wichtig, weil sonst die Replikation fehlschlagen könnte, wenn sich der Hostnamedes Servers ändert. Wir empfehlen darüber hinaus, nicht den Hostnamen für die Benen-nung zu verwenden – klopfen Sie also die Vorgaben nicht auch noch fest. Legen Sie statt-dessen einen Namen für Ihre Binärlogs fest, und benutzen Sie ihn allgemein. Dadurchwird es viel einfacher, die Datei eines Servers auf eine andere Maschine zu verschiebenund das Failover zu automatisieren.

Sie sollten auch die Relay-Logs (die standardmäßig ebenfalls nach dem Hostnamen desServers benannt werden) und die entsprechenden .index-Dateien explizit mit Namen ver-sehen. Hier sind unsere empfohlenen my.cnf-Einstellungen für all diese Optionen:

log_bin = mysql-binlog_bin_index = mysql-bin.indexrelay_log = mysql-relay-binrelay_log_index = mysql-relay-bin.index

Die .index-Dateien erben ihre Namen eigentlich von den Log-Dateien, allerdings schadetes nichts, wenn man sie explizit benennt.

Die .index-Dateien arbeiten auch mit einer anderen Einstellung zusammen, nämlichexpire_logs_days, die angibt, wie MySQL abgelaufene Binärlogs aufräumen soll. Wenndie mysql-bin.index-Dateien Dateien erwähnen, die es auf der Festplatte gar nicht gibt,funktioniert die automatische Reinigung nicht, ja, nicht einmal die Anweisung PURGEMASTER LOGS funktioniert. Die Lösung für dieses Problem besteht im Allgemeinen darin,die Binärlogs vom MySQL-Server verwalten zu lassen, damit dieser nicht durcheinander-kommt.

Sie müssen explizit eine Log-Reinigungsstrategie implementieren, entweder mitexpire_logs_days oder auf andere Weise, da MySQL ansonsten die Festplatte mit Binär-

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


logs füllt. Denken Sie in diesem Zusammenhang gleich über Ihre Backup-Regelungennach. Mehr über das Binärlog erfahren Sie in »Das Binärlogformat« auf Seite 532.

Replikations-Events an andere Slaves sendenMit der Option log_slave_updates können Sie einen Slave als Master für andere Slavesverwenden. Sie weist MySQL an, die Events, die der Slave-SQL-Thread ausführt, in seineigenes Binärlog zu schreiben, das andere Slaves sich dann holen und ausführen können.Abbildung 8-2 verdeutlicht das.

In diesem Szenario sorgt eine Änderung auf dem Master dafür, dass ein Event in seinBinärlog geschrieben wird. Der erste Slave holt sich das Event und führt es aus. An dieserStelle wäre das Leben des Events normalerweise vorbei. Da aber log_slave_updates akti-viert ist, schreibt der Slave das Event stattdessen in sein eigenes Binärlog. Jetzt kann derzweite Slave das Event in sein Relay-Log übertragen und ausführen. Diese Konfigurationsorgt also dafür, dass Änderungen auf dem ursprünglichen Master an Slaves weiterver-teilt werden können, die nicht direkt an den Master angeschlossen sind. Wir setzenlog_slave_updates immer, weil Sie dadurch einen Slave anschließen können, ohne denServer neu starten zu müssen.

Wenn der erste Slave ein Binärlog-Event vom Master in sein eigenes Binärlog schreibt,befindet sich das Event mit hoher Wahrscheinlichkeit an einer anderen Position als aufdem Master – d.h., es könnte in einer anderen Log-Datei stehen oder an einer anderennumerischen Position innerhalb der Log-Datei. Sie dürfen also nicht davon ausgehen,dass alle Server, die sich an der gleichen logischen Stelle in der Replikation befinden, diegleichen Log-Koordinaten aufweisen. Wie wir später sehen werden, wird dadurch dieErledigung mancher Aufgaben verkompliziert, etwa das Wechseln der Slaves zu einemanderen Master oder das Ankündigen eines Slaves als Master.

Abbildung 8-2: Ein Replikations-Event an weitere Slaves übergeben

Master Slave

Lesen Mit log_slave_updates

Lesen

Relay-Log

Slave

Binary-Log

Daten-änderungen

Ein/Ausgabe-Thread

SQL-Thread

Lesen

Binärlog Relay- Log

Schreiben Wieder-abspielen

Wieder-abspielen

Lesen

Ein/Ausgabe-Thread

SQL-Thread

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Falls Sie nicht sorgfältig darauf geachtet haben, jedem Server eine eindeutige Server-ID zugeben, könnte die Konfiguration eines Slaves auf diese Weise zu schleichenden Fehlernführen oder sogar dafür sorgen, dass sich die Replikation beschwert und stoppt. Eine deram häufigsten auftretenden Fragen in Bezug auf die Konfiguration der Replikation lautet,weshalb man die Server-ID angeben muss. Müsste MySQL nicht in der Lage sein, Anwei-sungen zu replizieren, ohne zu wissen, woher sie stammen? Wieso kümmert sich MySQLdarum, ob die Server-ID global eindeutig ist? Die Antwort auf diese Frage ist darin zusuchen, wie MySQL eine Endlosschleife bei der Replikation verhindert. Wenn der Slave-SQL-Thread das Relay-Log liest, dann verwirft er alle Events, deren Server-ID seiner eige-nen entspricht. Dadurch werden Endlosschleifen bei der Replikation unterbrochen. DasVerhindern von Endlosschleifen ist für einige der nützlichsten Replikationstopologienwichtig, etwa für die Master-Master-Replikation.

Falls Sie Probleme damit haben, die Replikation in Gang zu bekommen,dann sollten Sie als eines der ersten Dinge die Server-ID überprüfen. Esreicht nicht, nur die @@server_id-Variable zu untersuchen. Diese besitzteinen Vorgabewert, allerdings funktioniert die Replikation nur, wenn die-ser Vorgabewert ausdrücklich gesetzt ist, entweder in my.cnf oder übereinen SET-Befehl. Wenn Sie einen SET-Befehl verwenden, dann denken Siedaran, auch die Konfigurationsdatei zu aktualisieren, da Ihre Einstellun-gen sonst einen Serverneustart nicht überleben.

ReplikationsfilterDie Möglichkeiten zur Replikationsfilterung erlauben es Ihnen, nur einen Teil der Server-daten zu replizieren. Es gibt zwei Arten von Replikationsfiltern: solche, die Events ausdem Binärlog auf dem Master filtern, und solche, die Events filtern, die aus dem Relay-Log auf dem Slave kommen. Abbildung 8-3 illustriert die beiden Arten.

Abbildung 8-3: Möglichkeiten zur Replikationsfilterung

Master Slave

Lesen

Bin rlog

binlog_do_dbbinlog_ignore_db replicate_do_db

replicate_do_tablereplicate_ignore_dbreplicate_ignore_tablereplicate_rewrite_dbreplicate_wild_do_tablereplicate_wild_ignore_table

Ein/Ausgabe-Thread

SQL-Thread

Lesen

Relay- Log

Schreiben

Wiederabspielen

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Die Optionen zur Filterung des Binärlogs heißen binlog_do_db und binlog_ignore_db.Normalerweise sollten Sie sie nicht aktivieren, wie wir gleich erklären.

Auf dem Slave filtern die replicate_*-Optionen Events, während der Slave-SQL-Threadsie aus dem Relay-Log liest. Sie können eine oder mehrere Datenbanken replizieren oderignorieren, eine Datenbank in eine andere Datenbank umschreiben und Tabellen aufBasis einer LIKE-Mustervergleichssyntax replizieren oder ignorieren.

Sie müssen vor allen Dingen verstehen, dass die Optionen *_do_db und *_ignore_dbsowohl auf dem Master als auch auf dem Slave nicht so funktionieren, wie Sie es viel-leicht erwarten. Vermutlich glauben Sie, dass die Optionen auf der Datenbank des ange-gebenen Objekts filtern, dabei filtern sie tatsächlich auf der aktuellen Standarddatenbank.Das heißt, wenn Sie die Anweisungen

mysql> USE test;mysql> DELETE FROM sakila.film;

auf dem Master ausführen, filtern die Parameter *_do_db und *_ignore_db die DELETE-Anweisung auf test, nicht auf sakila. Normalerweise ist das nicht das, was Sie wollen,und kann dazu führen, dass die falschen Anweisungen repliziert oder ignoriert werden.Es gibt Anwendungen für die Parameter *_do_db und *_ignore_db, allerdings sind diesebegrenzt und selten, und Sie sollten sie sehr vorsichtig einsetzen. Wenn Sie diese Parame-ter verwenden, kann es leicht vorkommen, dass die Replikation in eine Schieflage gerät.

Die Optionen binlog_do_db und binlog_ignore_db haben nicht nur dasPotenzial, die Replikation zu stören, sondern machen es auch nochunmöglich, eine punktgenaue Wiederherstellung aus einem Backup durch-zuführen. Sie sollten sie in den meisten Situationen nicht verwenden. Wirzeigen Ihnen weiter hinten in diesem Kapitel einige sichere Methoden, dieReplikation mit Blackhole-Tabellen zu filtern.

Mit Replikationsfiltern möchte man normalerweise verhindern, dass GRANT- und REVOKE-Anweisungen auf Slaves repliziert werden.5 Oft kommt es vor, dass ein Administratoreinem Benutzer mit GRANT bestimmte Schreibberechtigungen auf dem Master gewährt hatund dann feststellt, dass diese auf den Slave weiterverbreitet wurden, wo der Benutzereigentlich keine Daten ändern dürfte. Die folgenden Replikationsoptionen auf dem Slaveverhindern das:

replicate_ignore_table=mysql.columns_privreplicate_ignore_table=mysql.dbreplicate_ignore_table=mysql.hostreplicate_ignore_table=mysql.procs_privreplicate_ignore_table=mysql.tables_privreplicate_ignore_table=mysql.user

5 Eine bessere Möglichkeit, die Berechtigungen auf Slaves zu beschränken, besteht darin, read_only zu benutzenund auf dem Master und den Slaves die gleichen Berechtigungen einzusetzen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikationstopologien | 393

Vielleicht haben Sie den Tipp erhalten, einfach alle Tabellen in der mysql-Datenbank miteiner solchen Regel auszufiltern:

replicate_wild_ignore_table=mysql.%

Sicher, damit wird verhindert, dass GRANT-Anweisungen repliziert werden, allerdings wer-den jetzt auch keine Events und Routinen repliziert. Solche unvorhergesehenen Folgensind der Grund dafür, weshalb wir gesagt haben, dass Sie mit Filtern vorsichtig sein müs-sen. Es ist sicher besser, wenn Sie verhindern, dass bestimmte Anweisungen repliziertwerden. Üblicherweise erreichen Sie das mit SET SQL_LOG_BIN=0, obwohl auch dieses Vor-gehen Gefahren birgt. Im Allgemeinen sollten Sie Replikationsfilter sehr vorsichtig einset-zen und auch nur, wenn Sie sie wirklich brauchen, weil es leicht ist, mit ihnen dieanweisungsbasierte Replikation zu stören. (Zeilenbasierte Replikation könnte einige die-ser Probleme lösen, allerdings ist das noch nicht vollständig bewiesen.)

Die Filteroptionen sind im MySQL-Handbuch gut dokumentiert, weshalb wir die Einzel-heiten hier nicht wiederholen wollen.

ReplikationstopologienSie können die MySQL-Replikation für fast jede Konfiguration aus Mastern und Slaveseinrichten. Als Einschränkung gilt nur, dass eine Instanz eines MySQL-Slaves nur einenMaster haben darf. Es sind viele komplexe Topologien möglich, doch selbst die einfa-chen können sehr flexibel sein. Eine einzige Topologie kann viele unterschiedlicheAnwendungszwecke haben. Behalten Sie dies im Hinterkopf, wenn Sie unsere Beschrei-bungen lesen, weil wir nur die einfachen Anwendungen beschreiben. Die Vielfalt derMöglichkeiten könnte leicht ein ganzes Buch füllen.

Wir haben bereits gesehen, wie man einen Master mit einem einzigen Slave einrichtet. Indiesem Abschnitt schauen wir uns weitere gebräuchliche Topologien an und diskutierenderen Stärken und Beschränkungen. Merken Sie sich diese Grundregeln:

• Eine MySQL-Slave-Instanz kann nur einen Master haben.

• Jeder Slave muss eine eindeutige Server-ID besitzen.

• Ein Master kann viele Slaves haben (bzw. ein Slave kann entsprechend vieleGeschwister aufweisen).

• Ein Slave kann Änderungen von seinem Master weiterverbreiten und der Masteranderer Slaves sein, falls Sie log_slave_updates aktivieren.

Ein Master und mehrere SlavesNeben der bereits erwähnten, zwei Server umfassenden Master-Slave-Anordnung ist diesdie einfachste Replikationstopologie. Sie ist im Prinzip genauso einfach wie die Grundan-ordnung, weil die Slaves überhaupt nichts miteinander zu tun haben; sie sind jeweils nurmit dem Master verbunden. Abbildung 8-4 zeigt dieses Arrangement.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Diese Konfiguration ist am sinnvollsten, wenn Sie wenige Schreib- und viele Leseopera-tionen haben. Sie können die Lesevorgänge über eine beliebige Anzahl Slave-Server ver-teilen, und zwar bis zu dem Punkt, an dem die Slaves zu viel Last auf den Master legenoder die Netzwerkbandbreite vom Master zu den Slaves zu einem Problem wird. Sie kön-nen viele Slaves auf einmal einrichten oder sie bei Bedarf hinzufügen. Dabei gehen Siegenauso vor, wie wir es bereits gezeigt haben.

Obwohl diese Topologie sehr einfach ist, genügt sie vielen Anforderungen. Hier sind nureinige Anregungen:

• Verwenden Sie unterschiedliche Slaves für unterschiedliche Rollen (z.B. für unter-schiedliche Indizes oder Storage-Engines).

• Richten Sie einen der Slaves als Reserve-Master ein, zu dem es keinen weiteren Ver-kehr als die Replikation gibt.

• Setzen Sie einen der Slaves als Notfallreserve in ein entferntes Rechenzentrum.

• Richten Sie einen oder mehrere Slaves mit Zeitverzögerung ein, so dass er als Not-fallreserve dienen kann.

• Nutzen Sie einen der Slaves für Backups, zu Trainingszwecken oder als Entwick-lungs- oder Staging-Server.

Einer der Gründe für die Beliebtheit dieser Topologie besteht darin, dass sie viele derKomplexitäten vermeidet, die andere Konfigurationen mit sich bringen. Hier ein Beispiel:Es ist leicht, einen Slave in Bezug auf die Binärlog-Positionen auf dem Master mit einemanderen Slave zu vergleichen, weil sie gleich sind. Mit anderen Worten: Wenn Sie alleSlaves an der gleichen logischen Position in der Replikation stoppen, dann lesen sie allevon der gleichen physischen Stelle im Log des Masters. Das ist eine hübsche Eigenschaft,die viele administrative Aufgaben vereinfacht, wie etwa die Beförderung eines Slaves zumMaster.

Diese Eigenschaft gilt allerdings nur zwischen »verschwisterten« Slaves. Zwischen Ser-vern, die sich nicht in einer direkten Master-Slave- oder Geschwisterbeziehung befinden,lassen sich Log-Positionen nicht so einfach vergleichen. Viele der Topologien, die wir

Abbildung 8-4: Ein Master mit mehreren Slaves

Master

Slave Slave Slave

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


später vorstellen, wie etwa die Baumreplikation oder Distribution-Master, erlauben esnicht so einfach festzustellen, von welcher Stelle in der logischen Abfolge der Events einSlave tatsächlich repliziert.

Master-Master im Aktiv-Aktiv-ModusDie Master-Master-Replikation (auch als Dual-Master- oder bidirektionale Replikationbezeichnet) umfasst zwei Server, die jeweils als Master und als Slave des anderen Serverskonfiguriert sind – mit anderen Worten: ein Paar aus Co-Mastern. Abbildung 8-5 ver-deutlicht dies.

Es gibt Anwendungen für eine Master-Master-Replikation im Aktiv-Aktiv-Modus, aller-dings sind diese üblicherweise sehr speziell. Ein möglicher Anwendungszweck ist für geo-grafisch getrennte Büros, bei denen jedes Büro seine eigene lokal schreibbare Kopie derDaten benötigt.

Abbildung 8-5: Master-Master-Replikation

MySQL unterstützt keine Multimaster-ReplikationWir verwenden den Begriff Multimaster-Replikation ganz speziell, um einen Slave mitmehr als einem Master zu beschreiben. Unabhängig davon, was man Ihnen erzählt hat,unterstützt MySQL (im Gegensatz zu einigen anderen Datenbankservern) momentan dieKonfiguration, die in Abbildung 8-6 gezeigt wird, nicht. Wir zeigen Ihnen jedoch weiterhinten in diesem Kapitel einige Möglichkeiten, die Multimaster-Replikation zu emulieren.

Leider benutzen viele Leute diesen Begriff gelegentlich, um eine Anordnung zu beschrei-ben, bei der es mehr als einen Master in der gesamten Replikationstopologie gibt, wie etwadie »Baum«-Topologie, auf die wir noch kommen. Andere Leute beschreiben damit diesogenannte Master-Master-Replikation, bei der die Server gegenseitig als Master und Slaveauftreten.

Diese Probleme mit der Terminologie verursachen viel Verwirrung und sogar Streit. Des-halb ist es unserer Meinung nach am besten, sorgfältig mit den Namen umzugehen. StellenSie sich vor, wie schwierig es wird, sich zu verständigen, wenn MySQL auf einmal Unter-stützung für einen Slave mit zwei Mastern bietet! Welchen Begriff würden Sie dafür benut-zen, wenn Sie »Multimaster-Replikation« nicht reserviert haben?

Master Master

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Das größte Problem mit einer solchen Konfiguration besteht darin, wie mit widersprüch-lichen Änderungen umgegangen wird. Die Liste der möglichen Probleme, die dadurchverursacht werden, dass man zwei schreibbare Co-Master hat, ist sehr lang. Problemetreten normalerweise auf, wenn eine Abfrage gleichzeitig auf beiden Mastern die gleicheZeile ändert oder zum gleichen Zeitpunkt auf beiden Servern etwas in eine Tabelle miteiner AUTO_INCREMENT-Spalte einfügt.

Seit MySQL 5.0 gibt es einige Replikationsfunktionen, die diese Art der Replikation einwenig sicherer machen: die Einstellungen auto_increment_increment und auto_increment_offset. Diese Einstellungen erlauben es Servern, automatisch nicht-widersprüchlicheWerte für INSERT-Abfragen zu generieren. Es ist aber immer noch gefährlich, auf beidenServern Schreiboperationen zu erlauben. Updates, die auf den beiden Maschinen inunterschiedlicher Reihenfolge geschehen, können weiterhin dafür sorgen, dass die Datenstillschweigend in Konflikt geraten. Stellen Sie sich z.B. vor, dass Sie eine Tabelle miteiner Spalte und einer Zeile haben, die den Wert 1 enthält. Nehmen Sie nun an, dassdiese beiden Anweisungen gleichzeitig ausgeführt werden:

• Auf dem ersten Co-Master:

mysql> UPDATE tbl SET col=col + 1;

• Auf dem zweiten:

mysql> UPDATE tbl SET col=col * 2;

Das Ergebnis? Ein Server hat den Wert 4, der andere den Wert 3. Und dennoch gibt eskeine Replikationsfehler.

Dass Daten durcheinanderkommen, ist nur der Anfang. Was passiert, wenn die normaleReplikation mit einem Fehler stoppt, die Anwendung aber weiter auf beide Serverschreibt? Sie können nicht einfach einen der Server von dem anderen klonen, weil beidevon ihnen Änderungen enthalten, die Sie auf den anderen kopieren müssen. Es ist ver-mutlich ziemlich schwer, dieses Problem zu lösen.

Wenn Sie eine Master-Master-Aktiv-Aktiv-Konfiguration sorgfältig einrichten, mögli-cherweise mit gut partitionierten Daten und Berechtigungen, können Sie einige dieser

Abbildung 8-6: MySQL unterstützt keine Multimaster-Replikation.

Slave

Master Master

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Probleme vermeiden.6 Es ist jedoch schwierig, das wirklich gut hinzubekommen, undnormalerweise gibt es eine bessere Methode, das gewünschte Ziel zu erreichen.

Im Allgemeinen bringt es mehr Ärger, als dass es nützt, wenn man Schreiboperationenauf beiden Servern zulässt. Eine Aktiv-Passiv-Konfiguration dagegen ist ganz sinnvoll,wie Sie im nächsten Abschnitt sehen werden.

Master-Master im Aktiv-Passiv-ModusEs gibt eine Variante der Master-Master-Replikation, mit der man die gerade besproche-nen Nachteile vermeidet und die in der Tat eine sehr leistungsfähige Methode darstellt,um fehlertolerante und hochverfügbare Systeme zu entwickeln. Der wesentliche Unter-schied besteht darin, dass einer der Server ein schreibgeschützter »passiver« Server ist,wie Abbildung 8-7 zeigt.

Mit dieser Konfiguration können Sie die aktiven und passiven Serverrollen leicht wech-seln, da die Konfigurationen der Server symmetrisch sind. Dadurch werden Failover undFailback erleichtert. Außerdem können Sie Wartungsarbeiten, Tabellenoptimierungen,Betriebssystem-(oder Anwendungs- oder Hardware-)Upgrades und andere Aufgabenohne Ausfallzeiten durchführen.

So wird z.B. durch das Ausführen einer ALTER TABLE-Anweisung die gesamte Tabellegesperrt, d.h., Lese- und Schreiboperationen werden blockiert. Dieser Zustand kannlange anhalten und den Service unterbrechen. Die Master-Master-Konfiguration erlaubtes Ihnen jedoch, die Slave-Threads auf dem aktiven Server zu stoppen, so dass keineAktualisierungen vom passiven Server mehr verarbeitet werden. Ferner können Sie beieiner Master-Master-Konfiguration die Tabelle auf dem passiven Server verändern, dieRollen vertauschen und den Slave-Prozess auf dem vormals aktiven Server neu starten.7

Dieser Server liest dann sein Relay-Log und führt die gleiche ALTER TABLE-Anweisung aus.Auch dies kann lange dauern, was aber egal ist, da der Server aktuell keine Abfragenbedient.

6 Einige, aber nicht alle – wir können den Advocatus Diaboli spielen und Ihnen in praktisch jeder vorstellbarenAnordnung Schwachstellen zeigen.

Abbildung 8-7: Master-Master-Replikation im Aktiv-Passiv-Modus

7 Sie können das Binär-Logging zeitweise mit SET SQL_LOG_BIN=0 deaktivieren, anstatt die Replikation zu stop-pen. Manche Befehle, wie etwa OPTIMIZE TABLE, unterstützen auch die Optionen LOCAL oder NO_WRITE_TO_BINLOG,die das Logging verhindern.

Aktiv Passiv

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Mit der Aktiv-Passiv-Master-Master-Topologie umgehen Sie viele weitere Probleme undBeschränkungen in MySQL. Sie können sich beim Einrichten und Verwalten eines sol-chen Systems vom MySQL-Master-Master Replication Manager (http://code.google.com/p/mysql-master-master/) unterstützen lassen. Dieses Programm automatisiert viele kniff-lige Aufgaben, wie etwa das Wiederherstellen und Neusynchronisieren der Replikation,das Einrichten neuer Slaves usw.

Schauen wir uns an, wie man ein Master-Master-Paar konfiguriert. Führen Sie dieseSchritte auf beiden Servern aus, damit die Konfigurationen symmetrisch bleiben:

1. Aktivieren Sie das Binär-Logging, wählen Sie eindeutige Server-IDs, und legen SieAccounts für die Replikation an.

2. Aktivieren Sie das Logging von Slave-Updates. Das ist entscheidend für Failover undFailback, wie Sie später sehen werden.

3. Konfigurieren Sie optional den passiven Server als schreibgeschützt, um Änderun-gen zu verhindern, die mit Änderungen auf dem aktiven Server in Konflikt geratenkönnten.

4. Stellen Sie sicher, dass die Server exakt die gleichen Daten enthalten.

5. Starten Sie die MySQL-Instanz auf allen Servern.

6. Konfigurieren Sie die einzelnen Server als Slave des jeweils anderen Servers, wobeiSie mit dem neu angelegten Binärlog beginnen.

Wir wollen nun verfolgen, was geschieht, wenn es eine Änderung auf dem aktiven Servergibt. Die Änderung wird in sein Binärlog geschrieben und gelangt durch die Replikationin das Relay-Log des passiven Servers. Der passive Server führt die Abfrage aus undschreibt das Event in sein eigenes Binärlog, da Sie log_slave_updates eingeschaltet haben.Der aktive Server holt dann die gleiche Änderung über die Replikation in sein eigenesRelay-Log, ignoriert sie jedoch, weil die Server-ID des Events seiner eigenen entspricht.

In »Die Master wechseln« auf Seite 415 erfahren Sie, wie Sie die Rollen vertauschen.

Das Einrichten einer Aktiv-Passiv-Master-Master-Topologie ist ein bisschen wie dasAnlegen eines Hot-Spare, nur dass Sie hier das »Spare« verwenden können, um die Per-formance anzukurbeln. Sie können es für Leseabfragen, Backups, »Offline«-Wartungsar-beiten, Upgrades usw. einsetzen – Dinge, die mit einem echten Hot-Spare nicht möglichsind. Allerdings erzielen Sie hiermit keine bessere Schreib-Performance als mit einem ein-zelnen Server (mehr dazu später).

Wenn wir weitere Szenarien und Anwendungen für die Replikation vorstellen, kommenwir auf diese Konfiguration zurück. Es ist eine sehr wichtige und verbreitete Replika-tionstopologie.

Master-Master mit SlavesBei einer verwandten Konfiguration werden jedem Co-Master ein oder mehrere Slaveshinzugefügt (siehe Abbildung 8-8).

http://code.google.com/p/mysql-master-master/

http://code.google.com/p/mysql-master-master/

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Vorteilhaft an dieser Konfiguration ist die zusätzliche Redundanz. In einer geografischverteilten Replikationstopologie vermeidet sie die eine Schwachstelle jedes Standorts.Wir üblich können Sie außerdem leseintensive Abfragen auf die Slaves abschieben.

Wenn Sie lokal für ein schnelles Failover eine Master-Master-Topologie einsetzen, kannIhnen diese Konfiguration dennoch helfen. Es ist möglich, aber auch etwas komplexer,einen der Slaves zu befördern, um einen ausgefallenen Master zu ersetzen. Das gilt auchfür das Verschieben eines der Slaves derart, dass er auf einen anderen Master verweist.Die zusätzliche Komplexität ist ein wichtiger Gesichtspunkt.

RingDie Dual-Master-Konfiguration ist in Wirklichkeit ein Sonderfall8 der Ring-Replikations-konfiguration, die in Abbildung 8-9 zu sehen ist. Ein Ring umfasst drei oder mehr Mas-ter. Jeder Server ist ein Slave des vorhergehenden Servers im Ring und ein Master desnachfolgenden Servers. Diese Topologie wird auch als kreisförmige Replikation bezeich-net.

Abbildung 8-8: Master-Master-Replikation mit Slaves

8 Ein etwas vernünftigerer Sonderfall, wie wir hinzufügen wollen.

Abbildung 8-9: Eine Replikationsringtopologie

Master Master

Slave Slave

Master

Master Master

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Ringe verfügen nicht über die wichtigsten Vorteile einer Master-Master-Anordnung, wieetwa symmetrische Konfiguration und einfaches Failover. Darüber hinaus sind sie voll-ständig davon abhängig, dass jeder Knoten im Ring verfügbar ist, wodurch sich dieWahrscheinlichkeit stark erhöht, dass das gesamte System ausfällt. Und falls Sie einender Knoten aus dem Ring entfernen, können alle Replikations-Events, die von diesemKnoten stammten, in eine Endlosschleife gelangen. Sie kreisen für immer durch dieTopologie, weil der einzige Server, der sie anhand ihrer Server-ID filtern könnte, der Ser-ver ist, der sie erzeugt hat. Ringe sind im Allgemeinen eigenwillig und sollten am bestenvermieden werden.

Sie können einige der Risiken einer ringförmigen Replikationsanordnung mildern, indemSie Slaves hinzufügen, die an jedem Standort für Redundanz sorgen (siehe Abbildung 8-10).Das schützt allerdings nur vor dem Risiko eines Serverausfalls. Ein Stromausfall oder einanderes Problem, das die Verbindung zwischen den Standorten beeinflusst, unterbrichtweiterhin den gesamten Ring.

Master, Distribution-Master und SlavesWir haben erwähnt, dass Slaves eine ziemliche Last auf einen Master laden können,wenn es genügend von ihnen gibt. Jeder Slave erzeugt auf dem Master einen neuenThread, der den speziellen binlog dump-Befehl ausführt. Dieser Befehl liest die Daten ausdem Binärlog und schickt sie an den Slave. Die Arbeit wird für jeden Slave-Thread wie-derholt; die Threads teilen sich die Ressourcen nicht, die für einen Binlog-Dump benötigtwerden.

Abbildung 8-10: Ein Replikationsring mit Slaves an jedem Standort

Master Master

Master

Slave

SlaveSlave

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Wenn es viele Slaves und ein besonders großes Binärlog-Event, wie ein riesiges LOAD DATAINFILE, gibt, kann die Last auf dem Master deutlich ansteigen. Dem Master geht unterUmständen sogar der Speicher aus, und er stürzt ab, weil alle Slaves gleichzeitig das glei-che riesige Event anfordern. Falls andererseits die Slaves unterschiedliche Binlog-Eventsanfordern, die sich nicht mehr im Dateisystem-Cache befinden, werden vermutlich vieleFestplattensuchen verursacht, die sich ebenfalls zuungunsten der Leistung des Serversauswirken.

Aus diesem Grund bietet es sich an, die Last vom Server zu nehmen und einen Distribu-tion-Master einzusetzen, wenn Sie viele Slaves benötigen. Ein Distribution-Master ist einSlave, dessen einziger Zweck darin besteht, die Binärlogs vom Master zu lesen und anzu-bieten. Mit dem Distribution-Master können sich viele Slaves verbinden, wodurch derursprüngliche Master von der Last abgeschirmt wird. Um zu vermeiden, dass die Abfra-gen tatsächlich auf dem Distribution-Master ausgeführt werden, sollten Sie seine Tabel-len in die Blackhole-Storage-Engine überführen, wie es in Abbildung 8-11 gezeigt ist.

Es ist schwer, genau anzugeben, wie viele Slaves ein Master bedienen kann, bevor ereinen Distribution-Master braucht. Als Faustregel gilt: Wenn ein Master mit fast vollerKapazität läuft, dann sollten Sie ihm nicht mehr als 10 Slaves zuordnen. Gibt es nur einegeringe Schreibaktivität oder replizieren Sie nur einen Bruchteil der Tabellen, dann kannder Master wahrscheinlich viel mehr Slaves bedienen. Außerdem müssen Sie sich nichtauf einen Distribution-Master beschränken. Sie können mehrere verwenden, wenn Sieauf eine wirklich große Zahl von Slaves replizieren müssen. Sogar eine Pyramide aus Dis-tribution-Mastern wäre möglich.

Der Distribution-Master lässt sich auch für andere Aufgaben benutzen, wie etwa das Fil-tern und das Umschreiben von Regeln für die Binärlog-Events. Das ist effizienter, alswenn Sie das Logging, Umschreiben und Filtern auf jedem Slave wiederholen.

Abbildung 8-11: Ein Master, ein Distribution-Master und viele Slaves

Master

Distribution-Master mitBlackhole-Storage-Engine

Viele Slaves

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Falls Sie auf dem Distribution-Master mit Blackhole-Tabellen arbeiten, kann dieser mehrSlaves bedienen als üblich. Der Distribution-Master führt die Abfragen aus, die ausge-sprochen preiswert sind, weil die Blackhole-Tabellen keine Daten enthalten.

Häufig taucht die Frage auf, wie man sicherstellt, dass alle Tabellen auf dem Distribu-tion-Master die Blackhole-Storage-Engine benutzen. Was passiert, wenn jemand auf demMaster eine neue Tabelle anlegt und eine andere Storage-Engine festlegt? Das Problemtritt übrigens auch auf, wenn Sie auf einem Slave eine andere Storage-Engine einsetzenwollen. Normalerweise setzt man die storage_engine-Option des Servers:

storage_engine = blackhole

Dies beeinflusst nur CREATE TABLE-Anweisungen, die nicht explizit eine Storage-Engineangeben. Falls Sie eine Anwendung haben, die Sie nicht kontrollieren können, dann istdiese Topologie eventuell empfindlich. Sie können InnoDB mit der Option skip_innodbdeaktivieren und die Tabellen auf MyISAM zurückgreifen lassen, Sie können jedoch dieEngines MyISAM oder Memory nicht ausschalten.

Der andere wesentliche Nachteil ist die Schwierigkeit, den Master durch einen der (tat-sächlichen) Slaves zu ersetzen. Es ist schwierig, einen der Slaves an seine Stelle zu beför-dern, weil der dazwischenliegende Master dafür sorgt, dass er fast immer andereBinärlog-Koordinaten besitzt als der ursprüngliche Master.

Baum oder Pyramide?Falls Sie einen Master auf eine sehr große Anzahl von Slaves replizieren – egal, ob Sie dieDaten geografisch verteilen oder lediglich versuchen, die Lesekapazität zu erhöhen –, kannes praktischer sein, ein pyramidenförmiges Design zu verwenden (siehe Abbildung 8-12).

Abbildung 8-12: Eine pyramidenförmige Replikationstopologie

Slave

Slave Slave

Slave

Slave Slave

Master

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Der Vorteil dieses Aufbaus besteht darin, dass er die Last auf dem Master mildert – genauwie der Distribution-Master im vorherigen Abschnitt. Nachteilig ist, dass jeder Ausfall ineiner Zwischenebene mehrere Server beeinträchtigt. Wären die Slaves jeweils direkt anden Master angeschlossen, würde dies nicht geschehen. Je mehr Zwischenebenen Sieaußerdem haben, umso schwieriger und komplizierter wird der Umgang mit Ausfällen.

Eigene ReplikationslösungenDie MySQL-Replikation ist so flexibel, dass man oft sogar eigene Lösungen für dieAnforderungen einer Anwendung entwickeln kann. Typischerweise nutzt man eine Kom-bination aus Filterung, Verteilung und Replikation auf unterschiedliche Storage-Engines.Sie können natürlich auch »hacken«, also etwa auf und von Servern replizieren, die dieBlackhole-Storage-Engine einsetzen (wie in »Master, Distribution-Master und Slaves« aufSeite 400 besprochen). Ihr Entwurf kann so ausgeklügelt sein, wie Sie wollen. Die größ-ten Einschränkungen betreffen das, was Sie vernünftigerweise überwachen und adminis-trieren können, sowie die Grenzen Ihrer Ressourcen (Netzwerkbandbreite, CPU-Leistung usw.).

Selektive Replikation

Um die Lokalitätseigenschaft auszunutzen und Ihren Arbeitssatz für Leseoperationen imSpeicher zu behalten, können Sie auf jeden der vielen Slaves eine kleine Menge Datenreplizieren. Wenn jeder Slave einen Bruchteil der Daten des Masters enthält und Sie Lese-operationen an die Slaves umleiten, nutzen Sie den Speicher auf den einzelnen Slaves vielbesser aus. Jeder Slave übernimmt auch nur einen Bruchteil der Schreiblast des Masters,so dass der Master viel leistungsfähiger wird, ohne dass die Slaves zurückfallen.

Dieses Szenario ähnelt in gewisser Hinsicht der horizontalen Datenpartitionierung, aufdie wir im nächsten Kapitel ausführlicher eingehen werden, besitzt aber den Vorteil, dassimmer noch ein Server alle Daten vorhält – der Master. Das bedeutet, dass Sie für eineSchreibabfrage niemals auf mehr als einen Server schauen müssen. Gibt es Leseabfragen,die Daten benötigen, die nicht alle auf einem einzigen Slave-Server vorliegen, dann habenSie die Möglichkeit, diese Leseoperationen auf dem Master ausführen zu lassen. Selbstwenn Sie nicht alle Leseoperationen auf den Slaves durchführen können, sollten Sie inder Lage sein, viele von ihnen vom Master abzuziehen.

Am einfachsten geht das, indem Sie die Daten auf verschiedene Datenbanken auf demMaster aufteilen und dann jede Datenbank auf einen anderen Slave-Server replizieren.Falls Sie z.B. Daten für jede Abteilung in Ihrem Unternehmen auf einen anderen Slavereplizieren wollen, legen Sie Datenbanken namens sales, marketing, procurement usw. an.Jeder Slave muss dann eine replicate_wild_do_table-Konfigurationsoption enthalten, dieseine Daten auf die angegebene Datenbank beschränkt. Hier ist die Konfigurationsoptionfür die sales-Datenbank:

replicate_wild_do_table = sales.%

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Das Filtern mit einem Distribution-Master ist ebenfalls sinnvoll. Falls Sie z.B. nur einenTeil eines stark ausgelasteten Servers über ein langsames oder sehr teures Netzwerk repli-zieren wollen, dann nutzen Sie einfach einen lokalen Distribution-Master mit Blackhole-Tabellen und Filterregeln. Der Distribution-Master kann Replikationsfilter enthalten, dieunerwünschte Einträge aus seinen Logs entfernen. Auf diese Weise vermeiden Sie gefähr-liche Loggingeinstellungen auf dem Master, und außerdem müssen Sie nicht alle Logsüber das Netzwerk auf die entfernten Slaves übertragen.

Funktionen trennen

Viele Anwendungen enthalten einen Mix aus OLTP- (Online Transaction Processing)und OLAP-(Online Analytical Processing-)Abfragen. OLTP-Abfragen sind meist kurzund transaktionsfähig. OLAP-Abfragen dagegen sind normalerweise groß und langsamund verlangen keine absolut aktuellen Daten. Die zwei Arten von Abfragen beanspru-chen den Server völlig unterschiedlich. Daher werden sie am besten auf Servern ausge-führt, die verschieden konfiguriert sind und vielleicht sogar unterschiedliche Storage-Engines und Hardware verwenden.

Eine gebräuchliche Lösung für dieses Problem besteht darin, die Daten des OLTP-Serversauf Slaves zu replizieren, die speziell für die OLAP-Last entworfen wurden. Diese Slaveskönnen eine andere Hardware, andere Konfigurationen, Indizes und/oder Storage-Engi-nes besitzen. Wenn Sie einen Slave für OLAP-Abfragen vorsehen, dann könnten Sie aufdiesem Slave auch eine gewisse Verzögerung bei der Replikation oder eine anderweitigverminderte Service-Qualität tolerieren. Das bedeutet möglicherweise, dass Sie ihn fürAufgaben einsetzen, die auf einem nicht speziell zugewiesenen Slave zu einer unakzep-tablen Performance führen würden, etwa für das Ausführen sehr lange laufender Abfra-gen.

Es ist keine spezielle Replikationsanordnung erforderlich. Allerdings erreichen Sie viel-leicht deutliche Einsparungen, wenn Sie nicht alle Daten des Masters auf dem Slavehaben. Denken Sie daran: Selbst wenn Sie nur einen kleinen Teil der Daten mit Replika-tionsfiltern im Relay-Log herausfiltern können, verringern Sie die Ein-/Ausgabe- undCache-Aktivität.

Daten archivieren

Sie können Daten auf einem Slave-Server archivieren – d.h., sie auf dem Slave behalten,aber vom Master entfernen –, indem Sie Löschabfragen auf dem Master ausführen unddafür sorgen, dass diese Abfragen nicht auf dem Slave ausgeführt werden. Dazu sind zweiMethoden üblich: Entweder Sie deaktivieren selektiv das Binär-Logging auf dem Master,oder Sie setzen auf dem Slave replicate_ignore_db-Regeln ein.

Die erste Methode verlangt das Ausführen von SET SQL_LOG_BIN=0 in dem Prozess, der dieDaten auf dem Master aufräumt. Anschließend werden die Daten aufgeräumt. Auf demSlave ist in diesem Fall keine besondere Replikationskonfiguration erforderlich. Und dadie Anweisungen auch nicht in das Binärlog des Masters gelangen, ist diese Methode

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


sogar noch ein bisschen effizienter. Der größte Nachteil besteht darin, dass Sie das Binär-log auf dem Master nicht mehr dazu verwenden können, die punktgenaue Wiederher-stellung zu überwachen, da es nicht mehr jede Modifikation enthält, die Sie an den Datendes Masters vorgenommen haben. Außerdem ist für diese Methode die SUPER-Berechti-gung nötig.

Bei der zweiten Technik wird eine bestimmte Datenbank mit USE auf dem Master einge-setzt, bevor die Anweisungen ausgeführt werden, die die Daten aufräumen. Sie könnenz.B. eine Datenbank namens purge anlegen und dann in der my.cnf-Datei des Slavesreplicate_ignore_db=purge festlegen. Anschließend starten Sie den Slave neu. Der Slaveignoriert Anweisungen, die diese Datenbank mit USE benutzen. Dieser Ansatz hat nichtdie Schwächen der ersten Technik, bringt allerdings den (kleinen) Nachteil mit sich, dassder Slave veranlasst wird, Binärlog-Events zu holen, die er gar nicht braucht. Potenziellkönnte außerdem jemand versehentlich Abfragen in der purge-Datenbank ausführen, dienicht zum Aufräumen der Daten gedacht sind, was den Slave dazu bringt, gewünschteEvents nicht wieder abzuspielen.

Das Maakit-Programm mk-archiver unterstützt beide Methoden.

Eine dritte Möglichkeit besteht darin, mit binlog_ignore_db Replikations-Events herauszufiltern. Wie wir aber bereits angemerkt haben, halten wirdas in den meisten Situationen für gefährlich.

Slaves für Volltextsuchen einsetzen

Viele Anwendungen verlangen eine Kombination aus Transaktionen und Volltextsuchen.Allerdings sind nur in MyISAM-Tabellen Fähigkeiten zur Volltextsuche eingebaut, undMyISAM unterstützt keine Transaktionen. Eine Lösung wäre, einen Slave für Volltextsu-chen zu konfigurieren, indem die Storage-Engine für bestimmte Tabellen auf dem Slaveauf MyISAM geändert wird. Sie können Volltextindizes hinzufügen und Volltextsuchab-fragen auf dem Slave ausführen. Dadurch werden potenzielle Replikationsprobleme mittransaktionsfähigen und nichttransaktionsfähigen Storage-Engines in derselben Abfrageauf dem Master vermieden, und der Master muss nicht noch zusätzlich die Volltextindi-zes pflegen.

Schreibgeschützte Slaves

In vielen Unternehmen zieht man es vor, die Slaves nur zum Lesen zuzulassen, damitungewollte Änderungen nicht die Replikation unterbrechen. Dazu verwendet man dieKonfigurationsvariable read_only. Sie deaktiviert die meisten Schreiboperationen: Aus-nahmen bilden die Slave-Prozesse, Benutzer mit der Berechtigung SUPER und temporäreTabellen. Diese Lösung ist perfekt, solange Sie nicht normalen Benutzern die Berechti-gung SUPER gewähren, was Sie sowieso nie tun sollten.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Multimaster-Replikation emulieren

MySQL bietet momentan keine Unterstützung für die Multimaster-Replikation (d.h.einen Slave mit mehr als einem Master). Sie können diese Topologie jedoch emulieren,indem Sie einen Slave so konfigurieren, dass er abwechselnd auf unterschiedliche Masterverweist. Zum Beispiel verweisen Sie den Slave auf Master A und lassen ihn eine Weilelaufen, richten ihn dann für eine Weile auf Master B und wechseln dann wieder zurückauf Master A. Wie gut das funktioniert, hängt von Ihren Daten ab sowie davon, wie vielArbeit die beiden Master für den einen Slave verursachen. Ist die Last auf Ihren Masternrelativ leicht und kommen sich ihre Updates nicht ins Gehege, dann könnte das ganz gutfunktionieren.

Sie müssen die Binärlog-Koordinaten für die einzelnen Master im Auge behalten. Außer-dem sollten Sie sicherstellen, dass der Ein-/Ausgabe-Thread des Slaves nicht mehr Datenholt, als er in jedem Durchlauf ausführen soll; ansonsten erhöhen Sie unter Umständenden Netzwerkverkehr deutlich, indem Sie in jedem Zyklus viele Daten holen und verwer-fen.

Es gibt für diesen Zweck ein fertiges Skript: http://code.google.com/p/mysql-mmre/.

Sie können die Multimaster-Replikation mithilfe einer Master-Master- (oder Ring-) Repli-kation und der Blackhole-Storage-Engine mit einem Slave emulieren, wie Abbildung 8-13zeigt.

In dieser Konfiguration besitzen die beiden Master jeweils ihre eigenen Daten. Sie enthal-ten außerdem die Tabellen vom anderen Master, benutzen aber die Blackhole-Storage-Engine, um zu vermeiden, dass sie tatsächlich Daten in diesen Tabellen speichern. EinSlave ist an einen der Co-Master angeschlossen – es spielt keine Rolle, an welchen. DieserSlave verwendet nicht die Blackhole-Storage-Engine, so dass er im Prinzip der Slave bei-der Master ist.

Abbildung 8-13: Emulation der Multimaster-Replikation mit zwei Mastern und der Blackhole-Storage-Engine

Co-Master1

DB2

DB1

Co-Master2

DB2

DB1

Slave1

DB2

DB1Blackhole-Storage-Engines

http://code.google.com/p/mysql-mmre/

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Eigentlich ist dafür keine Master-Master-Topologie erforderlich. Sie können einfach vonserver1 auf server2 auf den Slave replizieren. Wenn server2 die Blackhole-Storage-Engine für Tabellen benutzt, die von server1 repliziert wurden, enthält er keine Datenvon server1, wie in Abbildung 8-14 zu sehen ist.

Beide Konfigurationen können unter den üblichen Problemen leiden, wie etwa wider-sprüchlichen Aktualisierungen und CREATE TABLE-Anweisungen, die explizit eine Storage-Engine angeben.

Einen Log-Server erzeugen

Eines der Dinge, die Sie mit der MySQL-Replikation erreichen können, ist die Erzeugungeines »Log-Servers« ohne Daten, dessen einzige Aufgabe darin besteht, das Abspielenund/oder Filtern von Binärlog-Events zu erleichtern. Wie Sie später erkennen werden,nützt das, wenn man die Replikation nach einem Absturz neu starten muss, und hilft beider punktgenauen Wiederherstellung, die wir in Kapitel 11 vorstellen.

Stellen Sie sich vor, Sie haben eine Gruppe von Binärlogs oder Relay-Logs – vielleicht auseinem Backup, vielleicht von einem abgestürzten Server – und wollen die darin enthalte-nen Events wieder abspielen. Sie könnten die Events mit mysqlbinlog extrahieren, beque-mer und effizienter ist es jedoch, eine MySQL-Instanz ohne Daten einzurichten und ihrvorzugaukeln, dass die Binärlogs ihre eigenen wären. Sie können das MySQL Sandbox-Skript von http://sourceforge.net/projects/mysql-sandbox/ benutzen, um den Log-Servereinzurichten, falls Sie ihn nur zeitweise benötigen. Der Log-Server benötigt keine Daten,weil er keine Logs ausführen wird – er dient nur den Logs der anderen Server. (Er brauchtallerdings einen Replikationsbenutzer.)

Schauen wir uns an, wie diese Technik funktioniert (Anwendungen dafür zeigen wir spä-ter). Nehmen Sie an, die Logs heißen somelog-bin.000001, somelog-bin.000002 usw.

Abbildung 8-14: Eine weitere Methode, um die Multimaster-Replikation zu emulieren

Master 1

Master 2

Slave

DB1

DB2

DB1

DB2

DB1


Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Legen Sie diese Dateien in das Binärlogverzeichnis Ihres Log-Servers. Wir nehmen einmalan, das ist /var/log/mysql. Bevor Sie den Log-Server starten, bearbeiten Sie seine my.cnf-Datei:

log_bin = /var/log/mysql/somelog-binlog_bin_index = /var/log/mysql/somelog-bin.index

Der Server entdeckt die Log-Dateien nicht automatisch, Sie müssen also die Log-Index-datei des Servers aktualisieren. Nutzen Sie dazu auf Unix-artigen Systemen folgendenBefehl:9

# /bin/ls -1 /var/log/mysql/somelog-bin.[0-9]* > /var/log/mysql/somelog-bin.index

Sorgen Sie dafür, dass der Benutzer-Account, unter dem MySQL läuft, die Log-Indexda-tei lesen und schreiben kann. Jetzt können Sie Ihren Log-Server starten und mit SHOWMASTER LOGS überprüfen, ob er die Log-Dateien sieht.

Wieso ist es für die Wiederherstellung besser, einen Log-Server anstelle von mysqlbinlogeinzusetzen? Dafür gibt es mehrere Gründe:

• Es ist schneller, weil jetzt die Anweisungen nicht mehr aus dem Log extrahiert undan mysql geleitet werden müssen.

• Sie können den Fortgang leicht überblicken.

• Sie können Fehlern leicht begegnen. Es ist z.B. möglich, Anweisungen zu übersprin-gen, die nicht repliziert werden können.

• Sie können leicht Replikations-Events filtern.

• Manchmal ist mysqlbinlog aufgrund der Änderungen des Logging-Formats nicht inder Lage, das Binärlog zu lesen.

Replikation und KapazitätsplanungMeist sind Schreiboperationen die Engstelle bei der Replikation. Es ist schwierig, Schreib-operationen mit der Replikation zu skalieren. Sie müssen richtig rechnen, wenn Sie pla-nen, welche Kapazität die Slaves Ihrem System insgesamt hinzufügen. Es kommt indiesem Zusammenhang leicht zu Fehlern.

Stellen Sie sich z.B. vor, Ihre Arbeitsbelastung besteht zu 20 % aus Schreib- und zu 80 %aus Lesevorgängen. Um die Berechnungen zu erleichtern, wollen wir vereinfachen undFolgendes annehmen:

• Lese- und Schreibabfragen erfordern die gleiche Menge Arbeit.

• Alle Server sind genau gleich und haben die Kapazität, exakt 1.000 Abfragen proSekunde zu erledigen.

9 Wir benutzen explizit /bin/ls, um zu verhindern, dass gebräuchliche Aliase aufgerufen werden, die Terminal-Escape-Codes für eine farbige Darstellung hinzufügen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikation und Kapazitätsplanung | 409

• Slaves und Master besitzen die gleichen Leistungsmerkmale.

• Sie können alle Leseabfragen auf die Slaves verschieben.

Falls Sie momentan einen Server haben, der 1.000 Abfragen pro Sekunde erledigt, wieviele Slaves müssen Sie dann hinzufügen, um das Doppelte Ihrer aktuellen Last zu verar-beiten und alle Leseabfragen auf die Slaves zu verschieben?

Es sieht so aus, als könnten Sie 2 Slaves hinzufügen und die 1.600 Leseoperationen zwi-schen ihnen aufteilen. Vergessen Sie jedoch nicht, dass Ihre Schreiblast sich auf 400Abfragen pro Sekunde erhöht hat und nicht zwischen Mastern und Slaves aufgeteilt wer-den kann. Jeder Slave muss 400 Schreiboperationen pro Sekunde durchführen. Dasbedeutet, dass jeder Slave zu 40 % mit Schreiboperationen belastet wird und nur 600Leseoperationen pro Sekunde bedienen kann. Daher brauchen Sie nicht zwei, sonderndrei Slaves, um den doppelten Verkehr zu erledigen.

Was ist, wenn Ihr Verkehr sich wieder verdoppelt? Es gibt dann 800 Schreiboperationenpro Sekunde, der Master kommt also noch hinterher. Die Slaves sind dann aber auch zu80 % mit Schreiboperationen belastet, so dass Sie 16 Slaves brauchen, um die 3.200 Lese-abfragen pro Sekunde zu verarbeiten. Und wenn sich der Verkehr jetzt noch ein wenigerhöht, ist es für den Master zu viel.

Das ist weit von einer linearen Skalierbarkeit entfernt: Sie benötigen 17-mal so viele Ser-ver, um die vierfache Anzahl an Abfragen zu verarbeiten. Dies verdeutlicht, dass Sieschnell einen Punkt abnehmender Erträge erreichen, wenn Sie Slaves zu einem einzigenMaster hinzufügen. Und das gilt sogar bei unseren unrealistischen Annahmen, die z.B.die Tatsache ignorieren, dass eine anweisungsbasierte Single-Thread-Replikation norma-lerweise dafür sorgt, dass die Slaves eine niedrigere Kapazität als der Master aufweisen.Eine echte Replikationsanordnung ist wahrscheinlich sogar noch schlechter als unseretheoretische.

Weshalb die Replikation das Skalieren von Schreiboperationen nicht unterstütztDas grundlegende Problem mit dem miesen Verhältnis von Server zu Kapazität bestehtdarin, dass Sie die Schreibvorgänge im Gegensatz zu den Lesevorgängen nicht gleicher-maßen zwischen den Maschinen verteilen können. Leseoperationen lassen sich also ska-lieren, Schreiboperationen nicht.

Sie werden sich fragen, ob es eine Möglichkeit gibt, mittels Replikation die Schreibkapa-zität zu erhöhen. Die Antwort lautet Nein – nicht einmal ein bisschen. Das Aufteilen(Partitionieren) Ihrer Daten ist die einzige Methode, mit der Sie Schreiboperationen ska-lieren können. Näheres dazu finden Sie im nächsten Kapitel.

Manche Leser denken jetzt vielleicht darüber nach, eine Master-Master-Topologie zu ver-wenden (siehe »Master-Master im Aktiv-Aktiv-Modus« auf Seite 395) und auf beide Mas-ter zu schreiben. Diese Konfiguration kann im Vergleich zu einer Master-Slave-Topologie

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


etwas mehr Schreiboperationen erledigen, weil Sie die Nachteile durch die Serialisierunggleichmäßig zwischen den beiden Servern aufteilen können. Wenn Sie auf jedem Server50 % der Schreiboperationen erledigen, dann müssen nur die 50 %, die via Replikationvom anderen Server erfolgen, serialisiert werden. Theoretisch ist das besser, als 100 %der Schreiboperationen parallel auf einer Maschine (dem Master) durchzuführen und100 % der Schreiboperationen seriell auf der anderen Maschine (dem Slave).

Das scheint attraktiv zu sein. Eine solche Konfiguration kann allerdings trotzdem nichtso viele Schreiboperationen durchführen wie ein einzelner Server. Ein Server, dessenSchreiblast zu 50 % serialisiert ist, ist langsamer als ein einzelner Server, der alle seineSchreibvorgänge parallel erledigt.

Deshalb eignet sich diese Taktik nicht zum Skalieren von Schreiboperationen. Es ist nureine Methode, um den Nachteil serialisierten Schreibens auf zwei Server zu verteilen,damit das »schwächste Glied in der Kette« nicht ganz so schwach ist. Sie bietet nur einerelativ kleine Verbesserung gegenüber einer Aktiv-Passiv-Anordnung, das zusätzlicheRisiko ist jedoch unverhältnismäßig viel größer – und, wie Sie im nächsten Abschnitterfahren, Sie haben eigentlich gar nichts davon.

Seien Sie großzügig und verschwenderischWenn Sie Ihre Server absichtlich teilweise ungenutzt lassen, können Sie auf clevere undkosteneffektive Weise eine große Anwendung aufbauen, speziell, wenn Sie Replikationeinsetzen. Server, die freie Kapazitäten aufweisen, tolerieren Lastspitzen besser, habenmehr Potenzial, um langsame Abfragen und Wartungsaufgaben zu erledigen (wie etwaOPTIMIZE TABLE-Operationen), und halten besser mit der Replikation Schritt.

Es ist normalerweise der falsche Ansatz zu versuchen, die Replikationsnachteile auszu-gleichen, indem man in einer Master-Master-Topologie auf beide Knoten schreibt. Siesollten ein Master-Master-Paar üblicherweise zu weniger als 50 % mit Leseoperationenbelasten, denn wenn die Last größer ist, reicht die Kapazität nicht aus, falls einer der Ser-ver ausfällt. Wenn beide Server die Last auch allein bewältigen könnten, dann müssen Siesich wahrscheinlich nicht um die Nachteile bei der Single-Thread-Replikation sorgen.

Das Anlegen einer übertriebenen Kapazität stellt darüber hinaus eines der besten Mitteldar, um Hochverfügbarkeit zu erreichen, obwohl es dafür auch andere Methoden gibt.So könnten Sie Ihre Anwendung auch in einem »geschwächten« Modus ausführen, wennes einen Ausfall gegeben hat. Im nächsten Kapitel untersuchen wir das genauer.

Replikationsadministration und -wartungVermutlich werden Sie sich nicht ständig mit dem Einrichten der Replikation befassen,zumindest, wenn Sie nicht sehr viele Server haben. Sobald Sie allerdings mit der Einrich-tung fertig sind, gehören Überwachung und Administration Ihrer Replikationstopologiezu Ihren regelmäßigen Aufgaben, egal, wie viele Server Sie haben.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikationsadministration und -wartung | 411

Sie sollten versuchen, diese Arbeit nach Möglichkeit zu automatisieren. Allerdings müs-sen Sie dazu keine eigenen Werkzeuge schreiben: In Kapitel 14 stellen wir verschiedeneProgramme für MySQL vor, von denen viele bereits mit Überwachungsmöglichkeitenoder Plugins ausgestattet sind. Zu den nützlichsten Angeboten gehören Nagios, MySQLEnterprise Monitor und MonYOG.

Die Replikation überwachenDie Replikation erhöht die Komplexität der MySQL-Überwachung. Obwohl die Replika-tion sowohl auf dem Master als auch auf dem Slave stattfindet, wird die meiste Arbeit aufdem Slave erledigt. Dort treten auch die meisten Probleme auf. Replizieren wirklich alleSlaves? Hat ein Slave Fehler gezeigt? Wie weit liegt der langsamste Slave zurück? MySQLbietet die meisten Informationen, die Sie benötigen, um diese Fragen zu beantworten.Ihnen bleibt es allerdings überlassen, den Vorgang zu überwachen und die Replikation zustabilisieren.

Auf dem Master können Sie mit dem Befehl SHOW MASTER STATUS die aktuelle Binärlog-Position des Masters und die Konfiguration ermitteln (siehe »Master und Slave konfigu-rieren« auf Seite 378). Sie können den Master auch fragen, welche Binärlogs auf der Fest-platte vorliegen:

mysql> SHOW MASTER LOGS;+------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000220 | 425605 || mysql-bin.000221 | 1134128 || mysql-bin.000222 | 13653 || mysql-bin.000223 | 13634 |+------------------+-----------+

Diese Informationen helfen Ihnen dabei, festzustellen, welche Parameter Sie dem BefehlPURGE MASTER LOGS übergeben müssen. Mit dem Befehl SHOW BINLOG EVENTS können Sie sichReplikations-Events im Binärlog anschauen. Nachdem wir z.B. den vorangegangenenBefehl ausgeführt hatten, erzeugten wir eine Tabelle auf einem ansonsten unbenutztenServer. Da wir wussten, dass dies die einzige Anweisung war, die irgendwelche Datenändert, wussten wir, dass der Offset der Anweisung im Binärlog 13634 war. Wir konntensie uns also folgendermaßen anschauen:

mysql> SHOW BINLOG EVENTS IN 'mysql-bin.000223' FROM 13634\G*************************** 1. row ***************************

Log_name: mysql-bin.000223Pos: 13634

Event_type: QueryServer_id: 1

End_log_pos: 13723Info: use `test`; CREATE TABLE test.t(a int)

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Den Rückstand des Slaves messenZu den Dingen, die Sie am häufigsten überwachen müssen, gehört der Rückstand, denein Slave gegenüber dem Master hat. Die Spalte Seconds_behind_master in SHOW SLAVESTATUS zeigt zwar theoretisch den Rückstand des Slaves, dieser Wert ist allerdings ausverschiedenen Gründen nicht immer exakt:

• Der Slave berechnet Seconds_behind_master, indem er den aktuellen Zeitstempel desServers mit dem Zeitstempel vergleicht, der im Binärlog-Event aufgezeichnet ist, sodass der Slave seinen Rückstand erst dann melden kann, wenn er eine Abfrage verar-beitet.

• Der Slave gibt normalerweise NULL zurück, wenn die Slave-Prozesse nicht laufen.

• Manche Fehler (z.B. falsch angepasste max_allowed_packet-Einstellungen zwischendem Master und dem Slave oder ein instabiles Netzwerk) können die Replikationunterbrechen und/oder die Slave-Threads stoppen. Seconds_behind_master gibtjedoch eine 0 zurück, anstatt einen Fehler anzuzeigen.

• Der Slave kann manchmal die Verzögerung nicht berechnen, obwohl die Slave-Pro-zesse laufen. Wenn dies geschieht, meldet der Slave entweder 0 oder NULL.

• Eine sehr lange Transaktion kann dafür sorgen, dass der berichtete Rückstandschwankt. Falls Sie z.B. eine Transaktion haben, die Daten aktualisiert, stundenlangoffen bleibt und dann bestätigt wird, gelangt die Aktualisierung ungefähr eineStunde, nachdem sie tatsächlich aufgetreten ist, in das Binärlog. Wenn der Slave dieAnweisung verarbeitet, berichtet er zeitweise, dass er eine Stunde hinter dem Mas-ter zurückliegt, und springt dann wieder auf einen Rückstand von null Sekunden.

• Wenn ein Distribution-Master zurückfällt und selbst Slaves besitzt, berichten dieSlaves, dass sie null Sekunden zurückliegen, wenn sie zum Distribution-Master auf-geholt haben, obwohl es relativ zum eigentlichen Master einen wirklichen Rück-stand gibt.

Ignorieren Sie deshalb Seconds_behind_master, und messen Sie die Verzögerung des Slavesmit etwas, das Sie direkt überwachen und messen können. Eine gute Lösung wäre einHeartbeat Record, also ein Zeitstempel, den Sie einmal pro Sekunde auf dem Masteraktualisieren können. Um den Rückstand zu berechnen, subtrahieren Sie einfach denHeartbeat vom aktuellen Zeitstempel auf dem Slave. Diese Methode ist immun gegen-über all den gerade erwähnten Problemen und hat den zusätzlichen Vorteil, dass einpraktischer Zeitstempel erzeugt wird, der zeigt, an welchem Punkt in der Zeit sich dieDaten des Slaves momentan befinden. Das mk-heartbeat-Skript, das in Maatkit enthaltenist, ist eine Implementierung eines Replikations-Heartbeats.

Keines der genannten Maße für den Rückstand bietet Ihnen einen Anhaltspunkt dafür,wie lange es dauert, bis ein Slave tatsächlich seinen Master eingeholt hat. Das hängt vonvielen Faktoren ab, etwa von der Leistungsfähigkeit des Slaves und der Anzahl derSchreibabfragen, die der Master verarbeitet.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Feststellen, ob Slaves konsistent mit dem Master sindIn einer perfekten Welt würde ein Slave immer eine exakte Kopie seines Masters sein.Tatsächlich aber sorgen Fehler bei der Replikation dafür, dass die Daten des Slaves vondenen des Masters »wegdriften«. Selbst wenn offensichtlich keine Fehler auftreten, kön-nen Slaves abweichen, weil es MySQL-Eigenschaften gibt, die nicht korrekt repliziertwerden, weil Bugs in MySQL, Netzwerkschäden, Abstürze, unsanftes Herunterfahrenoder andere Ausfälle auftreten.10

Unserer Erfahrung nach ist das die Regel, nicht die Ausnahme, was bedeutet, dass eseigentlich eine Routineaufgabe sein sollte, Ihre Slaves auf Konsistenz mit ihren Masternzu prüfen. Das ist besonders wichtig, wenn Sie die Replikation für Backups benutzen,weil Sie natürlich keine Backups von einem beschädigten Slave nehmen wollen.

Die erste Ausgabe dieses Buches enthielt ein Beispielskript, mit dem man die Anzahl derZeilen in den Tabellen auf dem Master und dem Slave vergleichen konnte. Damit kannman sicher einige Unterschiede feststellen, allerdings ist die Zeilenanzahl keine echteGewähr für identische Daten. Was Sie wirklich brauchen, ist eine effiziente Methode, umdie eigentlichen Inhalte der Tabellen zu vergleichen.

In MySQL ist keine Methode integriert, mit der sich feststellen ließe, ob ein Server diegleichen Daten enthält wie ein anderer Server. Es besitzt einige Grundbausteine, um Prüf-summen von Tabellen und Daten zu erzeugen, wie etwa CHECKSUM TABLE. Es ist jedochnicht trivial, einen Slave mit seinem Master zu vergleichen, während die Replikation imGange ist.

Maatkit enthält ein Werkzeug namens mk-table-checksum, das dieses und etliche andereProbleme löst. Das Werkzeug besitzt mehrere Funktionen, einschließlich schneller paral-leler Vergleiche vieler Server auf einmal. Seine Hauptfunktion ist allerdings, zu verifizie-ren, ob die Daten eines Slaves synchron zu denen seines Masters sind. Dazu führt esINSERT ... SELECT-Abfragen auf dem Master ab.

Diese Abfragen erzeugen Prüfsummen der Daten und fügen die Ergebnisse in eineTabelle ein. Die Anweisungen laufen durch die Replikation und werden erneut auf demSlave ausgeführt. Sie können die Ergebnisse auf dem Master dann mit den Ergebnissenauf dem Slave vergleichen und feststellen, ob sich die Daten unterscheiden. Da dieserVorgang durch die Replikation geht, erhalten Sie konsistente Ergebnisse, ohne dass Siedie Tabellen auf beiden Servern gleichzeitig sperren müssen.

Typischerweise wird dieses Werkzeug auf dem Master ausgeführt, und zwar mit solchenParametern:

$ mk-table-checksum --replicate=test.checksum --chunksize 100000 --sleep-coef=2 <master_host>

10 Wenn Sie eine nichttransaktionsfähige Storage-Engine benutzen, dann ist das Herunterfahren des Servers,ohne zuerst STOP SLAVE auszuführen, unsanft.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Dieser Befehl erzeugt aus allen Tabellen Prüfsummen, wobei er versucht, die Tabellen inGruppen von ungefähr 100.000 Zeilen zu verarbeiten, und fügt die Ergebnisse in dietest.checksum-Tabelle ein. Zwischen den einzelnen Verarbeitungsgruppen pausiert erund schläft doppelt so lange, wie es dauerte, die Prüfsumme für die letzte Gruppe zuerzeugen. Damit wird sichergestellt, dass die Abfragen den normalen Datenbankbetriebnicht blockieren.

Sobald die Abfragen auf den Slaves repliziert wurden, kann eine einfache Abfrage denSlave auf Unterschiede zum Master prüfen. mk-table-checksum sucht automatisch dieSlaves eines Servers, führt die Abfrage auf den einzelnen Slaves aus und gibt die Ergeb-nisse aus. Der folgende Befehl steigt, jeweils beim gleichen Master-Server beginnend, bisauf eine Tiefe von 10 in der Slave-Hierarchie hinab und gibt Tabellen aus, die sich vomMaster unterscheiden:

$ mk-table-checksum --replicate=test.checksum --replcheck 10 <master_host>

Bei MySQL AB plant man, irgendwann eine ähnliche Funktion im Server selbst zu imple-mentieren. Das ist dann wahrscheinlich besser als ein externes Skript, aber momentan istmk-table-checksum das einzige Werkzeug, mit dem man zuverlässig und einfach dieDaten eines Slaves mit denen seines Masters vergleichen kann.

Einen Slave wieder mit dem Master synchronisierenSie werden vermutlich mehr als einmal in Ihrer beruflichen Laufbahn mit einem Slave inBerührung kommen, dessen Daten nicht mehr mit denen des Masters übereinstimmen.Vielleicht haben Sie mit der Prüfsummentechnik Unterschiede entdeckt, vielleicht wissenSie auch, dass der Slave eine Abfrage übersprungen hat oder dass jemand die Daten aufdem Slave geändert hat.

Der herkömmliche Rat zum Reparieren eines nichtsynchronisierten Slaves lautet, ihn zustoppen und wieder vom Master zu klonen. Wenn ein inkonsistenter Slave ein ernsthaf-tes Problem darstellt, dann sollten Sie ihn wahrscheinlich anhalten und aus dem Betriebentfernen, sobald Sie ihn gefunden haben. Anschließend können Sie den Slave erneutklonen oder aus einem Backup wiederherstellen.

Nachteilig an diesem Ansatz ist seine Unbequemlichkeit, vor allem, wenn Sie viele Datenhaben. Wenn Sie feststellen können, welche Daten sich unterscheiden, dann können Siees vermutlich effizienter erledigen, als durch das erneute Klonen des gesamten Servers.Und wenn die entdeckte Inkonsistenz nicht bedeutsam ist, dann lassen Sie ihn einfach inBetrieb und synchronisieren nur die betroffenen Daten.

Am einfachsten ist es, nur die betroffenen Daten mit mysqldump zu speichern und erneutzu laden. Das funktioniert ganz gut, wenn sich die Daten währenddessen nicht ändern.Sie sperren die Tabelle auf dem Master, stellen einen Dump der Tabelle her, wartendarauf, dass der Slave den Master einholt, und importieren dann die Tabelle auf denSlave. (Sie müssen auf den Slave warten, damit Sie in den anderen Tabellen keine weite-ren Inkonsistenzen einführen, wie etwa solche, die dann wiederum in Joins mit der nicht-synchronisierten Tabelle auftreten.)

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Das geht zwar in vielen Fällen gut, ist aber auf einem stark belasteten Server oft unmög-lich. Es hat außerdem den Nachteil, dass die Daten des Slaves außerhalb der Replikationgeändert werden. Das Ändern der Slave-Daten durch die Replikation (indem Änderun-gen auf dem Master vorgenommen werden) ist normalerweise die sicherste Technik, dahässliche Race-Conditions und andere Überraschungen vermieden werden. Wenn dieTabelle sehr groß oder die Netzwerkbandbreite begrenzt ist, dann sind das Speichern ineinem Dump und das Neuladen unerschwinglich teuer. Was ist, wenn sich jede tau-sendste Zeile in einer Tabelle mit Millionen von Zeilen unterscheidet? Das Speichern undNeuladen der gesamten Tabelle wäre in diesem Fall eine Verschwendung.

mk-table-sync ist ein weiteres Werkzeug von Maatkit, das einige dieser Probleme löst. Eskann Unterschiede zwischen Tabellen effizient finden und auflösen. Außerdem kann esdurch die Replikation agieren, indem es den Slave durch das Ausführen von Abfragen aufdem Master neu synchronisiert – also: keine Race-Conditions. Es funktioniert jedochnicht in allen Szenarien: Es erfordert, dass die Replikation läuft, um einen Master undeinen Slave korrekt zu synchronisieren. Das Werkzeug funktioniert also nicht, wenn beider Replikation ein Fehler auftritt. mk-table-sync wurde mit Blick auf Effizienz geschaf-fen, ist bei extrem großen Datenmengen jedoch unpraktisch. Der Vergleich von einemTerabyte Daten auf dem Master und dem Slave verursacht zwangsläufig zusätzlicheArbeit für beide Server. In Fällen, in denen es jedoch funktioniert, können Sie eine MengeZeit und Aufwand sparen.

Die Master wechselnFrüher oder später müssen Sie einen Slave auf einen neuen Master richten. Vielleicht tau-schen Sie die Server aufgrund eines Upgrades, vielleicht gab es ja auch einen Ausfall undSie müssen einen Slave zum Master machen, oder vielleicht teilen Sie einfach nur neueKapazitäten zu. Egal, welchen Grund es gibt, Sie müssen den Slave über seinen neuenMaster informieren.

Wenn der Prozess geplant ist, dann ist es leicht (oder zumindest leichter als im Krisen-fall). Sie rufen auf dem Slave einfach den CHANGE MASTER TO-Befehl mit den passenden Wer-ten auf. Die meisten der Werte sind optional; Sie müssen nur diejenigen angeben, die Sieändern. Der Slave verwirft seine aktuelle Konfiguration und die Relay-Logs und beginntdamit, vom neuen Master zu replizieren. Er aktualisiert außerdem die master.info-Dateimit den neuen Parametern, damit die Änderung einen Neustart des Slaves überdauert.

Der schwierigste Teil dieses Vorgangs ist das Ermitteln der gewünschten Position aufdem neuen Master, damit der Slave an der gleichen logischen Position beginnt, an der erauf dem alten Master gestoppt hat.

Das Befördern eines Slaves zum neuen Master ist etwas schwieriger. Es gibt zwei Grund-szenarien, wie man einen Master durch einen seiner Slaves ersetzt. Beim ersten handelt essich um eine geplante Beförderung, beim zweiten um eine ungeplante.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Geplante Beförderungen

Einen Slave zum Master zu befördern, ist vom Konzept her einfach. Es sind folgendeSchritte erforderlich:

1. Schreiboperationen auf dem alten Master werden gestoppt.

2. Optional müssen seine Slaves bei der Replikation aufholen (dies vereinfacht dienachfolgenden Schritte).

3. Ein Slave muss zum neuen Master konfiguriert werden.

4. Slaves und Schreibverkehr müssen auf den neuen Master gerichtet werden, anschlie-ßend müssen Schreiboperationen auf ihm zugelassen werden.

Der Teufel steckt jedoch im Detail. Es sind mehrere Szenarien möglich, je nach IhrerReplikationstopologie. So unterscheiden sich die Schritte bei einer Master-Master-Topo-logie leicht von denen bei einer Master-Slave-Anordnung.

Hier sind, etwas ausführlicher, die Schritte, die Sie wahrscheinlich in den meisten Anord-nungen unternehmen müssen:

1. Stoppen Sie alle Schreiboperationen auf dem aktuellen Master. Falls möglich soll-ten Sie sogar alle Clientprogramme (nicht die Replikationsverbindungen) zwingen,sich zu beenden. Es hilft, wenn Sie Ihre Clientprogramme mit einem »Do not run«-Flag erstellt haben, das Sie setzen können. Wenn Sie virtuelle IP-Adressen benut-zen, können Sie einfach ihre Verarbeitung ausschalten und dann alle Clientverbin-dungen beenden, um deren offenen Transaktionen zu schließen.

2. Stoppen Sie optional mit FLUSH TABLES WITH READ LOCK alle Schreibaktivitäten auf demMaster. Sie können auf dem Master mit der Option read_only auch einen Schreib-schutz setzen. Von diesem Augenblick an sollten Sie alle Schreibvorgänge auf demzu ersetzenden Master verbieten. Da er jetzt kein Master mehr ist, würden Sieansonsten Daten verlieren, wenn Sie auf ihm schreiben lassen!

3. Wählen Sie einen der Slaves als neuen Master aus, und stellen Sie sicher, dass er inder Replikation vollständig aufgeholt hat (d.h., lassen Sie ihn das Ausführen allerRelay-Logs beenden, die er vom alten Master geholt hat).

4. Überprüfen Sie optional, dass der neue Master die gleichen Daten enthält wie deralte Master.

5. Führen Sie STOP SLAVE auf dem neuen Master aus.

6. Führen Sie auf dem neuen Master CHANGE MASTER TO MASTER_HOST='' aus, gefolgt vonRESET SLAVE, um die Verbindung zum alten Master zu trennen und die Verbindungs-informationen in seiner master.info-Datei zu verwerfen. (Das funktioniert nicht rich-tig, wenn die Verbindungsinformationen in my.cnf angegeben sind, weshalb wirauch davon abraten, sie dorthin zu legen.)

7. Holen Sie sich die Binärlog-Koordinaten des neuen Masters mit SHOW MASTER STATUS.

8. Sorgen Sie dafür, dass alle anderen Slaves auf den neuesten Stand kommen.

9. Fahren Sie den alten Master herunter.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


10. Aktivieren Sie in MySQL-Versionen ab 5.1 Events auf dem neuen Master, falls erfor-derlich.

11. Erlauben Sie es den Clients, eine Verbindung zum neuen Master herzustellen.

12. Rufen Sie auf jedem Slave einen CHANGE MASTER TO-Befehl auf, mit dem Sie den jeweili-gen Slave auf den neuen Master richten. Verwenden Sie dabei die Binärlog-Koordi-naten, die Sie mit SHOW MASTER STATUS gesammelt haben.

Wenn Sie einen Slave in einen Master umwandeln, dann achten Siedarauf, dass Sie ihn aus allen Slave-spezifischen Datenbanken, Tabellenund Berechtigungen entfernen. Sie müssen außerdem alle Slave-spezifi-schen Konfigurationsparameter ändern, wie etwa eine innodb_flush_log_at_trx_commit-Option. Falls Sie andererseits einen Master zum Slavezurückstufen, müssen Sie ihn ebenfalls entsprechend umkonfigurieren.Falls Sie Ihre Master und Slaves identisch konfigurieren, müssen Sie nichtsändern.

Ungeplante BeförderungenEs ist nicht ganz so leicht, einen Slave zu befördern, um einen Master zu ersetzen, wenndieser abstürzt. Gibt es nur einen Slave, dann nehmen Sie einfach diesen. Gibt es jedochmehrere Slaves, dann müssen Sie einige zusätzliche Schritte ausführen, um einen Slave inden neuen Master zu verwandeln.

Dazu kommt noch das Problem potenziell verloren gegangener Replikations-Events. Esist möglich, dass einige Updates, die auf dem Master vorgenommen wurden, noch nichtauf alle seine Slaves repliziert wurden. Es kann sogar sein, dass eine Anweisung ausge-führt und dann auf dem Master zurückgenommen wurde, nicht jedoch auf dem Slave –so dass der Slave der logischen Replikationsposition des Masters sogar voraus seinkönnte.11 Falls Sie die Daten des Masters an irgendeinem Punkt wiederherstellen können,dann sind Sie möglicherweise in der Lage, die verloren gegangenen Anweisungen wieder-zubekommen und manuell anzuwenden.

Achten Sie in den folgenden Schritten darauf, die Werte Master_Log_File und Read_Master_Log_Pos in Ihren Berechnungen einzusetzen. Hier ist das Vorgehen beim Beför-dern eines Slaves in einer Master-und-Slaves-Topologie:

1. Stellen Sie fest, welcher Slave die neuesten Daten besitzt. Prüfen Sie die Ausgabe vonSHOW SLAVE STATUS auf jedem Slave, und wählen Sie denjenigen, dessen Master_Log_File/Read_Master_Log_Pos-Koordinaten am neuesten sind.

2. Erlauben Sie allen Slaves, das Ausführen der Relay-Logs zu beenden, die sie vomalten Master geholt hatten, bevor er abgestürzt ist. Wenn Sie den Master eines Sla-ves wechseln, bevor er mit dem Ausführen des Relay-Logs fertig ist, wirft er alle ver-bleibenden Log-Events weg, und Sie wissen nicht, wo er gestoppt hat.

11 Das ist tatsächlich möglich, obwohl MySQL Events erst dann in das Log schreibt, wenn die Transaktion bestä-tigt wurde. Näheres erfahren Sie in »Transaktionsfähige und nichttransaktionsfähige Tabellen mischen« aufSeite 425.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


3. Führen Sie die Schritte 5 bis 7 der Liste aus dem vorangegangenen Abschnitt aus.

4. Vergleichen Sie die Master_Log_File/Read_Master_Log_Pos-Koordinaten der einzel-nen Slaves mit denen des neuen Masters.

5. Führen Sie die Schritte 10 bis 12 der Liste aus dem vorangegangenen Abschnitt aus.

Wir gehen davon aus, dass Sie log_bin und log_slave_updates auf allen Slaves aktivierthaben, wie wir Ihnen zu Beginn dieses Kapitels empfohlen haben. Wenn Sie dieses Log-ging aktivieren, haben Sie die Möglichkeit, alle Slaves zu einem konsistenten Zeitpunktwiederherzustellen, was ansonsten nicht zuverlässig möglich wäre.

Die gewünschten Log-Positionen suchen

Befindet sich einer der Slaves nicht an der gleichen Position wie der neue Master, müssenSie die Position in den Binärlogs des neuen Masters suchen, die dem letzten Event ent-spricht, das der Slave repliziert hat, und für CHANGE MASTER TO einsetzen. Mit dem Pro-gramm mysqlbinlog können Sie die letzte Abfrage untersuchen, die der Slave ausgeführthat, und diese Abfrage im Binärlog des neuen Masters suchen. Ein paar kleine Berech-nungen sind auch oft ganz hilfreich.

Um das zu verdeutlichen, wollen wir annehmen, dass Log-Events ansteigende ID-Num-mern haben und dass der Slave, der auf dem neuesten Stand ist – der neue Master –, geradeEvent 100 erreicht hatte, als der alte Master abstürzte. Nun wollen wir noch annehmen,dass es zwei weitere Slaves gibt, nämlich slave2 und slave3. slave2 hatte Event 99 undslave3 Event 98 erreicht. Wenn Sie beide Slaves auf die aktuelle Binärlog-Position desneuen Masters verweisen, beginnen sie bei Event 101 mit der Replikation, sind also nichtmehr synchron. Solange jedoch das Binärlog des neuen Masters mit log_slave_updates ein-geschaltet war, können Sie die Events 99 und 100 im Binärlog des neuen Masters finden,um die Slaves wieder zurück in einen konsistenten Zustand zu überführen.

Aufgrund von Serverneustarts, unterschiedlichen Konfigurationen, Log-Wechseln oderFLUSH LOGS-Befehlen können die gleichen Events auf unterschiedlichen Servern bei unter-schiedlichen Byte-Offsets existieren. Das Suchen der Events nervt und geht langsam von-statten, ist aber normalerweise nicht schwer. Untersuchen Sie einfach das letzte Event, dasauf dem jeweiligen Slave ausgeführt wurde, indem Sie im Binärlog oder im Relay-Log desSlaves mysqlbinlog ausführen. Suchen Sie anschließend – ebenfalls mit mysqlbinlog – diegleiche Abfrage im Binärlog des neuen Masters. Das Programm gibt den Byte-Offset derAbfrage aus. Sie können diesen Offset dann in der CHANGE MASTER TO-Abfrage einsetzen.

Sie beschleunigen diesen Vorgang, indem Sie die Byte-Offsets, an denen der neue Masterund der Slave gestoppt haben, voneinander abziehen und auf diese Weise die Differenz inihren Byte-Positionen ermitteln. Falls Sie dann diesen Wert von der aktuellen Binärlog-Position des neuen Masters subtrahieren, ist die Wahrscheinlichkeit ziemlich hoch, dassSie die gewünschte Abfrage an dieser Position gefunden haben. Sie müssen nun nur nochverifizieren, dass sie es tatsächlich ist, und haben jetzt die Position, an der Sie den Slavestarten müssen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Schauen wir uns ein konkretes Beispiel an. Stellen Sie sich vor, server1 ist der Master vonserver2 und server3 und stürzt ab. Entsprechend Master_Log_File/Read_Master_Log_Posin SHOW SLAVE STATUS hat es server2 geschafft, alle Events zu replizieren, die sich im Binär-log von server1 befanden; server3 dagegen ist nicht so aktuell. Abbildung 8-15 verdeut-licht dieses Szenario (die Log-Events und Byte-Offsets dienen nur zur Demonstration).

Wie Abbildung 8-15 verdeutlicht, können wir sicher sein, dass server2 alle Events imBinärlog des Masters repliziert hat, weil seine Master_Log_File- und Read_Master_Log_Pos-Werte den letzten Positionen auf server1 entsprachen. Daher können wir server2 zumneuen Master befördern und server3 zu seinem Slave machen.

Doch welche Parameter sollten wir im CHANGE MASTER TO-Befehl auf server3 verwenden?Hier müssen wir ein bisschen rechnen und überlegen. server3 stoppte bei Offset 1493,was 89 Byte hinter Offset 1582 liegt, dem letzten Befehl, den server2 ausgeführt hat.server2 schreibt momentan an Position 8167 in sein Binärlog. 8167 – 89 = 8078, theore-tisch müssen wir also server3 auf diesen Offset in den Logs von server2 verweisen. Es istallerdings keine schlechte Idee, die Log-Events um diese Position herum näher zu unter-suchen und zu verifizieren, dass server2 tatsächlich die richtigen Events an diesem Offsetin seinen Logs hat. Es könnte nämlich dort auch etwas anderes stehen, weil z.B. eineDatenaktualisierung stattgefunden hat, die sich auf server2 beschränkte.

Abbildung 8-15: Als server1 abstürzte, holte server2 auf, aber server3 hinkte hinter der Replikation hinterher.

Server1

mysql-bin.000001

145014931582

UPDATEDELETEINSERT

Server2

mysql-bin.000009

803580788167

UPDATEDELETEINSERT

Server3

Master_Log_File = mysql-bin.000001Read_Master_Log_Pos = 1582

Master_Log_File = mysql-bin.000001Read_Master_Log_Pos = 1493

Binärlog-Dateider Klarheit

wegenweggelassen

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Wenn sich bei der Untersuchung herausgestellt hat, dass es tatsächlich die gleichenEvents waren, machen wir mit dem folgenden Befehl server3 zum Slave von server2:

server2> CHANGE MASTER TO MASTER_HOST="server2", MASTER_LOG_FILE="mysql-bin.000009", MASTER_LOG_POS=8078;

Was ist, wenn server1 beim Absturz ein weiteres Event hinter Offset 1582 ausgeführtund im Log verzeichnet hatte? Da server2 die Events nur bis zum Offset 1582 gelesenund ausgeführt hatte, haben Sie womöglich ein Event für immer verloren. Falls jedochdie Festplatte des alten Masters nicht beschädigt wurde, können Sie das fehlende Eventmit mysqlbinlog oder mit einem Log-Server aus seinem Binärlog wiederherstellen.

Wir empfehlen Ihnen, fehlende Events vom alten Master wiederherzustellen, nachdemSie den neuen Master befördert, aber bevor Sie Clientverbindungen zu diesem Serverzugelassen haben. Auf diese Weise müssen Sie die fehlenden Events nicht auf jedem Slaveausführen, das übernimmt die Replikation für Sie. Ist der ausgefallene Master dagegenvollständig unerreichbar, müssen Sie wahrscheinlich warten und diese Arbeit später erle-digen.

Eine Variante dieses Vorgehens besteht darin, dass Sie eine zuverlässige Methode zurSpeicherung der Binärlog-Dateien des Masters einsetzen, etwa ein SAN oder ein Distri-buted Replicated Block Device (DRBD). Selbst wenn der Master komplett ausgefallen ist,haben Sie immer noch seine Binärlog-Dateien. Sie können einen Log-Server einrichten,die Slaves auf ihn richten und diese dann bis zu der Stelle aufholen lassen, an der derMaster ausgefallen ist. Anschließend ist es trivial, einen der Slaves zum neuen Master zubefördern – das geht im Prinzip genauso wie bei einer geplanten Beförderung. Wirbesprechen diese Speicheroptionen im nächsten Kapitel genauer.

Wenn Sie einen Slave zum neuen Master befördern, dann ändern Sie seineServer-ID nicht auf die des alten Masters. In diesem Fall sind Sie nämlichnicht mehr in der Lage, einen Log-Server einzusetzen, um die Events vomalten Master wieder abzuspielen. Dies ist einer der vielen Gründe dafür,weshalb man Server-IDs als fest betrachten sollte.

Rollentausch in einer Master-Master-KonfigurationEiner der Vorteile der Master-Master-Replikation besteht darin, dass Sie aufgrund dersymmetrischen Konfiguration ganz einfach die aktiven und passiven Rollen vertauschenkönnen. In diesem Abschnitt zeigen wir, wie Sie diesen Tausch vollziehen.

Wenn man die Rollen in einer Master-Master-Konfiguration vertauscht, dann ist es amwichtigsten, sicherzustellen, dass zu einem Zeitpunkt nur auf einen der Co-Mastergeschrieben wird. Überschneiden sich Schreiboperationen von einem Master mit Schreib-operationen vom anderen Master, können sie in einen Konflikt geraten. Mit anderen Wor-ten: Der passive Server darf keine Binärlog-Events vom aktiven Server empfangen,nachdem die Rollen getauscht wurden. Sie können garantieren, dass dies nicht passiert,indem Sie sicherstellen, dass der Slave-Thread des passiven Servers zum aktiven Serveraufholt, bevor Sie ihn schreibbar machen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Replikationsprobleme und Lösungen | 421

Mithilfe der folgenden Schritte vertauschen Sie die Rollen, ohne dass Sie Gefahr laufen,widersprüchliche Aktualisierungen zu erhalten:

1. Stoppen Sie alle Schreiboperationen auf dem aktiven Server.

2. Führen Sie SET @@global.read_only := 1 auf dem aktiven Server aus, und setzen Sieaus Sicherheitsgründen für den Fall eines Neustarts die Option read_only in seinerKonfigurationsdatei. Bedenken Sie, dass Benutzer mit der SUPER-Berechtigung immernoch Änderungen vornehmen könnten. Falls Sie Änderungen von allen Benutzernverhindern wollen, verwenden Sie FLUSH TABLES WITH READ LOCK. Tun Sie dies nicht,müssen Sie alle Clientverbindungen beenden, damit es wirklich keine lange laufen-den Anweisungen oder unbestätigten Transaktionen gibt.

3. Führen Sie SHOW MASTER STATUS auf dem aktiven Server aus, und merken Sie sich dieBinärlog-Koordinaten.

4. Führen Sie SELECT MASTER_POS_WAIT( ) auf dem passiven Server mit den Binärlog-Koordinaten des aktiven Servers aus. Dieser Befehl blockiert, bis die Slave-Prozessezum aktiven Server aufgeholt haben.

5. Führen Sie SET @@global.read_only := 0 auf dem passiven Server aus, und machen Sieihn damit zum aktiven Server.

6. Konfigurieren Sie Ihre Anwendungen neu, damit diese auf den neuen aktiven Serverschreiben.

Je nach der Konfiguration Ihrer Anwendung müssen Sie möglicherweise noch weitereAufgaben ausführen, wie etwa die IP-Adressen auf den beiden Servern ändern. Diesbesprechen wir im nächsten Kapitel.

Replikationsprobleme und LösungenEs ist nicht schwer, die MySQL-Replikation zu unterbrechen. Die einfache Implementie-rung, die die Einrichtung so sehr erleichtert, bietet auch viele Möglichkeiten, sie zu stop-pen, zu verwirren oder anderweitig zu stören. In diesem Abschnitt zeigen wir Ihnenhäufig auftretende Probleme, wie sie sich äußern und wie Sie sie lösen oder sogar vermei-den können.

Durch Datenverfälschung oder -verlust verursachte FehlerAus vielerlei Gründen ist die MySQL-Replikation nicht besonders belastbar, wenn es zuAbstürzen, Stromausfällen und Beschädigungen durch Festplatten-, Speicher- oder Netz-werkfehler kommt. Sie müssen mit hoher Sicherheit irgendwann einmal die Replikationaufgrund dieser Probleme neu starten.

Die meisten Probleme mit der Replikation nach einem unerwarteten Herunterfahrenstammen von einem der Server, der seine Daten nicht mehr auf die Festplatte zurückspei-chern konnte. Rechnen Sie mit folgenden Dingen:

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Unerwartetes Herunterfahren des MastersWenn der Master nicht mit sync_binlog konfiguriert wurde, hat er vor dem Absturzmöglicherweise seine letzten paar Binärlog-Events nicht auf die Festplatte übertra-gen. Der Ein-/Ausgabe-Thread des Slaves war möglicherweise gerade dabei, einEvent einzulesen, das es nie auf die Festplatte geschafft hat. Wenn der Master neustartet, baut der Slave wieder eine Verbindung auf und versucht, dieses Event erneutzu lesen. Der Master antwortet nun jedoch, dass es kein solches Binlog-Offset gibt.Der Binlog-Dump-Prozess geht typischerweise fast sofort los, so dass dies nichtungewöhnlich ist.

Die Lösung dieses Problem sieht so aus, dass der Slave angewiesen wird, mit demLesen am Anfang des nächsten Binärlogs zu beginnen. Manche Log-Events werdenallerdings für immer verloren sein. Das hätte man vermeiden können, wenn derMaster mit sync_binlog konfiguriert worden wäre.

Doch auch wenn Sie sync_binlog konfiguriert haben, können MyISAM-Daten beieinem Absturz beschädigt werden, genau wie InnoDB-Daten, wenn innodb_flush_logs_at_trx_commit nicht auf 1 gesetzt ist.

Unerwartetes Herunterfahren des SlavesWenn der Slave nach einem unerwarteten Herunterfahren wieder startet, liest erseine master.info-Datei, um festzustellen, wo er die Replikation gestoppt hat. Leiderwird diese Datei nicht auf die Festplatte synchronisiert, so dass die Informationen,die sie enthält, wahrscheinlich falsch sind. Der Slave versucht wahrscheinlich, einigeBinärlog-Events erneut auszuführen. Das könnte einige einmalige Indexstörungenverursachen. Solange Sie nicht feststellen, wo der Slave wirklich angehalten hat, wasunwahrscheinlich ist, haben Sie keine andere Wahl, als die resultierenden Fehler zuüberspringen. Dabei kann Ihnen das in Maatkit enthaltene mk-slave-restart-Werk-zeug helfen.

Falls Sie alle InnoDB-Tabellen verwenden, können Sie nach dem Neustart des Sla-ves in das MySQL-Fehler-Log schauen. Der InnoDB-Wiederherstellungsprozess gibtdie Binärlog-Koordinaten bis zu der Stelle an, ab der wiederhergestellt wird; Sie kön-nen mit ihrer Hilfe dann feststellen, wohin der Slave auf dem Master verweisenmuss.

Zusätzlich zu den Datenverlusten, die daher rühren, dass MySQL unsauber beendetwurde, werden oft auch die Binärlogs oder Relay-Logs auf der Festplatte beschädigt. Diessind einige der häufiger auftretenden Szenarien:

Binärlogs auf dem Master sind beschädigtWenn das Binärlog auf dem Master beschädigt ist, haben Sie keine andere Wahl, alszu versuchen, den beschädigten Teil zu überspringen. Sie können auf dem MasterFLUSH LOGS ausführen, damit er eine neue Log-Datei anfängt, und den Slave auf denAnfang des neuen Logs richten. Oder Sie versuchen, das Ende des beschädigtenBereichs zu finden. Manchmal können Sie mit SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1ein einzelnes beschädigtes Event überspringen. Wenn es mehr als ein beschädigtesEvent gibt, wiederholen Sie den Vorgang, bis Sie alle übersprungen haben.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Relay-Logs auf dem Slave sind beschädigtWenn die Binärlogs auf dem Master intakt sind, können Sie die beschädigten Relay-Logs mit CHANGE MASTER TO verwerfen und sie neu holen. Verweisen Sie den Slave ein-fach an die gleiche Position, von der er momentan repliziert (Relay_Master_Log_File/Exec_Master_Log_Pos). Dadurch verwirft er alle Relay-Logs auf der Festplatte.

Das Binärlog ist nicht mehr synchron zum InnoDB-Transaktions-LogStürzt der Master ab, könnte InnoDB eine Transaktion als bestätigt aufzeichnen,obwohl sie gar nicht in das Binärlog auf der Festplatte geschrieben wurde. Es gibtkeine Möglichkeit, die fehlende Transaktion wiederherzustellen, es sei denn, siebefindet sich im Relay-Log eines Slaves. Sie vermeiden diesen Fehler mit demsync_binlog-Parameter in MySQL 5.0 oder den Parametern sync_binlog undsafe_binlog in MySQL 4.1.

Es hängt von der Art der Beschädigung des Binärlogs ab, wie viele Daten Sie wiederher-stellen können. Es können verschiedene Arten auftreten:

Bytes sind geändert, aber das Event ist immer noch gültiges SQLLeider kann MySQL diese Art der Beschädigung gar nicht erkennen. Aus diesemGrund ist es keine schlechte Idee, wenn man regelmäßig überprüft, ob Ihre Slavesdie richtigen Daten enthalten.

Bytes sind geändert, und das Event ist ungültiges SQLWahrscheinlich können Sie das Event mit mysqlbinlog extrahieren und sich die ver-stümmelten Daten anschauen:

UPDATE tbl SET col?????????????????

Versuchen Sie, den Anfang des nächsten Events zu finden und es auszugeben. Dazuaddieren Sie den Offset und die Länge. Vielleicht können Sie dieses Event einfachüberspringen.

Bytes wurden weggelassen, und/oder die Länge des Events ist falschIn diesem Fall bricht mysqlbinlog manchmal mit einem Fehler ab oder stürzt ab,weil es das Event nicht lesen und den Anfang des nächsten Events nicht findenkann.

Mehrere Events sind beschädigt oder wurden überschrieben, oder Offsets haben sich ver-schoben, und das nächste Event beginnt bei einem falschen Offset

Auch hier nützt Ihnen mysqlbinlog nicht viel.

Wenn die Beschädigung so schlimm ist, dass mysqlbinlog die Log-Events nicht lesenkann, müssen Sie auf Hex-Editing oder andere seltsame Techniken zurückgreifen, um dieGrenzen zwischen den Log-Events zu finden. Das ist normalerweise gar nicht so schwer,weil die Events durch deutlich erkennbare Markierungen getrennt werden.

Hier ist ein Beispiel. Wir wollen uns zuerst die Offsets eines Log-Events aus einem Bei-spiel-Log anschauen, das mysqlbinlog ausgegeben hat:

$ mysqlbinlog mysql-bin.000113 | egrep '^# at '# at 4# at 98

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


# at 185# at 277# at 369# at 447

Sie finden die Offsets in dem Log, indem Sie die Offsets mit der Ausgabe des folgendenstrings-Befehls vergleichen:

$ strings -n 2 -t d mysql-bin.0001131 binpC'G

25 5.0.38-Ubuntu_0ubuntu1.1-log99 C'G

146 std156 test161 create table test(a int)186 C'G233 std243 test248 insert into test(a) values(1)278 C'G325 std335 test340 insert into test(a) values(2)370 C'G417 std427 test432 drop table test448 D'G474 mysql-bin.000114

Es gibt ein gut erkennbares Muster, das es Ihnen erlauben sollte, die Anfänge der Eventszu finden. Beachten Sie, dass die Strings, die mit 'G enden, sich ein Byte hinter demAnfang des Log-Events befinden. Sie gehören zu dem Log-Event-Header, der eine festeLänge besitzt.

Der exakte Wert variiert von Server zu Server, Ihre Ergebnisse hängen also vom Server ab,dessen Log Sie untersuchen. Mit ein bisschen Herumsuchen sollten Sie in der Lage sein,das Muster in Ihrem Binärlog zu finden und den Offset des nächsten intakten Log-Eventszu ermitteln. Sie können dann versuchen, mit dem Argument --start-position für mysql-binlog hinter das schlechte Event bzw. die schlechten Events zu springen. Oder Sie benut-zen den Parameter MASTER_LOG_POS für CHANGE MASTER TO.

Nichttransaktionsfähige Tabellen verwendenWenn alles gut geht, funktioniert die anweisungsbasierte Replikation normalerweise gutmit nichttransaktionsfähigen Tabellen. Tritt jedoch ein Fehler bei der Aktualisierungeiner nichttransaktionsfähigen Tabelle auf (wird etwa eine Anweisung abgebrochen,bevor sie vollständig ausgeführt wurde), dann kommt es auf dem Master und dem Slavezu unterschiedlichen Daten.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Nehmen Sie z.B. an, Sie aktualisieren eine MyISAM-Tabelle mit 100 Zeilen. Wasgeschieht, wenn die Anweisung 50 der Zeilen aktualisiert und jemand sie dann abbricht?Die eine Hälfte der Zeilen wurde geändert, die andere hingegen nicht. Als Ergebnis mussdie Replikation aus dem Takt geraten, weil die Anweisung auf dem Slave erneut abge-spielt wird und alle 100 Zeilen ändert. (MySQL bemerkt dann, dass die Anweisung aufdem Master einen Fehler verursacht hat, auf dem Slave aber nicht, und stoppt die Repli-kation mit einer Fehlermeldung.)

Wenn Sie MyISAM-Tabellen einsetzen, dann führen Sie auf jeden Fall STOP SLAVE aus,bevor Sie den MySQL-Server stoppen, da ansonsten alle laufenden Abfragen abgebro-chen werden (einschließlich unvollständiger Aktualisierungsanweisungen). Transak-tionsfähige Storage-Engines haben dieses Problem nicht. Bei transaktionsfähigenTabellen wird eine fehlgeschlagene Aktualisierung auf dem Master zurückgenommenund nicht im Binärlog verzeichnet.

Transaktionsfähige und nichttransaktionsfähige Tabellen mischenWenn Sie eine transaktionsfähige Storage-Engine benutzen, dann schreibt MySQL dieAnweisungen, die Sie ausführen, erst dann in das Binärlog, wenn die Transaktionenbestätigt wurden. Das heißt, wenn eine Transaktion zurückgenommen wird, zeichnetMySQL die Anweisungen nicht auf, sie werden also auch nicht auf dem Slave abgespielt.

Falls Sie jedoch transaktionsfähige und nichttransaktionsfähige Tabellen mischen und es zueinem Rollback kommt, dann kann MySQL die Änderungen an den transaktionsfähigenTabellen zurücknehmen; die nichttransaktionsfähigen Tabellen dagegen werden dauerhaftverändert. Solange keine Fehler auftreten, indem etwa eine Aktualisierung auf halbemWege abgebrochen wird, stellt das kein Problem dar: Anstatt die Anweisungen nicht zu pro-tokollieren, schreibt MySQL zuerst die Anweisungen in sein Binärlog und anschließendeine ROLLBACK-Anweisung. In der Folge werden auf dem Slave die gleichen Anweisungenausgeführt, und alles ist gut. Das ist nicht ganz so effizient, weil der Slave auch etwas tunmuss, theoretisch jedoch bleibt der Slave weiterhin synchron mit dem Master.

So weit, so gut. Problematisch wird es, wenn es auf dem Slave ein Deadlock gibt, das aufdem Master nicht aufgetreten ist. Für die Tabellen, die eine transaktionsfähige Storage-Engine benutzen, gibt es auf dem Slave ein Rollback, für die nichttransaktionsfähigenTabellen ist das aber nicht möglich. Es kommt dazu, dass die Daten des Slaves sich vondenen des Masters unterscheiden.

Sie können dieses Problem nur verhindern, indem Sie das Mischen transaktionsfähigerund nichttransaktionsfähiger Tabellen vermeiden. Falls Sie das Problem bemerken, dannhaben Sie nur die Möglichkeit, den Fehler auf dem Slave zu überspringen und die betei-ligten Tabellen neu zu synchronisieren.

Im Prinzip sollte dieses Problem bei der zeilenbasierten Replikation nicht auftreten. Bei derzeilenbasierten Replikation werden Änderungen an den Zeilen aufgezeichnet, nicht an denSQL-Anweisungen. Wenn eine Anweisung Zeilen in einer MyISAM-Tabelle und einer

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


InnoDB-Tabelle ändert, es dann auf dem Master zu einem Deadlock kommt und dieInnoDB-Tabelle wieder zurückgeändert wird, werden die Änderungen an der MyISAM-Tabelle dennoch im Binärlog aufgezeichnet und auf dem Slave abgespielt. Wir haben einfa-che Fälle getestet und festgestellt, dass dies korrekt funktioniert; allerdings hatten wir zudem Zeitpunkt, als dieses Buch entstand, noch nicht genügend Erfahrungen mit der zeilen-basierten Replikation, um sicher sagen zu können, ob Probleme komplett vermieden wer-den, die durch das Mischen transaktionsfähiger und nichttransaktionsfähiger Tabellenauftreten können.

Nichtdeterministische AnweisungenJede Anweisung, die Daten auf nichtdeterministische Weise ändert, kann dafür sorgen,dass die Daten eines Slaves sich von denen seines Masters unterscheiden. Zum Beispielhängt ein UPDATE mit einem LIMIT von der Reihenfolge ab, in der die Anweisung die Zeilenin der Tabelle findet. Solange die Reihenfolge auf dem Master und dem Slave nicht garan-tiert gleich ist – indem z.B. die Zeilen nach dem Primärschlüssel sortiert sind –, könntedie Anweisung unterschiedliche Zeilen auf diesen beiden Servern ändern. Solche Prob-leme sind unter Umständen subtil und schwer zu bemerken, weshalb manchmal dieRegel gilt, dass LIMIT nie mit einer Anweisung benutzt werden darf, die Daten ändert.

Achten Sie außerdem auf Anweisungen, die INFORMATION_SCHEMA-Tabellen einbeziehen.Diese können sich zwischen Master und Slave unterscheiden, so dass auch die Ergebnisseunterschiedlich sind. Denken Sie schließlich noch daran, dass die meisten Servervariab-len, wie etwa @@server_id und @@hostname in Versionen vor MySQL 5.1 nicht korrekt rep-liziert werden.

Die zeilenbasierte Replikation unterliegt nicht diesen Beschränkungen.

Unterschiedliche Storage-Engines auf Master und SlaveWie wir in diesem Kapitel schon angemerkt haben, ist es oft praktisch, wenn man aufeinem Slave andere Storage-Engines benutzt. Unter gewissen Umständen erzeugt aller-dings die anweisungsbasierte Replikation auf einem Slave mit anderen Storage-Enginesunterschiedliche Ergebnisse. Beispielsweise verursachen nichtdeterministische Anwei-sungen (wie die im vorherigen Abschnitt erwähnten) mit größerer WahrscheinlichkeitProbleme, wenn sich die Storage-Engines auf dem Slave unterscheiden.

Falls Sie feststellen, dass die Daten Ihres Slaves in bestimmten Tabellen nicht mit denje-nigen Ihres Masters übereinstimmen, dann sollten Sie die Storage-Engines untersuchen,die auf beiden Servern benutzt werden, sowie die Abfragen, die diese Tabellen aktualisie-ren.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Datenänderungen auf dem SlaveDie anweisungsbasierte Replikation ist darauf angewiesen, dass der Slave die gleichenDaten enthält wie der Master. Sie dürfen daher Änderungen auf dem Slave weder erlau-ben noch vornehmen (mit der Konfigurationsvariablen read_only können Sie dieses Zieldurchsetzen). Schauen Sie sich die folgende Anweisung an:

mysql> INSERT INTO table1 SELECT * FROM table2;

Wenn table2 auf dem Slave andere Daten enthält, bekommt table1 ebenfalls unter-schiedliche Daten. Mit anderen Worten: Datenunterschiede pflegen sich von Tabelle zuTabelle auszubreiten. Das passiert mit allen Arten von Abfragen, nicht nur mit INSERT ...SELECT-Abfragen. Es gibt zwei mögliche Folgen: Sie erhalten einen Fehler wie eine dop-pelte Indexverletzung, oder Sie bekommen überhaupt keinen Fehler. Seien Sie froh,wenn Sie einen Fehler erhalten, weil Sie damit wenigstens alarmiert werden, dass IhreDaten auf dem Slave nicht gleich sind. Bleiben unterschiedliche Daten unentdeckt, kön-nen sie insgeheim alle möglichen Schäden anrichten.

Die einzige Lösung für dieses Problem besteht darin, die Daten neu vom Master zu syn-chronisieren.

Nichteindeutige Server-IDsDies gehört zu den schwerer fassbaren Problemen, die bei der Replikation auftreten kön-nen. Falls Sie versehentlich zwei Slaves mit derselben Server-ID konfigurieren, scheinen sieauf den ersten Blick gut zu funktionieren. Schauen Sie sich jedoch deren Fehler-Logs anoder beobachten Sie den Master mit innotop, werden Ihnen eigenartige Dinge auffallen.

Auf dem Master sehen Sie, dass immer nur einer der beiden Slaves verbunden ist. (Nor-malerweise besteht zu allen Slaves eine Verbindung, so dass sie replizieren können.) Aufdem Slave finden Sie im Fehler-Log viele Fehlermeldungen über das Trennen und erneuteAufbauen von Verbindungen, aber keinen Hinweis auf eine fehlkonfigurierte Server-ID.

Je nach der verwendeten MySQL-Version replizieren die Slaves korrekt, aber langsam.Vielleicht replizieren sie aber auch gar nicht korrekt, sondern verpassen Binärlog-Eventsoder wiederholen sie fälschlicherweise, wodurch Fehler mit duplizierten Schlüsseln (oderDatenverfälschungen) auftreten. Es kann auch zu Abstürzen oder beschädigten Datenauf dem Master selbst kommen, weil die Slaves, die gegeneinander kämpfen, eineerhöhte Last verursachen. Und wenn die Slaves einander sehr stark bekämpfen, könnendie Fehler-Logs in kurzer Zeit sehr stark anwachsen.

Um diese Probleme zu vermeiden, kommen Sie nicht umhin, beim Einrichten der Slavessehr sorgfältig vorzugehen. Möglicherweise hilft es Ihnen, eine Liste mit Slave-zu-Server-ID-Zuordnungen anzulegen, damit Sie nicht den Überblick darüber verlieren, welche IDzu einem Slave gehört.12 Falls sich Ihre Slaves alle in einem Teilnetz Ihres Netzwerks

12 Vielleicht wollen Sie sie in einer Datenbanktabelle speichern? Wir scherzen … aber nicht nur: Sie können inder ID-Spalte einen eindeutigen Index hinzufügen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


befinden, können Sie eindeutige IDs wählen, indem Sie nur das letzte Oktett der IP-Adressen der einzelnen Maschinen nutzen.

Undefinierte Server-IDsFalls Sie die Server-ID nicht in der my.cnf-Datei definieren, scheint MySQL die Replika-tion mit CHANGE MASTER TO einzurichten, erlaubt Ihnen aber nicht, den Slave zu starten:

mysql> START SLAVE;ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO

Dieser Fehler ist besonders verwirrend, weil Sie gerade CHANGE MASTER TO benutzt und IhreEinstellungen mit SHOW SLAVE STATUS verifiziert haben. Sie erhalten möglicherweise einenWert von SELECT @@server_id, aber das ist nur ein Vorgabewert. Sie müssen den Wertexplizit setzen.

Abhängigkeiten von nichtreplizierten DatenHaben Sie auf dem Master Datenbanken oder Tabellen, die nicht auf dem Slave existie-ren, dann ist es ziemlich einfach, die Replikation absichtlich zu unterbrechen. NehmenSie an, dass es eine scratch-Datenbank auf dem Master gibt, die auf dem Slave nicht vor-liegt. Beziehen sich irgendwelche Datenaktualisierungen auf dem Master auf eine Tabellein dieser Datenbank, dann wird die Replikation abgebrochen, wenn der Slave versucht,die Aktualisierungen abzuspielen.

Man kann dieses Problem nicht umgehen. Sie können höchstens auf dem Master dasAnlegen von Tabellen vermeiden, die auf dem Slave nicht existieren.

Wie wird eine solche Tabelle erzeugt? Es gibt viele Möglichkeiten, von denen sich einigeschwerer vermeiden lassen als andere. Nehmen Sie z.B. an, dass Sie eine scratch-Daten-bank auf dem Slave erzeugt haben, die auf dem Master nicht vorhanden war, und dannaus irgendeinem Grund Master und Slave vertauscht haben. Vielleicht haben Sie in die-sem Fall vergessen, die scratch-Datenbank und ihre Berechtigungen zu entfernen. Jetztkönnte jemand eine Verbindung zu dem neuen Master herstellen und eine Abfrage in die-ser Datenbank ausführen, oder ein regelmäßig ablaufender Job entdeckt die Tabellenund führt in ihnen jeweils OPTIMIZE TABLE aus.

Daran müssen Sie unter anderem denken, wenn Sie einen Slave zum Master befördernoder wenn Sie entscheiden, wie die Slaves konfiguriert werden sollen. Alles, was dieSlaves anders macht als die Master oder umgekehrt, könnte künftig zu einem Problemwerden.

Die zeilenbasierte Replikation sollte einige dieser Probleme lösen, allerdings ist es nochzu früh, um sich sicher zu sein.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Fehlende temporäre TabellenFür manche Einsatzzwecke sind temporäre Tabellen ganz praktisch, allerdings sind sieleider inkompatibel zur anweisungsbasierten Replikation. Wenn ein Slave abstürzt oderwenn Sie ihn herunterfahren, dann verschwinden alle temporären Tabellen, die derSlave-Thread benutzt. Nach einem Neustart des Slaves schlagen alle weiteren Anweisun-gen fehl, die sich auf die fehlenden temporären Tabellen beziehen.

Es gibt keine sichere Methode, um temporäre Tabellen auf dem Master zusammen mitanweisungsbasierter Replikation zu benutzen. Viele Leute mögen die temporären Tabel-len, so dass sie vermutlich schwer davon zu überzeugen sind, aber es stimmt. Egal, wiekurz sie existieren, temporäre Tabellen machen es potenziell unmöglich, Slaves zu stop-pen und zu starten und sie nach Abstürzen wiederherzustellen. Das gilt sogar dann, wennSie sie nur innerhalb einer einzigen Transaktion benutzen. (Es ist etwas weniger proble-matisch, temporäre Tabellen auf einem Slave einzusetzen, wo sie sehr bequem sein kön-nen; ist der Slave aber selbst ein Master, dann existiert das Problem weiterhin.)

Falls die Replikation stoppt, weil der Slave eine temporäre Tabelle nach einem Neustartnicht finden kann, gibt es wirklich nur wenig, was Sie tun können. Überspringen Sie dieauftretenden Fehler, oder legen Sie manuell eine Tabelle mit dem gleichen Namen undder gleichen Struktur wie die verschwundene Tabelle an. Wie auch immer Sie vorgehen,Ihre Daten werden auf dem Slave wahrscheinlich anders aussehen, wenn Schreibabfragensich auf die temporäre Tabelle beziehen.

Es ist nicht so schwer, wie es scheint, temporäre Tabellen zu eliminieren. Die beidennützlichsten Eigenschaften einer temporären Tabelle sind folgende:

• Sie sind nur für die Verbindung sichtbar, die sie erzeugt hat, kommen also nicht dentemporären Tabellen anderer Verbindungen in die Quere, die denselben Namen tra-gen.

• Sie verschwinden, wenn die Verbindung geschlossen wird. Sie müssen sie also nichtexplizit entfernen.

Sie können diese Eigenschaften leicht emulieren, indem Sie eine Datenbank exklusiv fürpseudotemporäre Tabellen reservieren, wo Sie stattdessen permanente Tabellen anlegen.Sie müssen nur eindeutige Namen für sie wählen. Zum Glück geht das ganz leicht: HängenSie einfach die Verbindungs-ID an den Tabellennamen an. Wo Sie z.B. CREATE TEMPORARYTABLE top_users(...) ausgeführt haben, führen Sie nun CREATE TABLE temp.top_users_1234(...) aus, wobei 1234 der Wert ist, der von CONNECTION_ID( ) zurückgeliefert wird.Nachdem Ihre Anwendung mit der pseudotemporären Tabelle fertig ist, können Sie sie ent-weder wegwerfen oder sie von einem Aufräumprozess entfernen lassen. Da die Verbin-dungs-ID im Namen steht, kann man leicht feststellen, welche Tabellen nicht mehr inBenutzung sind – Sie erhalten eine Liste der aktiven Verbindungen mit SHOW PROCESSLIST undmüssen sie nur mit den Verbindungs-IDs in den Tabellennamen vergleichen.13

13 mk-find – noch ein weiteres Werkzeug in Maatkit – kann pseudotemporäre Tabellen leicht mit den Optionen--pid und --sid entfernen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Die Verwendung von echten Tabellen anstelle von temporären Tabellen hat noch andereVorteile. Zum Beispiel lassen sich damit leichter Fehler in Ihren Anwendungen aufspü-ren, weil Sie die Daten sehen können, die die Anwendungen von einer anderen Verbin-dung aus manipulieren. Mit einer temporären Tabelle wäre das nicht so einfach möglich.

Echte Tabellen bringen jedoch einen gewissen Overhead mit, den Sie bei temporärenTabellen nicht haben: Es geht langsamer, sie zu erzeugen, weil die .frm-Dateien, die mitdiesen Tabellen verknüpft sind, auf die Festplatte synchronisiert werden müssen. Sie kön-nen die sync_frm-Option deaktivieren, um das zu beschleunigen, aber das ist gefährlicher.

Falls Sie temporäre Tabellen einsetzen, müssen Sie sicherstellen, dass die StatusvariableSlave_open_temp_tables 0 ist, bevor sie einen Slave herunterfahren. Wenn sie nicht 0 ist,bekommen Sie wahrscheinlich Probleme damit, den Slave neu zu starten. Das richtigeVorgehen besteht darin, STOP SLAVE auszuführen, die Variable zu untersuchen und erstdann den Slave herunterzufahren. Wenn Sie die Variable untersuchen, bevor Sie dieSlave-Prozesse stoppen, riskieren Sie eine Race-Condition.

Es werden nicht alle Updates repliziertFalls Sie SET SQL_LOG_BIN=0 missbrauchen oder die Replikationsfilterregeln nicht verste-hen, ignoriert Ihr Slave möglicherweise Aktualisierungen, die auf dem Master stattgefun-den haben. Manchmal wollen Sie das zu Archivierungszwecken, normalerweise jedochgeschieht das versehentlich und hat schlimme Folgen.

Nehmen Sie z.B. an, dass Sie eine replicate_do_db-Regel haben, um nur die sakila-Datenbank auf einen Ihrer Slaves zu replizieren. Wenn Sie die folgenden Befehle auf demMaster ausführen, werden die Daten des Slaves anders als die Daten auf dem Master:

mysql> USE test;mysql> UPDATE sakila.actor ...

Andere Arten von Anweisungen können aufgrund von nichtreplizierten Abhängigkeitensogar dafür sorgen, dass eine Replikation mit einem Fehler fehlschlägt.

Lock-Contention aufgrund von sperrenden InnoDB-SelectsDie InnoDB-SELECT-Anweisungen sind normalerweise nichtsperrend, besorgen sich aberin bestimmten Fällen Sperren. Speziell INSERT ... SELECT sperrt standardmäßig alle Zei-len, aus denen es in der Quelltabelle liest. MySQL braucht die Sperren um sicherzustel-len, dass die Anweisungen beim Ausführen auf dem Slave das gleiche Ergebnis erzeugen.Im Prinzip serialisieren die Sperren die Anweisung auf dem Master, was der Art undWeise entspricht, wie der Slave sie ausführt.

Ihnen könnten aufgrund dieses Designs Lock-Contention, Blockaden und Timeoutsinfolge des Wartens auf Sperren begegnen. Um diese Probleme zu mildern, sollte maneine Transaktion nicht länger offen halten als nötig, damit die Sperren weniger Blocka-den verursachen. Sie können die Sperren freigeben, indem Sie die Transaktion so baldwie möglich auf dem Master bestätigen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Es ist außerdem hilfreich, wenn die Anweisungen kurz gehalten werden, indem mangroße Anweisungen in kleinere unterteilt. Das ist sehr effektiv, um Lock-Contention zureduzieren. Es lohnt sich meist, auch wenn es nicht leicht durchzuführen ist.

Andere Lösungen bestehen darin, INSERT ... SELECT-Anweisungen durch eine Kombina-tion aus SELECT INTO OUTFILE, gefolgt von LOAD DATA INFILE auf dem Master zu ersetzen.Das geht schnell und erfordert keine Sperren. Zugegebenermaßen ist das ein Hack, deraber dennoch manchmal hilft. Die größten Probleme sind die Wahl eines eindeutigenNamens für die Ausgabedatei, die noch nicht existieren darf, und das Aufräumen derAusgabedatei, wenn Sie damit fertig sind. Sie können die CONNECTION_ID( )-Technik ein-setzen, die wir in »Fehlende temporäre Tabellen« auf Seite 429 besprochen haben, umsicherzustellen, dass der Dateiname eindeutig ist, und Sie können einen regelmäßig aus-geführten Job benutzen (crontab unter Unix, GEPLANTE TASKS unter Windows), umungenutzte Ausgabedateien aufzuräumen, nachdem die Verbindungen, die sie erzeugthaben, mit ihnen fertig sind.

Sie sind vielleicht versucht, die Sperren zu deaktivieren, anstatt eine der genanntenLösungen einzusetzen. Es gibt zwar eine Methode, um das zu erreichen, es ist aber meistkeine gute Idee, weil dadurch der Slave stillschweigend hinter den Master zurückfallenkönnte. Außerdem wird dadurch das Binärlog nutzlos für die Wiederherstellung einesServers. Falls Sie jedoch beschließen, dass die Vorteile die Risiken aufwiegen, wird dieKonfigurationsänderung folgendermaßen erreicht:

innodb_locks_unsafe_for_binlog = 1

Dadurch können die Ergebnisse einer Anweisung von Daten abhängen, die sie nichtsperrt. Wenn eine zweite Anweisung die Daten modifiziert und sie vor der ersten Anwei-sung bestätigt, dann kann es passieren, dass die beiden Anweisungen beim Abspielen desBinärlogs nicht dieselben Ergebnisse erzeugen. Das gilt sowohl für die Replikation alsauch für die punktgenaue Wiederherstellung.

Um einmal zu sehen, wie durch das Sperren von Leseoperationen Chaos vermieden wird,stellen Sie sich vor, dass Sie zwei Tabellen haben: eine ohne Zeilen und eine, deren ein-zige Zeile den Wert 99 enthält. Die Daten werden durch zwei Transaktionen aktualisiert.Transaktion 1 fügt den Inhalt der zweiten Tabelle in die erste Tabelle ein, und Trans-aktion 2 aktualisiert die zweite (Quell-)Tabelle, wie in Abbildung 8-16 gezeigt ist.

Schritt 2 in dieser Folge von Ereignissen ist sehr wichtig. Darin versucht Transaktion 2,die Quelltabelle zu aktualisieren, was es nötig macht, eine exklusive (Schreib-)Sperre aufdie Zeilen zu legen, die aktualisiert werden sollen. Eine exklusive Sperre ist inkompatibelzu jeder anderen Sperre, einschließlich des Shared Lock, das Transaktion 1 auf dieseZeile gelegt hat, so dass Transaktion 2 gezwungen ist zu warten, bis Transaktion 1 bestä-tigt wird. Die Transaktionen werden im Binärlog in der Reihenfolge serialisiert, in der siebestätigt werden, so dass sich beim erneuten Abspielen dieser Transaktionen in derBinärlog-(Commit-)Reihenfolge die gleichen Ergebnisse erzielen lassen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Falls andererseits Transaktion 1 kein Shared Lock auf die Zeilen legt, die es für das INSERTliest, gibt es keine solche Garantie. Betrachten Sie Abbildung 8-17, in der eine möglicheFolge von Ereignissen ohne das Lock zu sehen ist.

Ohne Sperren werden die Transaktionen in einer Reihenfolge in das Binärlog geschrie-ben, die andere Ergebnisse erzeugt, wenn dieses Log erneut abgespielt wird, wie Sie inder Abbildung erkennen. MySQL zeichnet Transaktion 2 zuerst auf, so dass die Ergeb-nisse von Transaktion 1 auf dem Slave beeinflusst werden. Auf dem Master ist das nichtpassiert. In der Folge enthält der Slave andere Daten als der Master.

Wir raten Ihnen dringend, in den meisten Fällen die Konfigurationsvariable innodb_locks_unsafe_for_binlog auf 0 gesetzt zu lassen.

In einer Master-Master-Replikation auf beide Master schreibenAuf beide Master zu schreiben, ist im Allgemeinen keine gute Idee. Falls Sie versuchen,sicher auf beide Master gleichzeitig zu schreiben, dann gibt es für einige der ProblemeLösungen, für andere jedoch nicht.

In MySQL 5.0 gibt es zwei Server-Konfigurationsvariablen, mit denen man dem Problemder widersprüchlichen AUTO_INCREMENT-Primärschlüssel begegnen kann. Diese Variablen

Abbildung 8-16: Zwei Transaktionen aktualisieren Daten; mittels gemeinsam genutzter Sperren (Shared Lock) wird die Aktualisierung serialisiert.

Tbl1 Tbl2 Binlog

Ausgangszustand0

3 Txn 1 wird bestätigtund gibt Sperren frei

4 Txn 2 fährt fortund wird bestätigt

Txn 1

Txn 2

99 10099

SET = 100

Txn 19999

2 Txn 2UPDATEder Blöcke mit einemexklusiven Lock

9999

SET = 100

1 Txn 1INSERT/SELECTmit einem Shared Lock

9999

99

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


sind auto_increment_increment und auto_increment_offset. Mit ihnen können Sie dieZahlen, die die Server generieren, »staffeln«, so dass sie sich verschachteln und nicht mit-einander kollidieren.

Das löst jedoch nicht alle Probleme, die mit zwei schreibbaren Mastern auftreten. Es löstnur das Autoinkrement-Problem, das wahrscheinlich nur einen kleinen Teil der wider-sprüchlichen Schreiboperationen ausmacht, mit denen Sie es zu tun bekommen könnten.Um genau zu sein, werden dadurch mehrere neue Probleme eingeführt:

• Dieses Verfahren erschwert es, Server in der Replikationstopologie zu verschieben.

• Es verschwendet Schlüsselplatz, indem potenziell Lücken zwischen den Zahlen ein-geführt werden.

• Es hilft nur, wenn alle Ihre Tabellen AUTO_INCREMENT-Primärschlüssel besitzen, unddabei ist es nicht unbedingt eine gute Idee, AUTO_INCREMENT-Primärschlüssel allge-mein einzusetzen.

Sie können eigene, nicht widersprüchliche Primärschlüsselwerte generieren. Eine Mög-lichkeit wäre, einen mehrspaltigen Primärschlüssel zu erzeugen und die Server-ID für dieerste Spalte zu benutzen. Das funktioniert gut, vergrößert allerdings die Primärschlüssel,was eine schlimme Wirkung auf die Sekundärschlüssel in InnoDB hat.

Abbildung 8-17: Zwei Transaktionen aktualisieren Daten, allerdings ohne dass ein Shared Lock die Aktualisierungen serialisiert.

2

Tbl1 Tbl2 Binlog

3 Txn 1 wird bestätigt Txn 2

Txn 1

Txn 2

10099

2 Txn 2 machtweiter und wird bestätigt 99

SET = 100

1 Txn 1INSERT/SELECTohne Locking

9999

99 100

Später,auf dem Slave...

1 Txn 2UPDATE

99 100SET = 100

Txn 1INSERT/SELECT

100100

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Es ist auch möglich, einen einspaltigen Primärschlüssel einzusetzen und die »hohen Bits«des Integers für die Server-ID zu nehmen. Das erreichen Sie durch eine einfache Linksver-schiebung (oder Multiplikation) und Addition. Falls Sie z.B. die 8 höchstwertigen Bitseiner vorzeichenlosen BIGINT-(64-Bit-)Spalte benutzen, um die Server-ID aufzunehmen,können Sie den Wert 11 auf Server 15 folgendermaßen einfügen:

mysql> INSERT INTO test(pk_col, ...) VALUES( (15 << 56) + 11, ...);

Wenn Sie das Ergebnis in die Basis 2 konvertieren und es auf 64 Bit Länge auffüllen, istder Effekt besser zu erkennen:

mysql> SELECT LPAD(CONV(pk_col, 10, 2), 64, '0') FROM test;+------------------------------------------------------------------+| LPAD(CONV(pk_col, 10, 2), 64, '0') |+------------------------------------------------------------------+| 0000111100000000000000000000000000000000000000000000000000001011 |+------------------------------------------------------------------+

Das Problem bei dieser Methode besteht darin, dass Sie eine externe Möglichkeit benöti-gen, um die Schlüsselwerte zu generieren, weil AUTO_INCREMENT das nicht für Sie erledigenkann. Benutzen Sie nicht @@server_id anstelle der Konstante 15 in dem INSERT, da Sieansonsten ein anderes Ergebnis auf dem Slave erhalten.

Sie können sich auch mit einer Funktion wie MD5( ) oder UUID( ) für pseudozufälligeWerte entscheiden, allerdings sind diese unter Umständen schlecht für die Performance –sie sind groß, und sie sind prinzipiell zufällig, was speziell für InnoDB nicht so gut ist.(Benutzen Sie UUID( ) nur dann, wenn Sie die Werte in der Anwendung generieren, weilUUID( ) mit der anweisungsbasierten Replikation nicht korrekt repliziert wird.)

Es ist ein schwieriges Problem, und wir empfehlen im Normalfall, die Anwendung soumzugestalten, dass man nur noch einen schreibbaren Master hat.

Übermäßiger Rückstand bei der ReplikationEin Rückstand bei der Replikation ist ein häufig auftretendes Problem. Nichtsdestotrotzist es keine schlechte Idee, die Anwendungen so zu entwerfen, dass sie einen gewissenRückstand der Slaves tolerieren. Wenn das System mit verzögerten Slaves nicht funk-tionieren kann, dann ist die Replikation vermutlich nicht die richtige Architektur für IhreAnwendung. Sie können jedoch einige Schritte unternehmen, um den Slaves zu helfen,mit dem Master Schritt zu halten.

Die Single-Thread-Natur der MySQL-Replikation bedeutet, dass sie auf dem Slave relativineffizient ist. Selbst ein schneller Slave mit vielen Festplatten, CPUs und Speicher kannganz leicht hinter einem Master zurückfallen, weil der eine Thread des Slaves üblicher-weise nur eine CPU und eine Festplatte effizient nutzt. Um genau zu sein, muss jederSlave typischerweise mindestens so leistungsfähig sein wie der Master.

Auch Sperren auf dem Slave stellen ein Problem dar. Andere Abfragen, die auf einemSlave laufen, könnten Sperren setzen, die den Replikations-Thread blockieren. Da die

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Replikation nur mit einem Thread erfolgt, könnte der Replikations-Thread keine weitereArbeit verrichten, während er wartet.

Meist fällt die Replikation auf zwei Arten zurück: mit Verzögerungspitzen, die in derFolge aufgeholt werden, oder indem der Slave ständig hinterherbummelt. Die erste Artwird üblicherweise von Abfragen verursacht, die schon lange laufen; die zweite Formdagegen kann sogar dann auftauchen, wenn es keine langen Abfragen gibt.

Leider gibt es momentan nur eine Möglichkeit, um festzustellen, wie dicht der Slave anseine Kapazitätsgrenzen kommt: indem man empirische Beweise untersucht. Wenn IhreLast immer absolut gleichförmig wäre, würden Ihre Slaves bei 99 % Kapazität fastgenauso gut funktionieren wie bei 10 % Kapazität. Wenn sie 100 % Kapazität erreichen,würden sie abrupt zurückfallen. In der Realität ist die Last kaum so stetig. Wenn also einSlave fast seine volle Schreibkapazität erreicht hat, würden Sie wahrscheinlich währendLastspitzen eine erhöhte Replikationsverzögerung bemerken.

Das ist ein Warnsignal! Es bedeutet vermutlich, dass Sie gefährlich nahe daran sind, IhreSlaves überzubeanspruchen, so dass sie auch zwischen den eigentlichen Lastspitzen nichtaufholen können. Ein seltsamer Test dafür, wie dicht Sie an der Grenze sind, bestehtdarin den SQL-Thread eines Slaves absichtlich für eine Weile zu stoppen, ihn dann neuzu starten und festzustellen, wie lange es dauert, bis er wieder aufgeholt hat.

Die Patches, die Google veröffentlicht hat (siehe »Synchrone MySQL-Replikation« aufSeite 492), enthalten ebenfalls einen SHOW USER STATISTICS-Befehl, der die Busy_time desReplikationsbenutzers zeigen kann. Dabei handelt es sich um den prozentualen Zeitan-teil, den der Slave-Thread mit dem Verarbeiten von Abfragen verbracht hat – eine weiteregute Methode, um die »Kopffreiheit« des Slave-SQL-Threads zu ermitteln.

Wenn Sie merken, dass Slaves nicht hinterherkommen, dann ist es am besten, die Abfra-gen auf einem Slave zu protokollieren und mit einem entsprechenden Analysewerkzeugfestzustellen, was da so langsam ist. Verlassen Sie sich bei dieser Frage nicht auf IhrenInstinkt, und gehen Sie nicht davon aus, wie die Abfragen auf dem Master funktionieren,da Slaves und Master ganz unterschiedliche Leistungsprofile aufweisen. Für diese Ana-lyse aktivieren Sie am besten das Slow-Query-Log auf dem Slave. Das normale MySQL-Slow-Query-Log zeichnet nicht die langsamen Abfragen auf, die der Slave-Thread aus-führt, so dass Sie beim Replizieren nicht sehen können, welche Abfragen langsam sind.Der Mikrosekunden-Patch löst dieses Problem. Mehr über das Slow-Query-Log und die-sen Patch erfahren Sie in »MySQL-Profiling« auf Seite 68.

Es gibt nicht viel, was Sie auf einem Slave einstellen oder verändern können, der nichtSchritt hält, abgesehen vom Erwerb schnellerer Festplatten und CPUs. Meist soll man aufdem Slave Dinge deaktivieren, die zusätzliche Arbeit verursachen, und auf diese Weiseversuchen, die Last auf dem Slave zu verringern. Man könnte z.B. InnoDB so konfigurie-ren, dass es Änderungen weniger oft auf die Festplatte überträgt, damit Transaktionenschneller bestätigt werden. Das erreichen Sie, indem Sie innodb_flush_log_at_trx_commitauf 2 setzen. Sie können auch das Binär-Logging auf dem Slave deaktivieren,innodb_locks_unsafe_for_binlog auf 1 und delay_key_write auf ALL für MyISAM setzen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Diese Einstellungen tauschen allerdings Sicherheit gegen Geschwindigkeit ein. Wenn Sieeinen Slave zum Master befördern, dann denken Sie daran, diese Einstellungen aufsichere Werte zurückzusetzen.

Verdoppeln Sie den teuren Teil des Schreibens nicht

Der Umbau Ihrer Anwendung und/oder die Optimierung Ihrer Abfragen sind oft die bes-ten Methoden, um Slaves auf die Sprünge zu helfen. Versuchen Sie, die Arbeitsmenge zureduzieren, die durch Ihr System dupliziert werden muss. Alle Schreiboperationen, dieauf dem Master teuer sind, werden auf allen Slaves noch einmal abgespielt. Falls Sie dieArbeit vom Master auf einen Slave delegieren können, muss nur einer der Slaves dieArbeit erledigen. Sie können dann die Schreibergebnisse wieder auf den Master schieben,z.B. mit LOAD DATA INFILE.

Betrachten wir ein Beispiel. Nehmen Sie an, Sie haben eine sehr große Tabelle, die Sie füreine häufig vorkommende Verarbeitung in einer kleineren Tabelle zusammenfassen:

mysql> REPLACE INTO main_db.summary_table (col1, col2, ...)-> SELECT col1, sum(col2, ...)-> FROM main_db.enormous_table GROUP BY col1;

Falls Sie diese Operation auf dem Master durchführen, muss jeder Slave die riesige GROUPBY-Abfrage wiederholen. Kommt das oft vor, werden die Slaves irgendwann nicht mehrmithalten können. Es hilft wahrscheinlich, das Zahlenschieben auf einen der Slaves abzu-wälzen. Auf dem Slave, vielleicht in einer speziellen Datenbank, die extra reserviertwurde, um Konflikte mit den Daten zu vermeiden, die vom Master repliziert wurden,können Sie Folgendes ausführen:

mysql> REPLACE INTO summary_db.summary_table (col1, col2, ...)-> SELECT col1, sum(col2, ...)-> FROM main_db.enormous_table GROUP BY col1;

Jetzt können Sie SELECT INTO OUTFILE, gefolgt von LOAD DATA INFILE, auf dem Master aus-führen, um die Ergebnisse zurück auf den Master zu verschieben. Voilà – die doppelteArbeit wurde auf ein einfaches LOAD DATA INFILE reduziert. Bei N Slaves haben Sie geradeN – 1 riesige GROUP BY-Abfragen gespart.

Das Problem bei dieser Strategie ist der Umgang mit alten Daten. Manchmal ist es schwer,konsistente Ergebnisse zu erhalten, indem man auf dem Slave liest und auf den Masterschreibt (ein Problem, mit dem wir uns im nächsten Kapitel befassen). Wenn es schwer ist,das Lesen auf dem Slave durchzuführen, können Sie die Abfrage vereinfachen und IhrenSlaves eine Menge Arbeit ersparen. Wenn Sie die REPLACE- und SELECT-Teile der Abfragetrennen, können Sie die Ergebnisse in Ihre Anwendung holen und sie dann wieder auf denMaster einfügen. Führen Sie zuerst die folgende Abfrage auf dem Master durch:

mysql> SELECT col1, sum(col2, ...) FROM main_db.enormous_table GROUP BY col1;

Sie fügen dann die Ergebnisse wieder in die Summary-Tabelle ein, indem Sie die folgendeAbfrage für jede Zeile in der Ergebnismenge wiederholen:

mysql> REPLACE INTO main_db.summary_table (col1, col2, ...) VALUES (?, ?, ...);

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Auch hier haben Sie den Slaves den großen GROUP BY-Anteil der Abfrage erspart; das Tren-nen des SELECT vom REPLACE bedeutet, dass der SELECT-Teil der Abfrage nicht auf jedemSlave wieder abgespielt wird.

Diese allgemeine Strategie – den Slaves den teuren Teil einer Schreiboperation zu erspa-ren – kann in vielen Fällen helfen, in denen Sie Abfragen haben, deren Ergebnisse auf-wendig zu berechnen, aber nach der Berechnung einfach zu handhaben sind.

Schreiboperationen außerhalb der Replikation parallel durchführen

Eine andere Taktik, um übermäßige Verzögerungen bei den Slaves zu vermeiden, siehtvor, die Replikation ganz und gar zu umgehen. Alle Schreiboperationen, die Sie auf demMaster durchführen, müssen auf dem Slave serialisiert werden, so dass es sinnvoll ist,sich die »serialisierten Schreiboperationen« als knappe Ressource vorzustellen. Müssenalle Ihre Schreibvorgänge vom Master zum Slave laufen? Wie können Sie die beschränkteserialisierte Schreibkapazität Ihres Slaves für solche Schreiboperationen aufsparen, diewirklich mittels Replikation erledigt werden müssen?

Wenn Sie es in diesem Licht betrachten, können Sie vielleicht die Prioritäten für dieSchreiboperationen neu setzen. Falls Sie im Speziellen Schreiboperationen finden, diesich leicht außerhalb der Replikation durchführen lassen, können Sie Schreiboperationenparallelisieren, die ansonsten wertvolle Schreibkapazitäten auf dem Slave beanspruchenwürden.

Ein großartiges Beispiel ist die Datenarchivierung, die wir weiter vorn in diesem Kapiteldiskutiert haben. OLTP-Archivierungsabfragen sind oft einfache Einzeilenoperationen.Wenn Sie einfach nur nicht benötigte Zeilen von einer Tabelle in eine andere verschie-ben, besteht eigentlich kein Grund, diese Schreiboperationen auf den Slaves zu replizie-ren. Stattdessen können Sie das Binär-Logging für die Archivierungsanweisungendeaktivieren und dann separate, aber identische Prozesse auf den Mastern und den Slavesausführen.

Es klingt vielleicht verrückt, die Daten selbst auf einen anderen Server zu kopieren,anstatt das durch die Replikation erledigen zu lassen, das kann aber tatsächlich für man-che Anwendungen sinnvoll sein. Das gilt vor allem dann, wenn eine Anwendung dieeinzige Aktualisierungsquelle für eine bestimmte Gruppe von Tabellen darstellt. Fla-schenhälse in der Replikation sammlen sich oft um eine kleine Gruppe von Tabellen, undfalls Sie diese Tabellen außerhalb der Replikation verarbeiten können, haben Sie dieMöglichkeit, diese deutlich zu beschleunigen.

Den Cache für den Slave-Thread vorbereiten

Bei einer entsprechenden Last könnten Sie von einer Parallelisierung der Ein-/Ausgabenauf den Slaves profitieren, indem Sie die Daten bereits vorab in den Speicher holen. DieseTechnik ist nicht sehr verbreitet, wir kennen aber große Anwendungen, die sie bereitserfolgreich einsetzen.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Dabei wird ein Programm benutzt, das bereits kurz vor dem Slave-SQL-Thread in denRelay-Logs liest und die Abfragen als SELECT-Anweisungen ausführt. Dadurch wird derServer veranlasst, einige der Daten von der Festplatte in den Speicher zu holen. Wenndann der Slave-SQL-Thread die Anweisung aus dem Relay-Log ausführt, muss er nichtwarten, bis die Daten von der Festplatte geholt wurden. Im Prinzip parallelisiert dasSELECT die Ein-/Ausgabe, die der Slave-SQL-Thread normalerweise seriell ausführenmuss. Während eine Anweisung Daten ändert, werden die Daten der nächsten Anwei-sung von der Festplatte in den Speicher geholt.

Wie weit das Programm vor dem Slave-SQL-Thread bleiben soll, ist ganz unterschied-lich. Sie können einige Sekunden oder eine entsprechende Anzahl von Byte im Relay-Logausprobieren. Sind Sie zu weit voraus, werden die Daten, die Sie in die Caches holen,schon wieder verschwunden sein, wenn der SQL-Thread sie braucht.

Schauen wir uns an, wie man Anweisungen umschreiben muss, um diesen Ansatz verfol-gen zu können. Nehmen Sie einmal die folgende Abfrage:

mysql> UPDATE sakila.film SET rental_duration=4 WHERE film_id=123;

Das folgende SELECT bezieht die gleichen Zeilen und Spalten:

mysql> SELECT rental_duration FROM sakila.film WHERE film_id=123;

Diese Technik funktioniert nur mit den richtigen Lasteigenschaften und der passendenHardware-Konfiguration. Folgende Bedingungen könnten darauf hindeuten, dass siefunktioniert:

• Der Slave-SQL-Thread ist ein-/ausgabegebunden, aber der Slave-Server insgesamt istes nicht. Ein vollständig ein-/ausgabegebundener Server würde vom Vorabholen derDaten nichts haben, weil er keine untätigen Festplatten hat, mit denen dies erfolgenkönnte.

• Der Arbeitssatz ist viel größer als der Speicher (weshalb der SQL-Thread viel Zeitmit dem Warten auf die Ein-/Ausgaben verbringt). Wenn Ihr Arbeitssatz in denSpeicher passt, hilft das Vorabholen nicht, weil Ihr Server sich nach einer Weile»aufwärmt« und nur noch selten auf Ein-/Ausgaben warten muss.

• Der Slave besitzt viele Festplattenlaufwerke. Die Leute, von denen wir wissen, dasssie diese Taktik einsetzen, haben acht oder mehr Laufwerke pro Slave. Es könntemit weniger funktionieren, aber Sie brauchen wenigstens zwei bis vier Laufwerke.

• Sie nutzen eine Storage-Engine mit Row-Level-Locking, wie etwa InnoDB. Wenn Siedies auf einer MyISAM-Tabelle versuchen, werden der Slave-SQL-Thread und derThread, der die Daten vorab holt, wahrscheinlich in einen Wettstreit um die Tabel-len-Locks verfallen, wodurch sich die Dinge weiter verlangsamen. (Wenn Sie jedochviele Tabellen haben und die Schreiboperationen zwischen ihnen verteilt sind,könnte sich theoretisch auch bei MyISAM-Tabellen mit dieser Technik die Replika-tion beschleunigen lassen.)

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Eine Beispiellast, die vom Vorabholen der Daten profitiert, ist eine mit vielen weit ver-streuten, einzeiligen UPDATE-Anweisungen, die typischerweise auf dem Master starknebenläufig sind. DELETE-Anweisungen kommt dies ebenfalls zugute. INSERT-Anweisun-gen haben weniger von diesem Ansatz – vor allem, wenn die Zeilen sequenziell eingefügtwerden –, weil das Ende des Index bereits von vorangegangenen Einfügevorgängen»heiß« ist.

Wenn eine Tabelle viele Indizes besitzt, ist es eventuell nicht möglich, alle Daten vorherzu holen, die eine Anweisung modifizieren wird. Die UPDATE-Anweisung ändert vielleichtjeden Index, das SELECT liest aber im besten Fall typischerweise nur den Primärschlüsselund einen sekundären Index. Das UPDATE muss dennoch weitere Indizes zur Modifikationholen. Die Effektivität dieser Taktik ist daher in Tabellen mit vielen Indizes deutlich ein-geschränkt.

Sie können mit iostat feststellen, ob Sie freie Festplatten haben, die solche Anforderungenzum Vorabholen von Daten erledigen könnten. Schauen Sie sich die Warteschlangen-größe und die Service-Zeit an (Beispiele finden Sie im vorangegangenen Kapitel). Einekleine Warteschlange zeigt, dass etwas auf einer höheren Ebene Anforderungen seriali-siert. Eine große Warteschlange zeigt eine hohe Last – die Art, die Sie typischerweisenicht von einem Slave-SQL-Thread erhalten werden, wenn Sie viele Festplatten haben.Eine hohe Service-Zeit bedeutet, dass zu viele Anforderungen auf einmal an die Festplatteübermittelt werden.

Diese Technik ist keine Wunderwaffe. Es gibt viele Gründe, weshalb sie bei Ihnen nichtfunktionieren oder vielleicht sogar weitere Probleme verursachen könnte. Sie sollten sienur dann versuchen, wenn Sie Ihre Hardware und Ihr Betriebssystem gut kennen. Wirkennen Leute, bei denen dieser Ansatz die Replikationsgeschwindigkeit um 300 % bis400 % vergrößert hat. Wir haben es aber selbst ausprobiert und festgestellt, dass es nichtimmer funktioniert hat. Es ist wichtig, die Parameter richtig einzustellen. Allerdings gibtes nicht immer eine richtige Kombination aus Parametern. Manchmal verhindern auchVerhaltensweisen des Dateisystems und/oder des Kernels eine parallele Ein-/Ausgabe. Siemüssen es selbst ausprobieren!

Das Werkzeug mk-slave-prefetch, ein Teil von Maatkit, ist eine Implementierung derIdeen, die wir in diesem Abschnitt beschrieben haben.

Übergroße Pakete vom MasterEin weiteres schwer zu findendes Problem bei der Replikation kann auftreten, wenn diemax_allowed_packet-Größe des Masters nicht der des Slaves entspricht. In diesem Fallkann der Master ein Paket im Log aufzeichnen, das der Slave als zu groß ansieht. Wennder Slave dann das Binärlog-Event bezieht, treten bei ihm dann verschiedene Problemeauf. Dazu gehören eine Endlosschleife aus Fehlern und erneuten Versuchen oder eineBeschädigung im Relay-Log.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Beschränkte ReplikationsbandbreiteWenn Sie über eine eingeschränkte Bandbreite replizieren, können Sie die Optionslave_compressed_protocol auf dem Slave aktivieren (verfügbar seit MySQL 4.0). Verbin-det sich der Slave mit dem Master, fordert er eine komprimierte Verbindung an – mit dergleichen Komprimierung, die jede MySQL-Clientverbindung nutzen kann. Die verwen-dete Komprimierungs-Engine ist zlib, und unsere Tests haben gezeigt, dass sie textuelleDaten auf etwa ein Drittel ihrer Originalgröße komprimiert. Allerdings wird für die Kom-primierung auf dem Master und die Dekomprimierung auf dem Slave zusätzliche CPU-Zeit benötigt.

Bei einer langsamen Verbindung mit einem Master auf der einen Seite und vielen Slavesauf der anderen Seite, könnten Sie einen Distribution-Master auf der Slave-Seite unter-bringen. Auf diese Weise ist über die langsame Leitung nur ein Server mit dem Masterverbunden, wodurch sich die Last auf der Verbindung sowie die CPU-Last auf dem Mas-ter verringern.

Kein FestplattenplatzDie Replikation kann Ihre Festplatten tatsächlich mit Binärlogs, Relay-Logs oder tempo-rären Tabellen füllen, vor allem, wenn Sie viele LOAD DATA INFILE-Abfragen auf dem Mas-ter durchführen und log_slave_updates auf dem Slave aktiviert haben. Je weiter ein Slavezurückfällt, umso mehr Festplattenplatz benutzt er wahrscheinlich für die Relay-Logs,die vom Master geholt, aber noch nicht ausgeführt wurden. Sie können diese Fehler ver-meiden, indem Sie die Festplattenauslastung überwachen und die Konfigurationsvariablerelay_log_space setzen.

Beschränkungen der ReplikationDie MySQL-Replikation kann aufgrund der ihr innewohnenden Beschränkungen ausfal-len oder – mit oder ohne Fehler – aus dem Takt geraten. Es gibt eine ziemlich lange Listean SQL-Funktionen und Programmierpraktiken, die einfach nicht zuverlässig repliziertwerden (wir haben viele von ihnen in diesem Kapitel erwähnt). Es ist schwer sicherzustel-len, dass keine von ihnen den Weg in Ihren Produktionscode findet, vor allem, wenn IhreAnwendung oder Ihr Team sehr groß ist.14

Ein weiteres Problem sind Bugs im Server. Wir wollen nicht negativ klingen, aber diemeisten großen Versionen des MySQL-Servers haben in der Vergangenheit Bugs in derReplikation besessen, vor allem in den ersten Ausgaben der Hauptversion. Neue Eigen-schaften, wie etwa gespeicherte Prozeduren, haben normalerweise weitere Probleme ver-ursacht.

14 Leider besitzt MySQL keine forbid_operations_unsafe_for_replication-Option.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Wie schnell ist die Replikation? | 441

Für die meisten Benutzer stellt dies keinen Grund dar, neue Funktionen zu vermeiden,sondern bietet lediglich Veranlassung, besonders sorgfältig zu testen, vor allem wenn SieIhre Anwendung oder MySQL aufrüsten. Auch die Überwachung ist wichtig; Sie müssenwissen, wenn etwas ein Problem verursacht.

Die MySQL-Replikation ist kompliziert, und je komplizierter Ihre Anwendung ist, umsosorgfältiger müssen Sie sein. Wenn Sie jedoch lernen, damit umzugehen, funktioniert siewirklich gut.

Wie schnell ist die Replikation?Häufig wird in Bezug auf die Replikation die Frage gestellt: »Wie schnell ist sie?« Sie ist,kurz gesagt, im Allgemeinen sehr schnell und läuft so schnell, wie MySQL die Eventsvom Master kopieren und wieder abspielen kann. Wenn Sie ein langsames Netzwerk undsehr große Binärlog-Events haben, dann ist die Verzögerung zwischen der Aufzeichnungim Binärlog und der Ausführung auf dem Slave vielleicht spürbar. Brauchen Ihre Abfra-gen lange für die Ausführung und haben Sie ein schnelles Netzwerk, dann können Siemeist davon ausgehen, dass die Abfragezeit auf dem Slave einen größeren Anteil an derZeit für die Replikation eines Events hat.

Um eine umfassendere Antwort geben zu können, müsste jeder Schritt des Vorgangsgemessen und anschließend entschieden werden, welche Schritte die meiste Zeit in IhrerAnwendung erfordern. Für manche Leser ist es vermutlich nur wichtig, dass es normaler-weise nur eine kleine Verzögerung zwischen dem Aufzeichnen der Events auf dem Masterund dem Kopieren der Events in das Relay-Log auf dem Slave gibt. Falls Sie es genauerwissen wollen, schauen Sie sich unser kleines Experiment an.

Wir bauten auf dem Prozess auf, der in der ersten Ausgabe dieses Buches beschriebenwurde, sowie auf den Methoden von Giuseppe Maxia,15 um die Replikationsgeschwin-digkeit mit hoher Präzision zu messen. Wir erstellten eine nichtdeterministische benut-zerdefinierte Funktion, die die Systemzeit mit Mikrosekundengenauigkeit zurückliefert(den Quellcode finden Sie in »Benutzerdefinierte Funktionen« auf Seite 248):

mysql> SELECT NOW_USEC( )+----------------------------+| NOW_USEC( ) |+----------------------------+| 2007-10-23 10:41:10.743917 |+----------------------------+

Dies erlaubt es uns, die Replikationsgeschwindigkeit zu messen, indem wir den Wert vonNOW_USEC( ) in eine Tabelle auf dem Master einfügten und sie dann mit dem Wert auf demSlave vergleichten.

15 Siehe http://datacharmer.blogspot.com/2006/04/measuring-replication-speed.html.

http://datacharmer.blogspot.com/2006/04/measuring-replication-speed.html

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Wir maßen die Verzögerung, indem wir zwei Instanzen von MySQL auf dem gleichenServer einrichteten, um Ungenauigkeiten zu vermeiden, die durch den Takt verursachtwurden. Wir konfigurierten eine Instanz als Slave der anderen und führten dann die fol-genden Abfragen auf der Master-Instanz aus:

mysql> CREATE TABLE test.lag_test(-> id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,-> now_usec VARCHAR(26) NOT NULL-> );

mysql> INSERT INTO test.lag_test(now_usec) VALUES( NOW_USEC( ) );

Wir verwendeten eine VARCHAR-Spalte, weil die in MySQL eingebauten Typen Zeiten mitAuflösungen von unter einer Sekunde nicht speichern können (obwohl einige seiner Zeit-funktionen in der Lage sind, Berechnungen im Bereich unter einer Sekunde durchzufüh-ren). Nun musste nur noch die Differenz zwischen dem Slave und dem Master verglichenwerden. Dazu eignet sich eine Federated-Tabelle. Auf dem Slave führten wir Folgendesaus:

mysql> CREATE TABLE test.master_val (-> id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,-> now_usec VARCHAR(26) NOT NULL-> ) ENGINE=FEDERATED-> CONNECTION='mysql://user:[email protected]/test/lag_test';

Ein einfaches Join und die Funktion TIMESTAMPDIFF( ) zeigen den Rückstand in Mikrose-kunden zwischen der Ausführungszeit der Abfrage auf dem Master und dem Slave:

mysql> SELECT m.id, TIMESTAMPDIFF(FRAC_SECOND, m.now_usec, s.now_usec) AS usec_lag-> FROM test.lag_test as s-> INNER JOIN test.master_val AS m USING(id);

+----+----------+| id | usec_lag |+----+----------+| 1 | 476 |+----+----------+

Wir fügten mit einem Perl-Skript 1.000 Zeilen auf dem Master ein. Zwischen den einzel-nen Einfügungen ließen wir eine Verzögerung von 10 Millisekunden, um zu verhindern,dass die Master- und Slave-Instanzen begannen, um die CPU-Zeit zu kämpfen. Anschlie-ßend erzeugten wir eine temporäre Tabelle, die den Rückstand des jeweiligen Events ent-hielt:

mysql> CREATE TABLE test.lag AS> SELECT TIMESTAMPDIFF(FRAC_SECOND, m.now_usec, s.now_usec) AS lag

-> FROM test.master_val AS m-> INNER JOIN test.lag_test as s USING(id);

Als Nächstes gruppierten wir die Ergebnisse nach Rückstandszeit, um festzustellen, wel-ches die am häufigsten auftretenden Rückstandszeiten waren:

mysql> SELECT ROUND(lag / 1000000.0, 4) * 1000 AS msec_lag, COUNT(*)-> FROM lag-> GROUP BY msec_lag-> ORDER BY msec_lag;

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009

Die Zukunft der MySQL-Replikation | 443

+----------+----------+| msec_lag | COUNT(*) |+----------+----------+| 0.1000 | 392 || 0.2000 | 468 || 0.3000 | 75 || 0.4000 | 32 || 0.5000 | 15 || 0.6000 | 9 || 0.7000 | 2 || 1.3000 | 2 || 1.4000 | 1 || 1.8000 | 1 || 4.6000 | 1 || 6.6000 | 1 || 24.3000 | 1 |+----------+----------+

Die Ergebnisse zeigen, dass die meisten kleinen Abfragen weniger als 0,3 Millisekundenfür die Replikation brauchen, also von der Ausführungszeit auf dem Master bis zur Aus-führungszeit auf dem Slave.

Hier wird allerdings nicht gemessen, wie schnell ein Event beim Slave ankommt, nach-dem es im Binärlog auf dem Master aufgezeichnet wurde. Es wäre schön, diesen Wert zukennen, denn je schneller der Slave das Log-Event empfängt, umso besser ist es. Wennder Slave das Event empfangen hat, kann er eine Kopie bereitstellen, falls der Masterabstürzt.

Obwohl Ihre Messungen nicht exakt zeigen, wie lang dieser Teil des Vorgangs dauert,sollte er theoretisch außerordentlich schnell ablaufen (d.h. nur durch die Netzwerkge-schwindigkeit eingeschränkt). Der MySQL-Binlog-Dump-Prozess fragt nicht den Masternach Events ab, weil das ineffizient und langsam wäre. Stattdessen benachrichtigt derMaster den Slave über Events. Das Lesen eines Binärlog-Events vom Master ist ein blo-ckierender Netzwerkaufruf, der praktisch sofort damit beginnt, Daten zu senden, nach-dem der Master das Event im Log aufgezeichnet hat. Man kann also mit hoher Sicherheitsagen, dass das Event den Slave so schnell erreicht, wie der Slave-Thread aufwachen unddas Netzwerk die Daten übertragen kann.

Die Zukunft der MySQL-ReplikationDie MySQL-Replikation hat eine Reihe von Schwächen, die MySQL AB künftig behebenwill. Von dritter Seite wurden bereits einige Funktionen und Problemlösungen bereitge-stellt. Zum Beispiel hat Google eine Reihe von eigenen Patches für den MySQL-Serververöffentlicht, die ihn um Fähigkeiten zur quasisynchronen Replikation sowie weitereEigenschaften erweitern (siehe »Synchrone MySQL-Replikation« auf Seite 492).

Ein weiterer möglicher Zusatz ist die Unterstützung für die Multimaster-Replikation –d.h. einen Slave mit mehr als einem Master. Dieses Problem ist wahrscheinlich schwierigzu lösen und erfordert vermutlich Fähigkeiten zur Konflikterkennung und -auflösung.

Dies ist ein A

uszug aus dem B

uch "High P

erformance M

ySQ

L / Optim

ierung, Backups, R


N 978-3-89721-889-5

http://ww


ysql2ger/ D


Urheberrecht. ©

O’R

eilly Verlag 2009


Die zeilenbasierte Replikation in MySQL 5.1 ist ein Schritt in diese Richtung. Zeilenba-sierte Replikation könnte es künftig auch erlauben, durch mehrere Threads Events aufden Slave anwenden zu lassen, wodurch der Flaschenhals verschwindet, der durch dieSingle-Thread-Regelung auftritt.

Es gibt darüber hinaus Pläne, die Online-Backup-API in die Replikation zu integrierenund es einem MySQL-Server zu erlauben, sich automatisch selbst als Slave eines anderenServers zu konfigurieren.

Momentan gibt es in MySQL keine Garantien für die Konsistenz und Korrektheit vonDaten. Entsprechend einer Umfrage auf der MySQL-Website ist die am meistengewünschte Funktion ein Online-Konsistenztest, mit dem geprüft werden kann, ob einSlave die gleichen Daten enthält wie sein Master. MySQL AB betreibt für diese Aufgabeein Worklog mit einer grundlegenden Beschreibung für die Lösung dieses Problems.Viele Leute haben außerdem Erweiterungen für das Binärlog-Format gefordert, umsicherzustellen, dass Beschädigungen erkannt werden können, und MySQL AB hat auchhier bestätigt, dass es sich um eine wichtige Aufgabe handelt.

Diese und weitere Verbesserungen dürften dafür sorgen, dass die MySQL-Replikation inder Zukunft noch leistungsfähiger und zuverlässiger wird. Es ist ermutigend, wenn manauf die letzten Jahre zurückblickt und die Änderungen sieht, die in dieser Zeit geschehensind. Es soll dennoch angemerkt werden, dass die meisten Funktionen, die in der erstenAusgabe dieses Buches vorhergesagt wurden, niemals umgesetzt wurden, obwohl einigevon ihnen teilweise implementiert wurden – wie z.B. die ausfallsichere Replikation, diezwar in der MySQL-Codebasis vorhanden ist, aber als Projekt nie zu Ende geführt wurde.

Documents

Inhalt - bücher.de · 2020-01-30 · |V Inhalt Vorwort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .