Спас мир?)

JuraS, Та я просто предусмотрительно сделал свой бекап. Настрочил скриптик, который считывает таблицы строку за строкой и каждую строку пишет в файл в виде insert-запроса, каким данные обычно добавляются. Просто чтобы при восстановлении, считывать поочерёдно каждую строку и передавать её mysql_query().

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

А натолкнул меня на эту светлую мысль тот факт, что на локальном сервере такая же фигня была, при использовании встроенного бекапера СУБД. Ему пофиг на кодировку таблиц, он всё равно дамп в latin1 пишет. В результате получается бяка.

Кстати, нашёл на эту тему забавную статью на хабре, надо будет потом поэксперементировать.
habrahabr.ru/post/137061/


Спас мир?)

Мир не мир, но было бы плохо, т.к. мне через ~20 часов надо систему заявок открывать.)))
vk.com/wall-10188014_11241

И хорошо что есть нормальный бекап, иначе всё было бы ооочень печально.

А пока что там висит моя мимимишная заглушка.)))
cabinet.tanibata.ru/

лень хабр читать. Что, мухля разных версий и ошибка с коллейшном?

sam_banshee, Та там коротенькая статья совсем.

Если кратко, то суть в том, что встроенному бекаперу пофиг на кодировку таблиц, он все пишет как latin1 (cp1252).
Учитывая особенности кодировок, для лечения надо сделать два шага:
1) Скормить сторку iconv, выдавая её за utf8 и с желанием получить cp1252.
2) Получившуюся строку опять же скормить iconv, только в этот раз выдать её за cp1251 и преобразовывать в utf8.
Учитывая особенности всех трёх кодировок, вроде должно получиться гуд. Но сам не проверял пока, мне есть чем сейчас заниматься.
Вот настрою всё, тогда играться буду. Если работает, то значит будет полезная плюшка в копилку знаний.)

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

ОМГ, на чем написан сайт-то?
У нас Джанго все это в автоматическом режиме делает.
К сожалению, мусора из-за этого завались >_<

JuraS, ОМГ, на чем написан сайт-то?

А причём здесь это вообще? Тут проблема в том, что mysql'ный дампер всё в latin1 пишет, а не в той кодировке, в какой данные. На чём и как написана система тут как бы роли, имхо, вообще не играет.


У нас Джанго все это в автоматическом режиме делает.

Что именно? Правит битую кодировку?


А так, усё на чистом php + js + css + html. Ибо не люблю пользоваться тем, в чём не разбираюсь и что слишком монструозно.
У меня только одна заимствованная функция - для отправки e-mail-рассылки. Ибо там с сокетами работа, а я не особо възжаю.
Но там понятно расписано, что куда, так что я просто передаю свои данные и письма разлетаются куда надо.
А всё остальное - моё. Пусть, может где-то и не кошерно, но зато я знаю что за что отвечает и куда в случае чего лезть.

Я так и думал.
Проблема в том, что кодировка в базе cp1251 вместо utf-8 изначально - или на уровне сосздания базы, или на уровне настроек, или обновлялись с мухли 4.х, например.
Если изначально в базе полноценная кодировка - достаточно выставить правильные настройки базы.

Аще, главное правило веб разработчика - все должно быть в UTF-8.
Или системный администратор его убьет.

sam_banshee, Проблема в том, что кодировка в базе cp1251

А вот и нихренашеньки. У меня и все скрипты в utf8 без BOM, и все таблицы в utf8_general_ci. Я за этим строго слежу, так что не надо тут на таблички гнать. Всё нормально было, пока на новый хостинг не перетащили.

надо будет потом поэксперементировать.

А вот нихренашеньки это не работает.

Ryuzaki_rnd, значит проблема или в том, как сделан бекап, или в том, как была настроена база, или в том, как она настроена.
Кстати, если честно, мухля конечно самая простая база, но постргес заметно надежнее.

sam_banshee, больше похоже, если честно, не на прроблему дампа, а проблему при импорте.

sam_banshee, больше похоже, если честно, не на прроблему дампа, а проблему при импорте.

Ну, кстати, может и так. Просто я, когда на локалке игрался, открывал дамп редактором, нормальным, и всё равно кракозябры были. Так что я встроенному дамперу не особо доверяю. Но да, возможно дело при импорте было. Тут уж не знаю.

В данный момет меня больше напрягает прослойка в виде nginx'а, который, сцуко, постоянно рвёт соединение. И в итоге я не могу свой бекап накатить, ибо Server is time out. Чо делать, сижу и перетаскиваю ручками 48к запросов. Слава богу, 1000 вроде успевает обработать. Так что... 48 заходов и бекап накатится.(((

А вообще, всё жопа.

Ryuzaki_rnd, встроенный дамп, если на стороне базы все ок, хоть японские иероглифы делает. Если они правильно в базу забиваются, а не в каком-то полуконвертироанном виде из расчета на коллейшн.
с энджинкосм странно. У тебя есть над ним контроль? перекатить файло на сервер и оттуда работать?

sam_banshee, Ну, как я понял, там как-то так забавно mysql настроена, что несмотря на поголовный utf8_general_ci, соединение она в какой-то другой кодировке делает. Прописал после каждого mysql_connect set names 'utf8'. Теперь работает всё вроде нормально.
Но опять же, из моего бекапа. Из того, который встроеным дампером делался, как были письмена даэдров, так и остались.

Над нджиксом у меня контроля нет. У меня вообще единственный контроль, это .htaccess, но это уже на конечном сервере. А промежуточный мешает. Захотел бекап свой залить. Ок, залил по ftp файлик, накатал скрипт, запустил, думаю сча ок, накатится будет зашибись. А вот хрен там. Апачу то пофиг, ему в .htaccess'е прописано, он и не парится по поводу времени выполнения скрипта. А nginx видимо очень быстро устаёт ждать ответа от апача и на 1:15 (несколько раз проверял) тупо обрывает связь. Server is Time Out. И хоть ты что делай. Пришлось свой бекап (48к инсертов) скармливать через вебморду по тысяче за раз. Ибо чуть больше и опять таймаут. Около полутора часов ушло.(((

Вообще, с nginx'ом у нас и на предыдущем сервере заморочка была, но тогда владелец железки чего-то там подкрутил и nginx заткнулся в тряпочку.

А с бекапом весело получилось, залился мой, pma его сразу приняло, сразу подхватило русский текст, всё ок. Но в самой системе - ??? ???? ? ?? ?????? ?? ???? ?. Такая вот байда. Только set names'ом и решилась.



перекатить файло на сервер и оттуда работать?

Ты о чём конкретно? Просто так, у меня все скрипты и самописная админка и так на сервере лежат. И все соединения для записи в бд идут на localhost.

Ryuzaki_rnd, я имел в виду, что если ssh есть просто mysql -u ... -p < dump.sql

sam_banshee, А я очередной раз повторяю, что встроенный дампер меня не устраивает. Описанным выше способом и делался тот бекап, который в итоге не рабочий. И на локальном серве он также делает бекап не самым лучшим способом.

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

описанным выше способом делается импорт. Он делается не через "дампер", а через выполнение всех SQL команд в базе через клиент базы. Конечно, клиет можно умудриться очень криво настроить, но это уже другая история. Если ты не доверяешь клиентской части базы данных, причем официальной, то и пользоваться ей не нужно, ибо сервер будет еще хуже. Собственно, клиент использует те же способности, что твой php драйвер, выполняя те же команды, ты просто перенаправляшь импорт в них. Даже протокол один и тот же.

"дампер" - mysqldump - это уже другое дело. Им конечно надо уметь пользоваться, но он официальный версии с четвертой, и его единственный полноценный недостаток в том, что он умеет делать бэкап только в одном потоке. Если тебе надо лочить таблицы перед дампом и у тебя огромные базы, это раздражает, но была еще и параллельная реализация, не помню уже названия.

Так вот, за долгие годы работы у меня не возникало таких проблем, как у тебя, на многогигабайтовых базах данных. Этим же "дампером" делались бэкапы, и там был и китайский, и японский, и куча других языков, которые умещаются только в utf-8. Кириллица там была тем более. Один раз проблема возникал в связи с миграцие базы с 4 на 5, и то, только потому, что разработчики непойми что писали. Кстати, PMA тоже будет использовтаь те же способности mysql клиента.

sam_banshee, А, туплю. Да, всё верно, ты за импорт писал. Я чего-то непроснувшись подумал, что ты мне создание дампа написал. Сорри.