Ошика импорта БД на сервер с MySQL 6.0 (#1071 - Specified key was too long; max key length is 767 bytes)

Главные вкладки

Аватар пользователя Tinnka Tinnka 26 февраля 2012 в 0:41

Уважаемые коллеги, может быть кто нибудь сталкивался, подскажите как бороться пожалуйста.

Сайт был разработан на хостинге с версией MySQL 5.5, а переехать к заказчику должен на хостинг с MySQL 6.0.

Импорт БД на хостинг производился сначала как помощью Sypex Dumper, так и через phpMyAdmin, в обоих случаях ошибка повторяется: #1071 - Specified key was too long; max key length is 767 bytes (пример ошибки импорта через phpMyAdmin приведен ниже).

Экспериментальным путем, импортируя за раз только по одной таблице замечена следующая закономерность, без проблем импортируются таблицы с Primary Key тип данных int, и НЕ импортируются таблицы с Primary Key varchar.

Буду благодарна за любые разумные рекомендации.

SQL-запрос:

--
-- База данных: `sql15`
--
-- --------------------------------------------------------
--
-- Структура таблицы `actions`
--
CREATE TABLE IF NOT EXISTS `actions` (
`aid` varchar( 255 ) NOT NULL DEFAULT '0' COMMENT 'Primary Key: Unique actions ID.',
`type` varchar( 32 ) NOT NULL DEFAULT '' COMMENT 'The object that that action acts on (node, user, comment, system or custom types.)',
`callback` varchar( 255 ) NOT NULL DEFAULT '' COMMENT 'The callback function that executes when the action runs.',
`parameters` longblob NOT NULL COMMENT 'Parameters to be passed to the callback function.',
`label` varchar( 255 ) NOT NULL DEFAULT '0' COMMENT 'Label of the action.',
PRIMARY KEY ( `aid` )
) ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT = 'Stores action information.';

Ответ MySQL: Документация
#1071 - Specified key was too long; max key length is 767 bytes

Комментарии

Аватар пользователя Tinnka Tinnka 26 февраля 2012 в 4:03

Вопрос был решен ручками.. все ключевые поля varchar( 255 ) были изменены на varchar(128).
Все нормально импортировалось, но теперь вылезла другая ошибка:

Fatal error: Undefined class constant 'MYSQL_ATTR_USE_BUFFERED_QUERY' in /includes/database/mysql/database.inc on line 46

Коллеги, есть у кого-нибудь какие-то идеи?

Аватар пользователя Tinnka Tinnka 13 марта 2012 в 16:25

RxB wrote:
Вообще, конечно, прикольно заказчик использует шестой мускуль для продакшена, а вы должны его проблемы разруливать

ну и такое бывает.. к сожалению..

Аватар пользователя Tinnka Tinnka 11 марта 2012 в 21:35

Подводя итоги.. Делюсь, может быть кому нибудь пригодиться.

При переезде сайта с хостинга с версией MySQL 5.5, на хостинг с MySQL 6.0. пришлось выполнить следующие шаги:
1. В БД сайта все ключевые поля varchar( 255 ) изменить на varchar(128);
2. Установить на сервере хостера поддержку pdo+pdo_mysql;
3. Установить разрешения 077 для /sites/default/files (для папки и всего ее содержимого);
4. Настроить доступ к базе в /sites/default/settings.php;
5. Раздать права в phpMyAdmin;

Благодарю всех за помощь!
Тема закрыта.

Аватар пользователя 220v50hz 220v50hz 4 сентября 2015 в 15:44

Я сделал так. В PMA.

1. галки на всех таблицах в вашей базе, действие "Анализ таблицы"

2. Копировать из окна SQL запросов список имен всех таблиц, каждое имя таблицы будет отделено так { `имя_таблицы`, }

3. Вставить список в редактор Notepad++ и задаем поиск с заменой
сначала меняем { `, } на { CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; } или наоборот { CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci; } или как угодно, затем заменяем { ` } на { ALTER TABLE }
Перед "конверт" поставить пробел и после "альтер" пробел (importent).

4. получаем вот такой готовый список SQL запросов

ALTER TABLE tracker_user CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE trigger_assignments CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE url_alias CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE users CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE users_roles CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE variable CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE vef_video_styles CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE views_display CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE views_view CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE votingapi_cache CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;
ALTER TABLE votingapi_vote CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;

Запрашиваем и ува-ля иля вуа-ля

Аватар пользователя Netbioz Netbioz 19 декабря 2015 в 1:24

Хотя уже не актуально, но столкнулся с той же проблемой. Суть в том что у вас движок указан в дампе ENGINE = InnoDB, а при миграции на новый сервер скорее всего по умолчанию там стоит MYISAM что приводит к ограничению на длину в 1000 байт для поля `label` varchar( 255 ) - Поэтому когда вы изменили на 128 это сработало

Аватар пользователя bsyomov bsyomov 14 декабря 2016 в 13:56

Всё не совсем так...
innodb_file_format = Barracuda - deprecated начиная с 5.7
innodb_file_per_table = TRUE - не влияет на проблему, на самом деле.
innodb_large_prefix = TRUE - с 5.7.7( ну и естественно в 6), по умолчанию и так установлено.
Ну и работает это только для таблиц с row format DYNAMIC и COMPRESSED - это важно!

Т.е. решение не поможет вот так просто. Smile

А теперь интересный вопрос - до переноса-то как это работало? Smile

Аватар пользователя orb orb 16 января 2017 в 8:56

deprecated - и в чем проблема? В РНР половина функций еще с фиг знает каких времен депрекейтед и в Друпал 8 куча всего деприкейтед

«А теперь интересный вопрос - до переноса-то как это работало?»

До переноса оно работает на китайском сервере и продолжает там работать, но нужно локальную копию поднять