25 февраля 2012 в 4:02
Суть проблемы - в /etc/my.cnf прописано init-connetc="SET NAMES cp1251"
Для тех, кто не вкурсе - друпал делает SET NAMES UTF8
Соответственно если просто попытаться сделать mysqldump - то получим UTF8 символы интрепетерированые в cp1251. Восстановлению такая база не подлежит.
Использование ключей --default-character-set, --no-set-names , --set-charset ни к чему не приводят.
Так как сервер после инициации соединения, переключает кодировку на cp1251.
С sxd проблемы - у него не получается сделать дамп. В причина не смог разобраться. Возможно лимит памяти.
Дамп, что был предоставлен тех поддержкой был к сожалению тоже в двойной конвертации! И аналогично не готовый к восстановлению.
Способ вытянуть базу в таком случае приложенный скрипт.
Инструкция по применению:
1) зайти по SSH - залить скрипт, прописать в него нужные данные
2) вызвать командой php script.php > dump.sql
Возможные проблемы: если у вас большая база.. то вы увидите сообщение killed!
В таком случае надо подправитьс крипт на то, чтоб делать дамп каждой таблицы отдельно - это дополнительный параметр в строке:
backup_tables('localhost','username','password','dbname','TABLE_NAME');
TABLE_NAME - заменить на имя таблицы.
Надеюсь это кому-то поможет если возникнет подобная проблема экспорта базы данных.
| Вложение | Размер |
|---|---|
 sweb-dump.php_.txt | 1.23 КБ |
Комментарии
это звучит издевательски)
Вот в такие моменты и выясняется, зачем сисадмину надо знать хотя бы пару скриптовых языков.
хотел было переехать на sweb а тут его опустили ниже плинтуса
где хоститься теперь?
Вообще меня устраивал nic.ru но там не нравятся создание поддоменов
в урлах и путях появляется дебильный путь /subdmn/xxx
Переносил сайт клиенто с свеба. Перенес пхпМайАдмином, но намучался нереально, т.к. пришлось практически по таблице вытаскивать данные - процесс убивался, хотя база была отностильно не большой...
Пока что приходилось переносить клиентский сайт с одного аккаунта свеб на другой, проблем не возникло, но спасибо за информацию о радужных перспективах.
Ты извращенец)) А в целом-поддерживаю))
###поскипано###
SWEBу необходимо пересмотреть политику по предоставляемым/изменяемым настройками или их целевая аудитория - хаумпаги.
Чисто сердечно извиняюсь перед SWEB за свою эмоциональную реакцию.
Как сотрудник конкурентной компании - я поступил не профессионально.
У всех бывают проблемы. У нас тоже. Тут бы за себя ответить.
Пост подредактировал, убрал текст как либо негативно оценивающий деятельность этой компании.
а вторым сайпекс дампером пробовали? там много плюшек для работы с кодировкой
да именно им и пробовал. Проблема в том, что он даже дамп не мог сформировать.
Модуль http://drupal.org/project/backup_migrate решит проблемы и причем с использованием UI.
а к представителям хостинга обращаться пробывали ?
По-моему скромному мнению ,они смогли бы решить всё без скриптов .
хотя для друпала ваш хостинг - несомненно лучший .
Я обычно, перед тем как установить друпал на свебе настраивал соединение с базой на utf8 через phpmyadmin
К нему доступ есть даже на шареде.
connect
Я аналогичную задачу решал более радикально, через ssh форвардил port 3306 c удаленой машины на локальный debian. И там уже делал бэкап.
давно оттуда съехал и всех клиентов тоже перевел к другому хостеру
фух. я думал на патруле так базы придется дампить. а, sweb. sweb..
Сколько себя помню, делаю экспорт и исморт БД небольшим php скриптом. Проблем никогда не бывает.
Sypex Dumper Lite 1.0.8 (http://sypex.net/news/06/10/14/5)
Существует также Sypex Dumper Pro 2.0.9, но мне он не понравился, нет в ней той простоты присущей первым версиям.
На все свои сайты создаю автоматом запароленную директорию с этим скриптиком.
Модуль backup_migrate и похожие не использую, так как приведенный мной скрипт считаю проще и надежнее.
Хотя это конечно на любителя. Может кому пригодится.
Во-первых в нормальном случае, делается штатным mysqldump, быстро и красиво.
А тут случай очень запущенный, и дампер бы не помог. Почитайте внимательно тред.
Sypex Dumper Lite мне помогал из sweb сбежать.
Более новая версия не помогла, ошибки вылезали.
Перед этим очищал кэш через производительность.
Ну и еще можно таблицы с кэшем очистить через phpmyadmin.
Всем рекомендую эту "конкурентную компанию" gor'a.
Держим там 40+ сайтов, всем довольны*, будем размещать ещё.
Со спайсвебом не сталкивался,
с niс.ru сталкивался много раз - это ад.
*навсякий случай ещё раз поноюсь про wkhtmltopdf
а я делал Экспорт sql в файл. Потом открывал его -> CTRL+A -> CTRL+C, в импорте вставлял.
У меня на sweb поблем с кодировкой дампа не наблюдается. Изначально соединение через phpMyadmin (как описано выше) не выставлял, но заливал базу sypex дампером и он видимо правильно выставил кодировку соеднения. Теперь даже если делать дамп с помощью mysqldump с кодировкой все в порядке.
То есть это не проблема SWEB.
А вот тайм лимит на запуск процессов это да... Когда база достигает размера 50+Мб процесс дампа начинает обрубаться через раз - "Killed". Базу 80 Мб уже вытащить целиком нельзя.
То что описывали выше http://drupal.org/project/backup_migrate действительно может решить проблему. В модуле Backup and Migrate по дефолту исключаются данные из таблиц кеша, watchdog и поисковый индекс. Структуру таблиц сохраняет, исключает только данные, поэтому дамп полностью рабочий, не нужно разбирать/собирать по кускам. Дамп становится меньше раза в 3-5 и укладывается в лимит свеба.
Только вот вопрос - поисковый индекс как то жалко выкидывать. Если потом востановится без него то
на сайте в несколько тысяч страниц он будет потом неделю лопатить чтобы востановить индекс и напрягаться будет бедняжка сервер грузить? Больше 50 страниц за запуск наверное лучше не выставлять ну и допустим запуск хрона раз в час.
Вопрос может кто посоветует - пригодится ли поисковый индекс или можно смело его выбрасывать?
Его можно не дампить, несколько запусков крона и он восстановится. Можно для этого вручную несколько раз подряд запустить крон в конце концов. Сколько выставлять за запуск зависит от производительности.