MySQL Binary Log Replication: Kann es so eingestellt werden, dass Fehler ignoriert werden?

Question

Ich bin ein Master-Slave-MySQL-Binär-Log-Replikationssystem (puh!), Die für einige Daten nicht synchron ist (was bedeutet, der Master hält mehr Daten als der Slave). Aber der Slave stoppt sehr häufig bei dem geringsten MySQL-Fehler, kann dies deaktiviert werden? (vielleicht eine my.cnf-Einstellung für den replizierenden Slave ignore-replicating-errors oder einen Teil der Sortierung;)

Dies passiert, wenn der Slave versucht, ein Objekt zu replizieren, das nicht existiert , der Sklave stirbt einfach. eine schnelle Überprüfung bei SHOW SLAVE STATUS \ 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)' 

, die ich sofort reparieren (wenn ich merke, dass der Slave gestoppt wurde), indem Sie die folgenden Aktionen ausführen:

STOP SLAVE; 
RESET SLAVE; 
START SLAVE; 

... in letzter Zeit wurde dies von ermüdend immer freundlich und vor Ich spucke eine Art von PHP aus, die das für mich tut, ich frage mich, ob es irgendeinen my.cnf-Eintrag gibt, der den Slave beim ersten Fehler nicht umbringt.

Cheers,

/mp

Answer 1

Ja, mit --slave-skip-errors = xxx in my.cnf, wobei xxx 'all' oder eine Komma sep Liste von Fehlercodes ist.

Answer 2

Zuerst wollen Sie wirklich Fehler ignorieren? Wenn Sie einen Fehler erhalten, ist es wahrscheinlich, dass die Daten nicht mehr synchron sind. Vielleicht möchten Sie die Slave-Datenbank löschen und den Synchronisierungsprozess neu starten, wenn Sie einen Fehler erhalten. Ich glaube, der Fehler, den Sie bekommen, ist nicht, wenn Sie ein Objekt replizieren, das nicht existiert (was würde das überhaupt bedeuten?) - es sieht so aus, als würden Sie ein Objekt replizieren, das bereits in der Slave-Datenbank existiert.

Ich vermute, dass das Problem vor allem daraus entsteht, nicht bei einer sauberen Datenkopie anzufangen. Es scheint, dass der Master zum Slave kopiert wurde; dann wurde die Replikation ausgeschaltet (oder fehlgeschlagen); und dann hat es wieder angefangen, aber ohne dem Sklaven die Chance zu geben, nachzuholen, was er verpasst hat.

Wenn Sie jemals eine Zeit haben, in der der Master für den Schreibzugriff lange genug geschlossen werden kann, um die Datenbank zu klonen und in den Slave zu importieren, könnte dies die Probleme beseitigen.

Answer 3

Moderne mysqldump Befehle haben einige Optionen, die beim Einrichten einer konsistenten Replikation helfen. Überprüfen Sie --master-data, die die binäre Protokolldatei und -position in den Speicherauszug legen und beim Laden in den Slave automatisch festlegen. Außerdem wird --single-transaction den Speicherauszug innerhalb einer Transaktion ausführen, so dass keine Schreibsperre für einen konsistenten Speicherauszug erforderlich ist.

Answer 4

Wenn der Slave nicht für andere Schreibvorgänge als die Replikation verwendet wird, empfehlen die Autoren von High Performance MySQL, auf dem Slave-Server read_only hinzuzufügen, um zu verhindern, dass Benutzer versehentlich Daten auf dem Slave ändern, da dies ebenfalls erstellt wird Fehler, die du erlebt hast.

Answer 5

Ich glaube, Sie Replikation mit aus sync tun die Datenbank zuerst die Datenbank synchronisieren und versuchen, die für die Replikation und Server gleichen eindeutigen IDs generieren und versuchen Auto incerment einstellen Offset Slave

Answer 6

Anschlag; setze global sql_slave_skip_counter = 1; Start Slave;

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