Pourquoi la défaillance de la réplication avec l'erreur a-t-elle répété la clé de la clé?

Nous reproduisons depuis un an ou deux sans aucun problème. Parfois, nous obtenons une requête SQL erronée qui arrête la réplication et nous utilisons les commandes suivantes pour la reprendre:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;
SHOW SLAVE STATUS \G;

Ceci est généralement normal, mais aujourd'hui, nous avons commencé à recevoir des erreurs lorsque vous essayez de répliquer la base de données. (FYI Invision Power Board):

               Last_SQL_Error: Error 'Duplicate entry 'forums-pid-994' for key '
app'' on query. Default database: 'forum_db'. Query: 'INSERT INTO ibf_rep
utation_cache (`app`,`type`,`type_id`,`rep_like_cache`) VALUES('forums','pid',99
4,'a:2:{s:10:\"cache_data\";a:0:{}s:12:\"cache_expire\";i:1326339370;}') ON DUPL
ICATE KEY UPDATE app=VALUES(app),type=VALUES(type),type_id=VALUES(type_id),rep_l
ike_cache=VALUES(rep_like_cache)'

Il existe de nombreuses demandes similaires qui semblent faire partie du logiciel. Invision Power Board, Alors éloignez-vous - Pas la meilleure option. Étrange que lorsque j'exécute cette demande d'accompagnement sur le même serveur MySQL, Il passe sans problèmes.

Noter:

Hier nous avons mis à jour MySQL 5.1.36 avant que MySQL 5.5.16, Donc, c'est presque certainement connecté. C'est sur le serveur Windows.

Voici l'emplacement de la table:

mysql> DESC forum_db.ibf_reputation_cache;
+----------------+---------------------+------+-----+---------+----------------+

| Field | Type | Null | Key | Default | Extra |

+----------------+---------------------+------+-----+---------+----------------+

| id | bigint(10) unsigned | NO | PRI | NULL | auto_increment |

| app | varchar(32) | NO | MUL | NULL | |

| type | varchar(32) | NO | MUL | NULL | |

| type_id | int(10) unsigned | NO | | NULL | |

| rep_points | int(10) | NO | | 0 | |

| rep_like_cache | mediumtext | YES | | NULL | |

+----------------+---------------------+------+-----+---------+----------------+

6 rows in set (0.12 sec)
Invité:

Alice

Confirmation de:

Commençons par un message d'erreur:

               Last_SQL_Error: Error 'Duplicate entry 'forums-pid-994' for key '
app'' on query. Default database: 'forum_db'. Query: 'INSERT INTO ibf_rep
utation_cache (`app`,`type`,`type_id`,`rep_like_cache`) VALUES('forums','pid',99
4,'a:2:{s:10:\"cache_data\";a:0:{}s:12:\"cache_expire\";i:1326339370;}') ON DUPL
ICATE KEY UPDATE app=VALUES(app),type=VALUES(type),type_id=VALUES(type_id),rep_l
ike_cache=VALUES(rep_like_cache)'

Réplication

Se plaindre de l'indice appelé

app

.

De toute évidence, vous avez un index unique pour cette colonne. Faites également attention à la demande

ON DUPLICATE KEY

paragraphe. Vous avez

app=VALUES(app)

. Cette colonne ne peut pas être remplacée dans

ON DUPLICATE KEY

Pour deux raisons:

C'est la même colonne qui a causé

ON DUPLICATE KEY

acte

Il affectera inutilement l'index

app

Si l'action a été autorisée

Recommandation: vous devez supprimer

app=VALUES(app)

de

ON DUPLICATE KEY

paragraphe.

Peut-être des versions précédentes MySQL Juste ignoré des colonnes invalides dans

ON DUPLICATE KEY

Article et la dernière version dont vous êtes actuellement conscient de ce problème.

Pour répondre aux questions, connectez-vous ou registre