Как восстановить некорректно сконвертированную базу?

[gunnar]

Добрый вечер.

Давно я тут не был. И проблемы стали куда глубже ;(

В общем, по факту имеем 3 базы и 3 форума на IPB 1.3.1 free.

Все 3 базы выше 30Мб каждая, таблица _posts от 10Мб и выше.

Перед отпуском примечено, что phpmyadmin 2.8.0.2 не формирует базу при Export как в открытом выше, так и в .zip, при этом моя ошибка, она же и единственная - не проверил содержимое .gz, в этом формате базы сохранились, но не законченные (см. в одной базе):

CREATE TABLE `vit_warn_logs` (
 `wlog_id` int(10) NOT NULL auto_increment,
 `wlog_mid` mediumint(8) NOT NULL default '0',
 `wlog_notes` text NOT NULL,
 `wlog_contact` varchar(250) NOT NULL default 'none',
 `wlog_contact_content` text NOT NULL,
 `wlog_date` int(10) NOT NULL default '0',
 `wlog_type` varchar(6) NOT NULL default 'pos',
 `wlog_addedby` mediumint(8) NOT NULL default '0',
 PRIMARY KEY  (`wlog_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=3;

-- 
-- ╨Ф╨░╨╝╨┐ ╨┤╨░╨╜╨╜╤Л╤Е ╤В╨░╨▒╨╗╨╕╤Ж╤Л `vit_warn_logs`
-- 

INSERT INTO `vit_warn_logs` VALUES (1, 338, '<content>├О├╖├е├н├╝ ├╡├о├░├о├╕├и├й ├о├б├░├а├з ├н├а ├┤├о├░├│├м├е.  ├Т├╗ ├м├о├л├о├д├е├╢! ├▓├а├к ├д├е├░├ж├а├▓├╝!</content><mod>,d,</mod><post>,d, </post><susp>,d</susp>', 'pm', '<subject>├З├а ├з├а├▒├л├│├г├и ├п├е├░├е├д ├о├▓├е├╖├е├▒├▓├в├о├м :)</subject><content>├Я ├п├о├в├╗├▒├и├л├а ├▓├е├б├е ├░├е├й├▓├и├н├г :) ├Н├а├▒├▓├┐</content>', 1143363785, 'neg', 13);
INSERT INTO `vit_warn_logs` VALUES (2, 72, '<content>├П├░├о├в├е├░├к├а! )</content><mod>,d,</mod><post>,d, </post><susp>,d</susp>', 'none', '', 1143448993, 'neg', 11);

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

 

В чем же причина "сбоя" текущего. Уходя в отпуск, заказал у хостеров перенос с их "международного" хранилища на их же, но местное (много шустрее доступ). И уехал на 2 недели. Приезжаю.... м-дя, весь форум отображается знаками "??????????????", как темы, так и сообщения, ну т.е. все кириллические символы. Потребовал текущую базу, глянул, а там в _posts реально данные в "?????????". Потребовал резервные копии - то же самое. Кенты делают бэкапы ежедневно неделю, потом данные перезаписываются. А прошло уже 1.5 недели. Резонный вопрос - а где копия "системная" до момента конвертации, в принципе это общепринятая технология. Но в данном случае "базы не нашлись".

 

И теперь без воды конкретика:

1) на старом хостинге настройки MySQL таковы, что

character set client	utf8
(Глобальное значение)	latin1
character set connection	utf8
(Глобальное значение)	latin1
character set database	latin1
character set results	utf8
(Глобальное значение)	latin1
character set server	latin1
character set system	utf8
character sets dir	/usr/share/mysql/charsets/
collation connection	utf8_unicode_ci
(Глобальное значение)	latin1_swedish_ci
collation database	latin1_swedish_ci
collation server	latin1_swedish_ci

Сразу скажу - после того, как я это увидел, меня охватил тихий ужас... Впрочем, наверное это реальная практика с кодировками в мире, для меня же понятно одно - ко хрена моя база в кодировке cp1251 жила год в latin1 без никаких намеков на ошибки?

2) На новом хостинге:

character set client	utf8
(Глобальное значение)	cp1251
character set connection	utf8
(Глобальное значение)	cp1251
character set database	cp1251
character set results	utf8
(Глобальное значение)	cp1251
character set server	cp1251
character set system	utf8
character sets dir	/usr/share/mysql/charsets/
collation connection	utf8_unicode_ci
(Глобальное значение)	cp1251_general_ci
collation database	cp1251_general_ci
collation server	cp1251_general_ci

не придирешься

3) при переносе хостеры _заметили_, что мои базы чудным образом не читабельны (т.е. там даже не UTF-8 и не latin1, а какой-то микс), но их задача четко стояла запустить базы на новом сервере. Системными фишками MySQL они сконвертировали базы "как есть", не проверили и запустили. Ясно, что я проверить не мог, ну а они ...

 

В итоге вопросы:

1) в чем был не прав я? как надо было забекапить базы до отпуска, дабы иметь четкую и законченную базу форума на тот момент? (учитывая вопросы - да, я прочекал и пофиксил базы до Экспорта)

2) как сделать базу кириллической, дабы ее перенести на новый хостинг? (учитывая неудачный опыт сисадминов у хостера) И что за кодировка у баз текущих, исходя из того, что я сказал выше (MySQL - UTF8, base - latin1, script base - cp1251).

3) этический вопрос - кто все же не прав больше: я, пустивший многое на самотек и уповая на хостеров, к тому же не проверивший базу или же хостеры, которые не могут восстановить мне базы на тот момент и у них нет резервных копий?

4) возможно ли восстановить текущую базу или же ее лучше грохнуть "от глаз подальше"?

5) Как "закрыть" базу, дабы ее "скюшал" phpmyadmin без вопросов (на нынешнюю версию ругается, гад)?

 

Спасибо за ваши советы...

[Song]

Виноват ты в том, что у тебя на старом использовался utf. Не знаю зачем это тебе было нужно.

На новом хостеры создали БД как надо, но она уже не сможет работать с utf.

Надо её пересоздавать.

 

>> я меня же понятно одно - ко хрена моя база в кодировке cp1251 жила год в latin1 без никаких намеков на ошибки?

 

она жила в uft8, а не в cp1251.

Русские символы можно записывать не только в кириллице, но ещё и в юникоде. И всё будет чудно записываться, только памяти будет занимать ровно в 2 раза больше и + будут глючить некоторые функции, связанные с ограничением по длине символов.

[gunnar]

2 Song: Твой ответ понятен. Но факт в том, что не я создаю базы на том хостинге. Вернее, правильно будет сказать, что я не могу инсталлятором создать базу. Она создается в cpanel без указания какой-бы-то-ни-было кодировки. Затем инсталлятор создавал таблицы, но уже в кодировке базы. А кодировку баз четко забили хостеры при настройках MySQL. Такие же проблемы и у других клиентов того хостинга.

Да, кстати, а вот как можно поменять кодировку "клиента" MySQL используя phpmyadmin? Понятное дело, я там не нашел такой функции.

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

Т.е. по сути все системные переменные SQL задают хостеры. На старом хостинге у них UTF8/latin1, на новом учли прошлые баги и сделали с поддержкой кириллицы (см. сообщение (1)). Переменные я поменять не могу, а тем более что нету ssh-доступа.

Таким образом я объяснил, что мне нафиг тот UTF не нужен был. Это чистая "прерогатива" хостеров, о чем они мне и сказали. Моя ошибка в том, что я ставлю форумы, при этом не зная php, во многом "методом догадок" и во многом успешно, а в итоге в определенный момент выявляются "подводные течения". Понятно, что отныне я 100 раз буду проверять, как и что настроено у хостеров.

Насчет неработы на новом - в оригинале да, конечно. Но ведь можно и сконвертить? Кстати, там еще остался 4-й проект, который не трогали, база большая, phpmyadmin как написано выше, глючит. Но почему тогда скрипт от zapimir все четко выдал мне в кириллице (т.е. база читабельна)? Получается, что нельзя юзать phpmyadmin?

 

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

И все же вопрос остается - текущая база это уже "мертвая" (со знаками???) или же из нее можно вытащить данные? Например, мне не ясно, почему при декодировании с юникода MySQL не только не меняет кодировку, но и все данные заменяет на "????". Нонсенс! Скоко раз менял кодировки файлов EditPlus, ни разу он мне таких выбрыков не давал...

Да, и пока я общаюсь с хостерами, что мне им сказать, дабы таких проблем не было у других их клиентов (я знаю точно, что 2 моих товарища держат у них же форумы... боюсь у них даже спрашивать о кодировках...)?

И напоследок главное - как мне корректно "закрыть" SQL-dump (см. 1-й код), дабы прошел процесс создания баз?

[Song]

Не обязательно создавать базу только используя линки cpanel.

Есть в MySQL запрос CREATE DATABASE params

в params имя, кодировки, регистр и т.д.

чего мешает так создать?

насчёт параметров смотри доку.

Вообще-то phpmyadmin создаёт базу через "Создать БД" и даёт выбрать все параметры из списка, при этом пишет выполняемый запрос со всеми параметрами, так что если интересно какие параметры приводят к каким кодировкам можно тут же и посмотреть.

[gunnar]

Не обязательно создавать базу только используя линки cpanel.

Есть в MySQL запрос CREATE DATABASE params

в params имя, кодировки, регистр и т.д.

чего мешает так создать?

насчёт параметров смотри доку.

Вообще-то phpmyadmin создаёт базу через "Создать БД" и даёт выбрать все параметры из списка, при этом пишет выполняемый запрос со всеми параметрами, так что если интересно какие параметры приводят к каким кодировкам можно тут же и посмотреть.

 

Дело в том, что с базами я работать-то умею И создавать умею.

Но не знаю, что накрутили хостеры, однако пользователь admin не имеет права создавать базы. Чтобы не быть голословным:

 

Вот код запроса, корректный:

CREATE DATABASE test CHARACTER SET cp1251 COLLATE cp1251_general_ci

 

А вот и ошибка:

Ошибка

SQL-запрос:

CREATE DATABASE test CHARACTER SET cp1251 COLLATE cp1251_general_ci

Ответ MySQL: Документация
#1044 - Access denied for user 'shansua'@'localhost' to database 'test'

 

ХЕЗ, как они там настроили, но в phpmyadmin я могу заходить лишь под админом, а админа базы задаем в cpanel, но уже после создания базы... Вот и вопрос - как создавать базы...

 

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

[Song]

Не хватает прав на создание БД.

А при чём тут cp1251?

 

Я ж тебе говорю, что теперь тебе единственный выход - это создавать БД в unicode.

[gunnar]

Не хватает прав на создание БД.

А при чём тут cp1251?

 

Я ж тебе говорю, что теперь тебе единственный выход - это создавать БД в unicode.

 

Привет.

Я-то понимаю, что не хватает прав на создание. Но ты где-то еще видел, чтобы Админ не имел права создавать базы? Я - нет, ни разу такого не видел...

cp1251 - это как пример От смены кодировки принципы создания баз не меняются...

 

Знаю, что нужно в юникоде, никаких проблем. Самое интересное, что я по жизни задаю вопросы, потом сам же на многие нахожу ответ В данном случае - базы оказались завершенными, несмотря на мои подозрения. Но не становятся базы совсем по иной причине. Первая база - 52 Мб, вторая - 68 Мб. При том, что у хостеров (или это требования MySQL 4.1?) стоят ограничения на макс размер дампа 51,200 Мб. Теперь возникает вопрос - как же это все работало???? Самое интересное, что я был в команде админов на форуме ОРТ еще когда форум был на движке 1.3.1 и точно помню, что база была явно больше 100Мб. Так что ограничения MySQL тут ни при чем...

И вот еще возник вопрос по ходу - можешь дать ссылку на тему (думаю, что должна быть), где четко расписывается, как правильно "архивировать" базы. Например, если все же требование в 51 Мб на базу не высосан из пальца, то я бы перенес закрытые темы в одну базу, открытые оставил текущей, а форум работал бы с обеими базами! О как

 

И, между прочим, до сих пор не могу понять, почему разработанный хорошей группой скрипт phpmyadmin "уступает" таким "детям" как Sypex Dumper? Причем по всем статьям! Потому как первый сдампил базу "как есть", а второй уже все сделал как надо, в кириллицу.

И, кстати, второй вариант перевода Юникода в кириллицу - Админка IPB, тоже все делает как надо.

Правда, в обоих вариантах если затем "подлаживать" phpmyadmin'u, то заменить везде текст latin1 на cp1251.

[Song]

>> Я-то понимаю, что не хватает прав на создание. Но ты где-то еще видел, чтобы Админ не имел права создавать базы? Я - нет, ни разу такого не видел...

 

везде видел. Админ - ты да, но админ ты только форума! А не всего сервера. Админ сервера, тот у которого доступ к логину "root" может тебе давать права или не давать. Обычно на хостингах руты запрещают доступ на создание и дропанье баз. А цпанели специально настроены так, чтобы делать свои действия от имени рута. Тебе нужно с хостером разговаривать.

А если ты и есть хостер тогда смотри гранта на БД.

[gunnar]

Аха, вот нашел ответ по вопросу баз:

http://www.ibresource.ru/forums/index.php?...mp;#entry176709

судя по всему, форум может работать со сколь угодно большими базами (кстати, а все же какой максимальный объем?), а 50 Мб - это ограничение phpmyadmin, и только его.

 

Ясно, попрошу у хостеров такую возможность... Я - не хостер