Réplication des journaux binaires MySQL :Peut-il être configuré pour ignorer les erreurs ?
-
09-06-2019 - |
Question
J'utilise un système de réplication de journaux binaires MySQL maître-esclave (ouf !) qui, pour certaines données, n'est pas synchronisé (ce qui signifie que le maître contient plus de données que l'esclave).Mais l'esclave s'arrête très fréquemment à la moindre erreur MySQL, cela peut-il être désactivé ?(peut-être un paramètre my.cnf pour l'esclave de réplication ignore-replicating-errors ou quelque chose du genre ;) )
C'est ce qui arrive de temps en temps, lorsque l'esclave tente de reproduire un objet qui n'existe pas, il meurt.une vérification rapide à AFFICHER LE STATUT D'ESCLAVE \G ; donne
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 )'
que je corrige rapidement (une fois que je me rends compte que l'esclave a été arrêté) en procédant comme suit :
STOP SLAVE;
RESET SLAVE;
START SLAVE;
...Dernièrement, cela est devenu un peu fastidieux, et avant de cracher une sorte de PHP qui fait cela pour moi, je me demandais s'il y avait une entrée my.cnf qui ne tuerait pas l'esclave à la première erreur.
Acclamations,
/mp
La solution
Oui, avec --slave-skip-errors=xxx dans my.cnf, où xxx est « tout » ou une liste de codes d'erreur avec virgule sep.
Autres conseils
arrêter l'esclave;définir global sql_slave_skip_counter=1 ;démarrer l'esclave ;
Vous pouvez ignorer uniquement l'erreur actuelle et poursuivre le processus de réplication.
Tout d’abord, voulez-vous vraiment ignorer les erreurs ?Si vous obtenez une erreur, il est probable que les données ne soient plus synchronisées.Peut-être que vous souhaitez supprimer la base de données esclave et redémarrer le processus de synchronisation lorsque vous obtenez une erreur.
Deuxièmement, je pense que l'erreur que vous obtenez ne se produit pas lorsque vous répliquez un élément qui n'existe pas (qu'est-ce que cela signifierait de toute façon ?) - il semble que vous répliquez un élément qui existe déjà dans la base de données esclave.
Je soupçonne que le problème vient principalement du fait de ne pas démarrer une copie de données propre.Il semble que le maître ait été copié sur l'esclave ;alors la réplication a été désactivée (ou a échoué) ;et puis il a recommencé, mais sans laisser à l'esclave la possibilité de rattraper ce qu'il avait manqué.
Si jamais vous arrivez à un moment où le maître peut être fermé pour l'accès en écriture suffisamment longtemps pour cloner la base de données et l'importer dans l'esclave, cela pourrait résoudre les problèmes.
Moderne mysqldump
Les commandes disposent de quelques options pour vous aider à configurer une réplication cohérente.Vérifier --master-data
qui placera le fichier journal binaire et sa position dans le dump et sera automatiquement défini lors du chargement dans l'esclave.Aussi --single-transaction
effectuera le vidage à l'intérieur d'une transaction afin qu'aucun verrou en écriture ne soit nécessaire pour effectuer un vidage cohérent.
Si l'esclave n'est utilisé pour aucune écriture autre que la réplication, les auteurs de High Performance MySQL recommandent d'ajouter read_only
sur le serveur esclave pour empêcher les utilisateurs de modifier par erreur les données sur l'esclave, car cela créerait également les mêmes erreurs que vous avez rencontrées.
je pense que vous effectuez une réplication sans synchroniser la base de données, synchronisez d'abord la base de données et essayez la réplication et les serveurs génèrent les mêmes identifiants uniques et essayez de définir un décalage d'incernement automatique