SWEB. Скрипт импорта базы для друпала.

Аватар пользователя gor gor 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_.txt1.23 КБ
0 Thanks

Комментарии

Аватар пользователя bsyomov bsyomov 25 февраля 2012 в 4:50

=) Я писал в своё время даже более продвинутый скриптик, который запоминал текущую табличку и последнее значение первичного ключа и который просто надо было запускать n-сят раз до победы над маразумом. Т.к. таблицы тоже могут быть довольно большими и тоже не успевать дампится в промежуток времени данный скрипту. А ещё потом всё выкачать это всё и собрать. М-м-м... =) Если найду - выложу сюда.
Вот в такие моменты и выясняется, зачем сисадмину надо знать хотя бы пару скриптовых языков. =)

Аватар пользователя cosmos cosmos 25 февраля 2012 в 11:02

хотел было переехать на sweb а тут его опустили ниже плинтуса
где хоститься теперь?
Вообще меня устраивал nic.ru но там не нравятся создание поддоменов
в урлах и путях появляется дебильный путь /subdmn/xxx

Аватар пользователя kodo kodo 25 февраля 2012 в 11:29

Переносил сайт клиенто с свеба. Перенес пхпМайАдмином, но намучался нереально, т.к. пришлось практически по таблице вытаскивать данные - процесс убивался, хотя база была отностильно не большой...

Аватар пользователя gorr gorr 25 февраля 2012 в 12:39

Пока что приходилось переносить клиентский сайт с одного аккаунта свеб на другой, проблем не возникло, но спасибо за информацию о радужных перспективах.

Аватар пользователя Chyvakoff Chyvakoff 25 февраля 2012 в 13:25
"bsyomov" wrote:

и последнее значение первичного ключа и который просто надо было запускать n-сят раз до победы над маразумом.

Ты извращенец)) А в целом-поддерживаю))

Аватар пользователя K0r5hun K0r5hun 25 февраля 2012 в 22:35

###поскипано###
SWEBу необходимо пересмотреть политику по предоставляемым/изменяемым настройками или их целевая аудитория - хаумпаги.

Аватар пользователя gor gor 25 февраля 2012 в 22:29

Чисто сердечно извиняюсь перед SWEB за свою эмоциональную реакцию.
Как сотрудник конкурентной компании - я поступил не профессионально.

У всех бывают проблемы. У нас тоже. Тут бы за себя ответить.

Пост подредактировал, убрал текст как либо негативно оценивающий деятельность этой компании.

Аватар пользователя xxandeadxx xxandeadxx 25 февраля 2012 в 22:40

а вторым сайпекс дампером пробовали? там много плюшек для работы с кодировкой

Аватар пользователя gor gor 25 февраля 2012 в 22:46
xxandeadxx wrote:

а вторым сайпекс дампером пробовали? там много плюшек для работы с кодировкой

да именно им и пробовал. Проблема в том, что он даже дамп не мог сформировать.

Аватар пользователя drupby drupby 26 февраля 2012 в 0:33
"gor" wrote:

да именно им и пробовал. Проблема в том, что он даже дамп не мог сформировать.

а к представителям хостинга обращаться пробывали ?
По-моему скромному мнению ,они смогли бы решить всё без скриптов .
хотя для друпала ваш хостинг - несомненно лучший .

Аватар пользователя gor gor 26 февраля 2012 в 1:02
"gor" wrote:

Дамп, что был предоставлен тех поддержкой был к сожалению тоже в двойной конвертации! И аналогично не готовый к восстановлению..

Аватар пользователя iryston iryston 27 февраля 2012 в 20:05

Я обычно, перед тем как установить друпал на свебе настраивал соединение с базой на utf8 через phpmyadmin
К нему доступ есть даже на шареде.

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 27 февраля 2012 в 20:13
"gor" wrote:

в /etc/my.cnf прописано init-connetc

connect

Я аналогичную задачу решал более радикально, через ssh форвардил port 3306 c удаленой машины на локальный debian. И там уже делал бэкап.

Аватар пользователя MAMONT MAMONT 1 марта 2012 в 13:06

Сколько себя помню, делаю экспорт и исморт БД небольшим php скриптом. Проблем никогда не бывает.
Sypex Dumper Lite 1.0.8 (http://sypex.net/news/06/10/14/5)
Существует также Sypex Dumper Pro 2.0.9, но мне он не понравился, нет в ней той простоты присущей первым версиям.
На все свои сайты создаю автоматом запароленную директорию с этим скриптиком.
Модуль backup_migrate и похожие не использую, так как приведенный мной скрипт считаю проще и надежнее.
Хотя это конечно на любителя. Может кому пригодится.

Аватар пользователя bsyomov bsyomov 1 марта 2012 в 13:08
"MAMONT" wrote:

Сколько себя помню, делаю экспорт и исморт БД небольшим php скриптом.

Во-первых в нормальном случае, делается штатным mysqldump, быстро и красиво.
А тут случай очень запущенный, и дампер бы не помог. Почитайте внимательно тред.

Аватар пользователя mamba mamba 2 марта 2012 в 16:49

Sypex Dumper Lite мне помогал из sweb сбежать.
Более новая версия не помогла, ошибки вылезали.
Перед этим очищал кэш через производительность.
Ну и еще можно таблицы с кэшем очистить через phpmyadmin.

Аватар пользователя APolitsin APolitsin 4 марта 2012 в 2:29
"gor" wrote:

Как сотрудник конкурентной компании

Всем рекомендую эту "конкурентную компанию" gor'a.
Держим там 40+ сайтов, всем довольны*, будем размещать ещё.

Со спайсвебом не сталкивался,
с niс.ru сталкивался много раз - это ад.

*навсякий случай ещё раз поноюсь про wkhtmltopdf =)

Аватар пользователя otmoroz otmoroz 7 марта 2012 в 13:34

а я делал Экспорт sql в файл. Потом открывал его -> CTRL+A -> CTRL+C, в импорте вставлял.

Аватар пользователя haver haver 12 марта 2012 в 22:14

У меня на sweb поблем с кодировкой дампа не наблюдается. Изначально соединение через phpMyadmin (как описано выше) не выставлял, но заливал базу sypex дампером и он видимо правильно выставил кодировку соеднения. Теперь даже если делать дамп с помощью mysqldump с кодировкой все в порядке.
То есть это не проблема SWEB.

А вот тайм лимит на запуск процессов это да... Когда база достигает размера 50+Мб процесс дампа начинает обрубаться через раз - "Killed". Базу 80 Мб уже вытащить целиком нельзя.

То что описывали выше http://drupal.org/project/backup_migrate действительно может решить проблему. В модуле Backup and Migrate по дефолту исключаются данные из таблиц кеша, watchdog и поисковый индекс. Структуру таблиц сохраняет, исключает только данные, поэтому дамп полностью рабочий, не нужно разбирать/собирать по кускам. Дамп становится меньше раза в 3-5 и укладывается в лимит свеба.

Только вот вопрос - поисковый индекс как то жалко выкидывать. Если потом востановится без него то
на сайте в несколько тысяч страниц он будет потом неделю лопатить чтобы востановить индекс и напрягаться будет бедняжка сервер грузить? Больше 50 страниц за запуск наверное лучше не выставлять ну и допустим запуск хрона раз в час.
Вопрос может кто посоветует - пригодится ли поисковый индекс или можно смело его выбрасывать?

Аватар пользователя bsyomov bsyomov 13 марта 2012 в 0:15

Его можно не дампить, несколько запусков крона и он восстановится. Можно для этого вручную несколько раз подряд запустить крон в конце концов. Сколько выставлять за запуск зависит от производительности.