Skip navigation links
MySQL 5.1 Referenzhandbuch :: 6 Replikation bei MySQL :: 6.14 Berichten von Replikationsfehlern und -problemen
6.15 Auto-Increment in der Multi-Master-Replikation »
Section Navigation      [Toggle]

6.14. Berichten von Replikationsfehlern und -problemen

Wenn Sie festgestellt haben, dass kein benutzerseitiger Fehler vorliegt und die Replikation trotzdem nicht stabil ist oder womöglich gar nicht funktioniert, ist es an der Zeit, uns einen Bugreport zu schicken. Wir benötigen von Ihnen so viele Informationen wie möglich, um den Bug aufzuspüren. Bitte nehmen Sie sich für die Vorbereitung des Bugreports Zeit und seien Sie sorgfältig bei Ihren Angaben.

Wenn Sie einen reproduzierbaren Testfall haben, der den Bug demonstriert, geben Sie diesen bitte in unsere Fehlerdatenbank ein. Eine Anleitung zur Vorgehensweise finden Sie in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“. Wenn Sie ein „Phantomproblem“ haben (d. h. eines, welches sich nicht gezielt reproduzieren lässt), dann gehen Sie wie folgt vor:

  1. Stellen Sie sicher, dass kein Fehler vorhanden ist. Wenn Sie am Slave beispielsweise Änderungen außerhalb des Slave-Threads vornehmen, dann sind die Daten nicht mehr synchron, und es kann bei Updates zu Verstößen aufgrund von Dubletten eindeutiger Schlüssel kommen. In diesem Fall bleibt der Slave-Thread stehen und wartet, bis Sie die Tabellen manuell bereinigt und die Synchronisation auf diese Weise wiederhergestellt haben. Dies ist kein replikationsbezogenes Problem. Die Replikation schlägt vielmehr aufgrund eines äußeren Störeinflusses fehl.

  2. Führen Sie den Slave mit den Optionen --log-slave-updates und --log-bin aus. Diese Optionen bewirken, dass der Slave die Updates, die er vom Master erhält, in seine eigenen Binärlogs schreibt.

  3. Speichern Sie alle Beweismittel, bevor Sie den Replikationsstatus zurücksetzen. Wenn wir keine oder nur bruchstückhafte Informationen erhalten, wird es schwierig bis unmöglich, die Problemursache zu ermitteln. Folgende Beweisstücke sollten Sie übermitteln:

    • alle Binärlogs des Masters

    • alle Binärlogs des Slaves

    • Ausgabe von SHOW MASTER STATUS auf dem Master zum Zeitpunkt der Feststellung des Problems

    • Ausgabe von SHOW SLAVE STATUS auf dem Slave zum Zeitpunkt der Feststellung des Problems

    • Fehlerlogs von Master und Slave

  4. Überprüfen Sie mit mysqlbinlog die Binärlogs. Folgender Befehl sollte zur Ermittlung der problematischen Abfrage hilfreich sein. Hierbei sind log_pos und log_file die Werte Master_Log_File bzw. Read_Master_Log_Pos in der Ausgabe von SHOW SLAVE STATUS. 

    shell> mysqlbinlog -j log_pos \
          log_file | head

Nachdem Sie alle Beweisstücke für das Problem gesammelt haben, versuchen Sie es zunächst als separaten Testfall zu extrahieren. Geben Sie das Problem danach mit möglichst vielen Informationen in unsere Bugdatenbank ein. Die Vorgehensweise ist in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“, beschrieben.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.