Bonjour,

Je viens poser une question pour essayer de comprendre ce qui a pu me provoquer un bug (que j'ai résolu depuis)

J'ai 3 environnement au boulot, tous sous debian 9 :
- dev (Maria 10.4.7 officiel) - Serveur baremetal
- recette (Maria 10.4.7 officiel) - VM Proxmox
- prod (10.3 10.1.26-0+deb9u1) - VM Proxmox

Les environnement de dev et de recette sont en avance, car nous préparons l'upgrade dans les prochains jours

Toutes les semaines, il y a une remontée des données de prod sur les environnements de dev et de recette, qui consiste à faire un mysqldump depuis la prod et à le remonter sur les 2 autres environnements (et annonymiser les données, mais là, ça ne va pas nous intéresser)

Les backups sont fait base par base via un script bash qui lance les dumps sans options particulière
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
 
# Le fichier .my.backups.cnf ne contient que le login et le mot de passe du user servant aux backups
mysqldump --defaults-file=~/.my.backup.cnf --single-transaction "$BASE" | gzip -9 > "weekly_${BASE}_$(date +%Y-%m-%d).sql.gz"
Le backup est réalisé sur un slave juste après avoir stoppé la réplication, car il y a plusieurs bases à sauvegarder, et elles doivent être "synchrones"

Lors de la remontée, le script (différent car sur un autre serveur) ne fait rien de particulier non plus
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
 
# Même remarque sur le fichier .my.restore.cnf
zcat "weekly_${BASE}_$(date +%Y-%m-%d).sql.gz" | mysql --defaults-file=~/.my.restore.cnf --force "$BASE"
Or dans le lot, il y a une table qui fait planter le serveur de recette, mais pas celui de dev...

Le DROP TABLE se passe bien, mais le CREATE TABLE plante
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
 
ERROR 1005 (HY000) at line 6002: Can't create table `BASE`.`table` (errno: 121 "Duplicate key on write or update")
ERROR 1146 (42S02) at line 6046: Table`BASE`.`table` doesn't exist
# Répétée une 30aine de fois
# Je pense que sur la suite, la remontée a un peu fonctionnée car je n'ai pas d'erreur entre les lignes 6080 et 19686
ERROR 2013 (HY000) at line 19686: Lost connection to MySQL server during query
ERROR 2006 (HY000) at line 19687: MySQL server has gone away
# L'erreur se répète jusqu'à la fin de la remontée de ce fichier, et j'ai un OMM Kill sur le service dans les logs système dû soit à un manque de mémoire, soit à un manque de processeur, c'est variable
Étant une table centrale de notre appli, j'ai dû remonter en catastrophe une table pour que les devs puissent bosser et les clients contrôler leurs données

Or quand je tente de créer la table telle qu'elle est en prod, j'ai l'erreur "Duplicate key on write or update"
J'ai donc tenté de recréer la table sans les clefs => OK
En revanche, quand je fais un SHOW CREATE TABLE table, je me retrouve avec les clefs étrangères

Pour le coup, la solution a été simple, une fois la table recréée, j'ai supprimé les clefs étrangères et relancé une syncho manuellement, et elle n'a pas planté (j'espère que ça restera comme ça pour la semaine prochaine )

Mais du coup, ma question, c'est est-ce que quelqu'un sait d'où peut provenir ce bug ? Parce que je m'y suis cassé les dents 3 semaines d'affilé (je n'avais pas pensé à revérifier comment était créée la table les premières fois) et j'aimerais bien comprendre ce qui s'est passé (et faire une doc, on sait jamais)