La conversion de 5.0.27 à 5.1.41, obtenir des erreurs clés en double (1062)

Question

J'ai une base de données qui est en cours d'exécution sur un serveur 5.0.27. Je veux passer à un nouveau serveur 5.1.41.

Je mysqldump'd tous les fichiers. Lors de la restauration, je reçois une erreur

ERROR 1062 (23000) at line 21: Duplicate entry 'weiÃ' for key 'title'

Je l'ai réduit la baisse de l'échec de ce script, que je peux courir et il échoue:

--
-- Table structure for table `word`
--

set names utf8;

DROP TABLE IF EXISTS `word`;
CREATE TABLE `word`
(
  `wordid` int (10) unsigned NOT NULL auto_increment,
  `title` char (50) NOT NULL default '',
  PRIMARY KEY  (`wordid`),
  UNIQUE KEY `title` (`title`)
) ENGINE=MyISAM AUTO_INCREMENT=280707 DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

--
-- Dumping data for table `word`
--

LOCK TABLES `word` WRITE;
INSERT INTO `word` VALUES
(198036,'weis'),
(241473, unhex('776569C39F'));
UNLOCK TABLES;

EDIT -. Changé UNHEX

Je l'ai vérifié et revérifié toutes les variables de charset et de collation entre les deux serveurs, et ils semblent identiques. Même si elles ne sont pas, je spécifiant le classement moi-même.

Les indices quant à ce que je fais mal ici?

EDIT: voici la commande que je utilise pour vider la base de données:

mysqldump --add-drop-table --add-locks --disable-keys --lock-tables --quick  -uusername -ppassword database > filename

et de charge

mysql -D$MYSQL_DB -u$MYSQL_USER -p$MYSQL_PASSWD < filename

Comment puis-je vérifier les connexions de classement pour la client?

Answer 1

D'un copain sur LiveJournal, j'ai découvert qu'il est un bug « fix » entre 5,0 et 5,1: Ils ont changé le classement. Si vous lisez le rapport de bogue, ils en fait ont éclaté il (IFE et weiss ne devrait pas être équivalent). Mais ils ne vont pas à unbreak il. Je vais donc soit avoir à modifier le classement (comme Dave Orr suggère), ou modifier manuellement mes données.

http://bugs.mysql.com/bug.php?id=27877

Answer 2

Le problème spécifique est que dans utf8_general_ci, « weis » et « weiß » sont équivalentes. Si vous voulez « weiß » être égal à « weiss », alors vous devriez utf8_unicode_ci utiliser. Cela corrigera le problème du côté des importations (sauf si vous avez « weiss » dans la base de données, mais vous avez vraiment un double).

Lors d'une supposition, la table d'origine a utf8_unicode_ci ensemble, et vous ne l'avez pas remarqué la différence. Si ce n'est pas vrai, je ne sais pas comment votre table est entré dans l'état où il est en - mais le passage à la collation droite devrait résoudre votre problème

.

Answer 3

Utilisez-vous le mysqldump & mysql de 5,1 de 5,0
vous pouvez essayer différents combos.

pourrait la sourcedb contenir des valeurs en double dans la colonne « unique »?
Retirer la contrainte et le contrôle « UNIQUE KEY » les enregistrements sont en double dans le TargetDB.
Cela pourrait donner un aperçu du problème.

Answer 4

Indiquez le jeu de caractères par option --default-character-set. Il est important.