16 мая 2007 в 11:48
Всем привет!
Возникла следующая ситуация:
Создал бэкап базы данных:
$ mysqldump dbname > ./file.sql
Разворачиваю обратно:
$ mysql < ./file.sql
ERROR 1062 (23000) at line 1364: Duplicate entry 'comment_default_' for key 1
Начинаю копать:
$ mysqld -V
mysqld Ver 5.0.32-Debian_3-log for pc-linux-gnu on x86_64 (Debian etch distribution)
Сравниваю полученый дамп с дампом, который использовался при инсталяции и виду что
Таблица variable (именно в нее не отрабатывает INSERT) в родном дампе создается с
`name` varchar(16) NOT NULL default ''
а в тот который получил я:
`name` varchar(48) NOT NULL default ''
Меняю в моем дампе ручками с 16 на 48 и все заливается на ура, но вот проблема:
Ни один пользователь теперь не может залогиниться.
На странице входа все время пишет:
Были указаны некорректное имя или пароль.
При этом я специально сделал:
UPDATE `users` SET pass = MD5('NewPass') WHERE uid=1;
Дамп снимал с работающего сайта!
Подскажите пожалуйста где проблема?
Комментарии
Не факт, что при дампе mysqldump dbname > ./file.sql он получился консистентным, если сайт при этом работал в штатном режиме. Надо либо предварительно отключать сайт, либо делать бэкап с параметром -l (lock-tables), а лучше всего так:
Также можно пробовать загонять ошибочный дамп обратно с параметром -f (force):
Тогда дубликаты ключей просто тихо проигнорятся. Чё-то есть сомнения, что mysqldump генерит другую структуру таблиц, может в период между инсталляцией и дампом делались апдейты сайта через update.php? В каком-то из апдейтов вполне вероятно сменили длину поля.
как можно выйти из ситуации?
есть ли возможность каким-то образом обнулить авторизацию или как-то отследить где косяк?
все равно не понимаю как записи привышающие varchar(16) моглин находиться в БД?
Если смотреть на содержимое этой таблицы то можно увидеть кучу строк с 'name' =
comment_default_xxxx, где xxxx - это та часть которая отличается
Кто-нибудь может вообще пояснить что это за таблица такая - variable? Для чего она вообще нужна?
Может вобще не в ней затык
Вот что получается при попытки реализовать предложенный метод:
$ mysql -f < ./1.sql
ERROR 1062 (23000) at line 1373: Duplicate entry 'comment_default_' for key 1
в таблице variable модули любят сохранять свои настройки.
По поводу dublicate было замечено, что возникает при залогиненных юзерах, согласен с axel что lock помочь должен.
И еще кодировка таблиц по умолчанию, чтобы не разбираться с мусором можно например сохранять и воссатнавливать через sypex скрипт, даже если таблицы в разной кодировке он корректно отрабатывает и если дошёл корректно, то уж раскроется обратно, только сами не забудьте выйти из юзеров, тогда можно и сайт не блокировать.
есть дамп который был снят без испльзования --opt
как его развернуть обратно?
Может у тебя старая таблица не трется перед заливкой? Опять-таки axel прав, надо бэкапить с --opt (вставляет также стирание таблиц перед созданием см. цитату из мана:
--opt Same as --add-drop-table --add-locks --all --extended-insert
--quick --lock-tables
)
и возможно с -Q (квотирование имен таблиц и полей) - но у тебя вроде с этим порядок.
Я уже делился своими наработками в этом: http://drupal.ru/node/4685
Скрипт работает и на линукс и на фрибсд хостинге
по поводу бэкапа я уже понял, что сплоховал, но все же я не могу понять каким образом мне теперь это пофиксить.
есть дамп снятый без использования --opt.
нужно вернуть все на место...
я справил varchar(16) на varchar(48) и дамп залился но на сайт залогиниться не дает! говорить что пароль или логин кривые... в базе юзеры есть. я проверял! и пароли менял, указаным выше способом!
как очистить... думаю раз эта таблица хранит информацию о настройки модулей то возможно там кривые записи относящиеся к модулят отвечающим за аутентификацию?
может как-то можно почистить всех юзиров и настройки всех этих модулей?
ну типа привести их в некое исходное состояние
Нажми при входе сбросить пароль - на malo придет временная страница по ней введешь новый
страничка не пришла
Плохо, если есть возможность запустить локально под DENWER ом, то у него письма складываются локально ( можно исключить почтовую пересылку) - возможно вариант решения
прикрутил новый drupal
создал там нового пользователя и по честям туда базу закачал....
вроде бы все работает теперь.
всем огромное спасибо