|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте!
Возникла проблема при бэкапе
Было обнаружено что Mysql имеет проблему при работе с полями типа binary
Проблема заключается в том что он трактует байтовое содержимое этих полей как текстовые символы.
При бэкапе подобные поля выгружаются "как есть" - байт в байт, в то время как они должны выгружаться в совместимом HEX формате вида x123456789ABCDEF
При попытке восстановить данные из бэкапа, происходит ошибка. Mysql видит байтовые данные, пытается трактовать их как текст(а там и спец символы и текст) и выдает сообщение об ошибке.
Пример как выглядит строка инсерт выгруженная из бд.
INSERT INTO `table1` VALUES (1,'€J«gсЪНЧcџo·–', X'687474703A2F2F7777772E776561746865722E636F6D2F6F7');
строка - '€J«gсЪНЧcџo·–' - не что иное как символьное представление бинарных данных.
в примере видно что Mysql поля типа BLOB обрабатывает нормально и форматирует их шестнадцатиричном виде - X'687474703A2...
код таблицы:
CREATE TABLE `table1` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`field1` binary(16) NOT NULL,
`field1` tinyblob NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`),
UNIQUE KEY `hash` (`hash`)
) ENGINE=InnoDB AUTO_INCREMENT=5682 DEFAULT CHARSET=utf8;
Почему так происходит? Что делать чтобы он выгружал binary поля по нормальному.
Неактивен
Используйте адекватные клиенты для бэкапа и восстановления данных.
Обычные mysqldump и mysql отлично справляются с задачей:
celestia:~$ mysqldump test table1 | grep INSERT
INSERT INTO `table1` VALUES (1,'blah\0\0\0\0\0\0\0\0\0\0\0\0','blah'),(2,'тест\0\0\0\0\0\0\0\0','тест');
но если Вас это смущает, можете явно указать hex-вид:
celestia:~$ mysqldump --hex-blob test table1 | grep INSERT
INSERT INTO `table1` VALUES (1,0x626C6168000000000000000000000000,0x626C6168),(2,0xD182D0B5D181D1820000000000000000,0xD182D0B5D181D182);
Неактивен
Спасибо за совет. он мне помог
Неактивен
