Преобразование от 5,0,27 до 5.1.41, получение дублирующихся ошибок ключей (1062)
-
01-10-2019 - |
Вопрос
У меня есть база данных, которая в данный момент работает на сервере 5.0.27. Я хочу перейти на новый сервер 5.1.41.
Я mysqldump'd все файлы. При восстановлении я получаю ошибку
ERROR 1062 (23000) at line 21: Duplicate entry 'weiÃ' for key 'title'
Я сузил неудачу на этот скрипт, который я могу бежать, и он не удается:
--
-- 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;
Редактировать - изменено на нее.
Я проверил и перепроверил все переменные Charset и Collation между двумя серверами, и они выглядят идентичными. Даже если бы они не были, я указываю сопоставление сам.
Любые подсказки относительно того, что я делаю не так?
Редактировать: вот команда, которую я использую для сброса базы данных:
mysqldump --add-drop-table --add-locks --disable-keys --lock-tables --quick -uusername -ppassword database > filename
и загрузить
mysql -D$MYSQL_DB -u$MYSQL_USER -p$MYSQL_PASSWD < filename
Как я могу проверить сопоставления для клиентских соединений?
Решение 2
От приятеля на LiveJournal я обнаружил, что это ошибка «исправить» между 5,0 и 5.1: они изменили сопоставление. Если вы прочитаете отчет об ошибках, они на самом деле сломанный Это (Weis и Weiss не должны быть эквивалентными). Но они не собираются не разрыв этого. Поэтому мне придется изменить сопоставление (как предлагает Dave ORR), либо вручную редактируют мои данные.
Другие советы
Специфика в том, что в UTF8_General_CI, «Weis» и «Weiß» эквивалентны. Если вы хотите «Weiß», чтобы быть равным «Weiss», то вам следует использовать UTF8_UNICODE_CI. Это исправит проблему на стороне импорта (если у вас нет «Weiss» в базе данных, но тогда у вас действительно есть дубликат).
На предположение, оригинальная таблица имеет набор UTF8_UNICODE_CI, и вы не заметили разницу. Если это не так, я понятия не имею, как ваш стол попал в состояние, но переключение на правильное сопоставление должно решить вашу проблему.
Вы используете mysqldump
& mysql
С 5,1 от 5,0?
Вы можете попробовать разные комбо.
Может ли SourcedB содержал дублирующие значения в «уникальном» столбце?
Удалите ограничение «Уникальный ключ» и проверьте, какие записи дублируются в TargetDB.
Это может дать некоторое представление о проблеме.
Укажите символ, установленный --default-character-set
вариант. Это важно.