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.
Буду благодарна за любые разумные рекомендации.
--
-- База данных: `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
Комментарии
Вопрос был решен ручками.. все ключевые поля varchar( 255 ) были изменены на varchar(128).
Все нормально импортировалось, но теперь вылезла другая ошибка:
Коллеги, есть у кого-нибудь какие-то идеи?
Как вариант попробовать залить дамп напрямую через ssh. Если его нет - просить админов/саппорт это сделать. Вот тут несколько решений описано.
спасибо, посмотрю
Вообще, конечно, прикольно заказчик использует шестой мускуль для продакшена, а вы должны его проблемы разруливать
ну и такое бывает.. к сожалению..
Подводя итоги.. Делюсь, может быть кому нибудь пригодиться.
При переезде сайта с хостинга с версией 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;
Благодарю всех за помощь!
Тема закрыта.
Я сделал так. В 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;
Запрашиваем и ува-ля иля вуа-ля
Хотя уже не актуально, но столкнулся с той же проблемой. Суть в том что у вас движок указан в дампе ENGINE = InnoDB, а при миграции на новый сервер скорее всего по умолчанию там стоит MYISAM что приводит к ограничению на длину в 1000 байт для поля `label` varchar( 255 ) - Поэтому когда вы изменили на 128 это сработало
innodb_file_format = Barracuda
innodb_file_per_table = TRUE
это где нужно написать?
Всё не совсем так...
innodb_file_format = Barracuda - deprecated начиная с 5.7
innodb_file_per_table = TRUE - не влияет на проблему, на самом деле.
innodb_large_prefix = TRUE - с 5.7.7( ну и естественно в 6), по умолчанию и так установлено.
Ну и работает это только для таблиц с row format DYNAMIC и COMPRESSED - это важно!
Т.е. решение не поможет вот так просто.
А теперь интересный вопрос - до переноса-то как это работало?
на локале openserver работает Drupal 8 молча.
при переносе на хостинг не импортируется база
deprecated - и в чем проблема? В РНР половина функций еще с фиг знает каких времен депрекейтед и в Друпал 8 куча всего деприкейтед
«А теперь интересный вопрос - до переноса-то как это работало?»
До переноса оно работает на китайском сервере и продолжает там работать, но нужно локальную копию поднять
Мне помогло вот это:
SET GLOBAL default_storage_engine = 'InnoDB';И импорт дампа через терминал (а не через pma).
«
это где нужно написать?
»
Файл конфигурации мускула my.cnf