ASPECT # 1: Réplication
Je ne pense pas que
replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup
aller ensemble.
D'autres personnes se sont également interrogées à ce sujet
Le problème provient des règles de réplication de commande qui sont traitées. Selon la documentation MySQL sur les règles de réplication :
Si des options --replicate-rewrite-db ont été spécifiées, elles sont appliquées avant que les règles de filtrage --replicate- * ne soient testées.
Même la documentation MySQL sur replicate-rewrite-db dit:
La traduction du nom de la base de données est effectuée avant que les règles --replicate- * ne soient testées.
Le replicate-wild-do-tableest appliqué après la réécriture. Il ne serait pas surprenant que cette commande impose en quelque sorte un INSERT dans une table qui contient déjà des données.
Vous vous demandez probablement comment les données y sont arrivées?
ASPECT # 2: mysqldump
Faire mysqldump --single-transactionsemblerait être le meilleur moyen de décharger des données à un moment précis. Malheureusement, mysqldump --single-transactiona un talon d'Achille: ALTER TABLE. Si une table est soumise à des ALTER TABLEcommandes, telles que a DROP TABLEet CREATE TABLE, qui peuvent briser l'intégrité de la transaction dans laquelle mysqldump tentait d'effectuer le vidage. Tronquer une table (qui est DDL dans l'univers MySQL) et supprimer et ajouter des index peut être aussi perturbateur.
Vous pouvez trouver plus d'informations à ce sujet dans le secret MySQLDump le mieux gardé de MySQL Performance Blog . J'ai en fait abordé ce point dans une question précédente décrivant 12 commandes qui peuvent briser l'intégrité d'une transaction mysqldump: MySQL backup InnoDB
CAVEAT
ÉPILOGUE
Un ou les deux aspects peuvent avoir contribué à laisser une ligne se glisser pendant le mysqldump qui n'aurait pas dû exister en raison des règles de réécriture ou de l'isolement du mysqldump qui a été remplacé.
SUGGESTIONS
Je ferais un vidage mysqlbinlog de tous les journaux de relais depuis le début du mysqldump pour voir tous les INSERT que l'esclave traitera et voir si ces lignes existent déjà sur l'esclave. S'ils le font, vous pourriez probablement faire deux choses:
1: Ignorez toutes les erreurs de clé en double
Ajoutez simplement ceci à my.cnf sur l'esclave
[mysqld]
slave-skip-errors=1062
skip-slave-start
et redémarrez mysql. Ensuite, exécutezSTART SLAVE;
toutes les erreurs de clé en double seront contournées. Quand Seconds_Behind_Masterarrive à 0, supprimez ces lignes et redémarrez mysql.
2: Téléchargez les outils Percona
Les outils dont vous avez besoin sont
Utilisez-les pour trouver les différences dans l'esclave, puis corrigez-les