MySQL-Binärprotokollreplikation:Kann es so eingestellt werden, dass Fehler ignoriert werden?

StackOverflow https://stackoverflow.com/questions/30660

Frage

Ich betreibe ein Master-Slave-MySQL-Binärprotokollreplikationssystem (puh!), das für einige Daten nicht synchron ist (was bedeutet, dass der Master mehr Daten speichert als der Slave).Der Slave stoppt jedoch sehr häufig beim kleinsten MySQL-Fehler. Kann dies deaktiviert werden?(Vielleicht eine my.cnf-Einstellung für den replizierenden Slave, „ignore-replicating-errors“ oder ähnliches ;) )

Das passiert hin und wieder, wenn der Sklave versucht, einen Gegenstand zu replizieren, der nicht existiert, und der Sklave einfach stirbt.ein kurzer Check unter SLAVE-STATUS ANZEIGEN \G; gibt

       Slave-IO-Running: Yes
      Slave-SQL-Running: No
        Replicate-Do-DB: 
             Last-Errno: 1062
             Last-Error: Error 'Duplicate entry '15218' for key 1' on query. Default database: 'db'. Query: 'INSERT INTO db.table ( FIELDS ) VALUES ( VALUES )'

was ich sofort behebe (sobald ich merke, dass der Slave gestoppt wurde), indem ich Folgendes tue:

STOP SLAVE;
RESET SLAVE;
START SLAVE;

...In letzter Zeit ist das etwas lästig geworden, und bevor ich irgendein PHP ausspucke, das das für mich erledigt, frage ich mich, ob es einen my.cnf-Eintrag gibt, der den Slave nicht beim ersten Fehler tötet.

Prost,

/mp

War es hilfreich?

Lösung

Ja, mit --slave-skip-errors=xxx in my.cnf, wobei xxx „all“ oder eine durch Kommas getrennte Liste von Fehlercodes ist.

Andere Tipps

Sklave stoppen;set global sql_slave_skip_counter=1;Slave starten;

Sie können nur den aktuellen Fehler ignorieren und den Replikationsprozess fortsetzen.

Erstens: Wollen Sie Fehler wirklich ignorieren?Wenn Sie eine Fehlermeldung erhalten, sind die Daten wahrscheinlich nicht mehr synchronisiert.Vielleicht möchten Sie die Slave-Datenbank löschen und den Synchronisierungsprozess neu starten, wenn Sie eine Fehlermeldung erhalten.

Zweitens denke ich, dass der Fehler nicht auftritt, wenn Sie ein Element replizieren, das nicht existiert (was würde das überhaupt bedeuten?), sondern es sieht so aus, als würden Sie ein Element replizieren, das bereits in der Slave-Datenbank vorhanden ist.

Ich vermute, dass das Problem hauptsächlich dadurch entsteht, dass nicht mit einer sauberen Datenkopie begonnen wird.Es scheint, dass der Master auf den Slave kopiert wurde;dann wurde die Replikation deaktiviert (oder ist fehlgeschlagen);und dann hat es wieder angefangen, aber ohne dem Sklaven die Chance zu geben, das Versäumte nachzuholen.

Wenn der Master einmal lange genug für den Schreibzugriff geschlossen werden kann, um die Datenbank zu klonen und in den Slave zu importieren, verschwinden die Probleme möglicherweise.

Modern mysqldump Befehle verfügen über einige Optionen, die beim Einrichten einer konsistenten Replikation helfen.Kasse --master-data Dadurch werden die binäre Protokolldatei und ihre Position im Speicherauszug abgelegt und beim Laden in den Slave automatisch festgelegt.Auch --single-transaction führt den Dump innerhalb einer Transaktion durch, so dass keine Schreibsperre erforderlich ist, um einen konsistenten Dump zu erstellen.

Wenn der Slave für keine anderen Schreibvorgänge als die Replikation verwendet wird, empfehlen die Autoren von High Performance MySQL das Hinzufügen read_only auf dem Slave-Server, um zu verhindern, dass Benutzer versehentlich Daten auf dem Slave ändern, da dies ebenfalls zu denselben Fehlern führt, die bei Ihnen aufgetreten sind.

Ich denke, Sie führen eine Replikation durch, ohne die Datenbank zu synchronisieren. Synchronisieren Sie zunächst die Datenbank und versuchen Sie eine Replikation. Die Server generieren dieselben eindeutigen IDs und versuchen, den automatischen Inkrement-Offset festzulegen

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top