[Проблема]

Добрый день!

Форум 3.8.7. Работает, но есть проблема - нарушена целостность базы данных.

Краткая предыстория.
Не смог зайти на форум под админом, проверил таблицу базы юзеров, не нашёл там админской записи. Пропала. Начал трясти хостинг-провайдера, подняли мне последний бэкап, там админская запись была на месте, восстановил, успокоился. Через некоторое время стали поступать жалобы от пользователей, что не могут залогиниться. Стал проверять, оказалось, что было удалено или пропало много пользователей, учитывая то, что автоудаление на форуме отключено. Ещё через некоторое время обнаружилось, что у некоторых пользователей утеряна взаимосвязь с постами. Т.к. юзер существует, его посты существуют, но связи нет. Статус юзера в постах отображается как удалённый или незарегистрированный, соответственно, у пользователя в статистике ноль тем и сообщений. Из-за того, что пользователей и сообщений на форуме было много, проблема обнаружилась не сразу. Подозреваю, что у хостера были проблемы с целостностью данных, но он об этом умолчал, т.к. другой версии потери данных нет. Сейчас форум продолжает работу, регятся пользователи, создают сообщения. Т.к. база накоплена приличная, перезапускать форум с нуля как-то неохота, но при этом остаётся ощущение, что форум теперь нездоровый, где-то что-то не в порядке, а где - непонятно. Соответственно, вопрос - как жить дальше? Что можно или нужно предпринять в данной ситуации?

В частности, но не ограничиваясь:

1. Возможно ли как-то проверить целостность самой базы данных, что все таблицы и поля на месте?
2. Для чего нужен пункт в админке - Обслуживание - Восстановить/оптимизировать таблицы? Для чего или после чего необходимо восстановление таблиц и поможет ли это мне в чём-нибудь?
3. Имеет ли смысл вручную восстанавливать связи пользователей и сообщений? Есть ли какие-то автоматические средства, которые могут восстановить подобные нарушения связей?
4. Можно ли считать, что потеряны только пользовательские данные, а функционал форума не нарушен и продолжить работу, закрыв на эту потерю глаза?

Спасибо!

@Advantech, интересная ситуация... но не слишком экзотичная
для начала, прямо сейчас попробуйте сделать следующее:
- откройте пару страниц каких-то тем, где есть такие посты - которые как бы от юзеров, но "утеряна взаимосвязь" - просто чтобы видеть результат после выполнение процедуры
- сама процедура: Админка - Обслуживание - Обновление счётчиков
там найдите пункт Восстановить повреждённые профили пользователей и нажмите на кнопочку
это штатная процедура, проходит достаточно быстро
и проверьте, что получилось - в тех темах, которые были заранее открыты

поможет - хорошо, не поможет - будем думать дальше

у меня к Вам ещё будет пара вопросов, потом

Luvilla, сделал всё, как Вы написали, кроме этого дополнительно запустил:
- Обновить статусы пользователей (ничего не изменилось);
- Перестроить кэш сообщений (ничего не изменилось);
- Обновить имена пользователей (ничего не изменилось);
- Исправление уникальных индексов (всё индексы исправны);
- Восстановить/оптимизировать таблицы (все таблицы в порядке).

В общем, понял, что придётся шариться в таблицах. Открыл таблицу post, вижу там следующее - для вышеуказанных тем есть поле username - имя пользователя и поле userid - 0 (а должно быть не 0). Хорошо, что в этой таблице есть избыточность данных в виде поля username. Вытащил вручную userid из таблицы user для данного username (select userid from user where username = 'xxx'), сделал update таблицы post и пользователь в теме восстановился (update post set userid = 'yyy' where username = 'xxx';). Модифицировал запрос следующим образом: update post set userid = (select userid from user where username = 'xxx') where username = 'xxx';

Потом сделал select distinct username from post where userid = '0';, вылезло 466 пользователей (из более чем 3000), чьи взаимосвязи с постами утерялись. Насколько мне известно, sql циклы не поддерживает, поэтому придётся вручную запускать запрос для каждого юзера. Программинг-то я уже подзабыл.

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

А какие у Вас ещё были вопросы? ;)

Originally Posted by Advantech

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

за то PHP поддерживает, можно написать скрипт и запустить.

Originally Posted by Advantech

Насколько мне известно, sql циклы не поддерживает

Поддерживает, но лучше и правда скрипт написать.

Originally Posted by Advantech

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

Нет, конечно нельзя.
Если это какой-то сбой в БД (во что лично мне не очень верится), то вряд ли он избирательно ограничился удалением записей в таблице user и частичным обнулением userid в таблице post.
Но для меня это больше похоже на специальную или случайную порчу. Поэтому, как минимум, хостинг я бы сменил, плюс проверил бы сайт на наличие дор-шелов и прочих атрибутов несанкционированного доступа.

Originally Posted by eska

Если это какой-то сбой в БД (во что лично мне не очень верится), то вряд ли он избирательно ограничился удалением записей в таблице user и частичным обнулением userid в таблице post.

+ 1!
действительно, очень уж странно

// хотя... не так давно на одном из форумов, за который я "присматриваю", произошёл довольно интересный глюк: был сбой на сервере, что-то у них там весьма серьёзно попортилось, и когда работу восстановили, оказалось, что пропал один раздел (с подразделами и всеми темами).
Но при внимательном рассмотрении оказалось, что "попортилась" запись в одной-единственной ячейке таблицы forum, это легко восстанавливается. Так что не пришлось выколупывать из бекапа все темы и посты

===

Originally Posted by Advantech

А какие у Вас ещё были вопросы? ;)

Прошу прощения, немного выпала из жизни... можем продолжить разговор

Судя по описанной ситуации - нет записей в таблице user, а в таблице post нет юзерИДа (то есть, там 0, но это всё равно что нет) - пользователи были удалены, причём вряд ли это какая-то сиквел-инъекция, уж очень "чистенько" всё, так вобле удаляет юзеров штатно, проходится по всем связанным таблицам

Отсюда вопросы... самый первый возник тут:

Originally Posted by Advantech

автоудаление на форуме отключено

а оно было когда-то включено? что за "автоудаление"? по каким критериям "автоудаляет"? не могло получиться так, что юзера были именно удалены этим автоудалением?

Ведь сейчас у Вас на руках фактически "гибридная" база: таблицы тем и постов не соответствуют таблице юзеров, раз таблица была поднята из бекапа (кстати, для корректной работы нужно поднимать три таблицы с записями о юзерах)

И второй вопрос (пачка вопросов)): со-администраторы есть? лог действий в админке - смотрели? странностей с собственным аккаунтом - не замечали? (дата последнего визита, например)

Ваши вопросы:

Originally Posted by Advantech

1. Возможно ли как-то проверить целостность самой базы данных, что все таблицы и поля на месте?

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

Originally Posted by Advantech

2. Для чего нужен пункт в админке - Обслуживание - Восстановить/оптимизировать таблицы? Для чего или после чего необходимо восстановление таблиц и поможет ли это мне в чём-нибудь?

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

Originally Posted by Advantech

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

да, имеет
про автоматику - не слышала

Originally Posted by Advantech

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

а юзера? они готовы закрыть глаза на потерю всего, что нажито непосильным трудом постов, репутации, статусов?

@eska, я так и сделал - сменил хостинг. Целостность файлов проверил через встроенные стредсва VB и во время апгрейда. Тут всё в порядке. Схема базы тоже целая. Все основные функции работают, глюков пока не замечено. Будем надеяться, что проблема устранена. Конечно, есть вероятность, что потеряно содержимое самих сообщений, но проверить каждое - это уже нереально.


Luvilla,

Originally Posted by Luvilla

что за "автоудаление"

Сейчас точно не могу подсказать, т.к. в последний раз настраивал форум давно. Если не изменяет память, должна быть где-то настройка автоудаления пользователя, если он не входил на форум какое-то время.
В данном случае эта функция не могла сработать, т.к. были удалены активные пользователи. А обнаружена пропажа данных была чисто случайно, потому что был удалён заодно и админ, юзер под номером 1, который, к тому же, прописан в config.php как неудаляемый

Originally Posted by Luvilla

таблицы тем и постов не соответствуют таблице юзеров

На этапе восстановления данных столкнулся со следующей проблемой - имена некоторых удалённых юзеров были заняты вновь зарегистрировавшимися юзерами. В случае автоматического восстановления связей можно было бы по ошибке не тем юзерам присвоить сообщения. Обнаружилось это не сразу и тоже случайно при ручной проверке (такой вариант изначально не был мной учтён в плане восстановления). В связи с чем в каждом случае принималось индивидуальное решение - какого юзера оставить - старого или нового. Ситуация упростилась тем, что многие такие юзеры не имели сообщений или давно не посещали форум. Удалённые юзеры восстанавливались простым insert-ом, взятым из дампа SQL. Это не считаеся корректным восстановлением, потому что в профиле юзера через админку пустота, чтобы юзер окончательно восстановился, необходимо после insert-а в админке запустить восстановление повреждённых профилей, после чего юзер реанимируется полноценно со всеми данными в анкете. Единственное, кажись не восстановились аватары. Далее для восстановления связей используются два запроса - один для восстановления связи юзера с темами, другой - с постами:

PHP Code:

update thread set postuserid = (select userid from user where binary username = 'xxx') where binary postusername = 'xxx' and postuserid = '0';
update post set userid = (select userid from user where binary username = 'xxx') where binary username = 'xxx' and userid = '0'; 


Originally Posted by Luvilla

со-администраторы есть? лог действий в админке - смотрели? странностей с собственным аккаунтом - не замечали?

Со-администраторов нет, логи не смотрел, да и не сообразил как-то сразу. Странностей с аккаунтом не замечал, но замечал много странностей с хостингом. В частности, часто приходили ошибки доступа к БД. Во время перезда обнаружил множество левых файлов на аккаунте - например, папка, в ней 32 тысячи html-файлов с разным seo-мусором. Похоже, что сервак хостинга взламывали или порутили. В общем, очень кривой хостинг оказался. Что удивительно - после переезда на другой хостинг увеличилась посещаемость.

Originally Posted by Luvilla

а юзера? они готовы закрыть глаза на потерю

Дело в том, что авария призошла несколько лет назад. С тех пор форум жил самостоятельной вялотекущей жизнью, т.к. не было смысла вкладываться в развитие проекта из-за боязни опять потерять данные, пока не сменится хостинг. Теперь, наконец, дошли руки. Будем надеяться, что дела пойдут в гору.


На данный момент почти все пользователи и их связи восстановлены, форум был проапгрейжен до 3.8.9. Работает в штатном режиме. Посмотрим, что будет дальше
Большое всем спасибо за помощь, подсказки и поддержку!

Advantech добавил 06.01.2016 в 19:18
binary в запросе необходим чтобы различать регистр в имени пользователя.