Как вычислить кто делает определенные запросы к базе?

Question

[Вячеслав Грачунов]

Ситуация такая:
есть в базе таблица с пользователями (назовем ее users) - в ней периодически кто-то правит данные пользователей методом DELETE/INSERT (похоже на то, поскольку меняется id). Так вот id меняться ни в коем случае не должен, т.к. на него завязано много других таблиц. Но, блин, меняется! Только UPDATE должен применяться. От этого база потихоньку превращается в кашу, которую мне разгребать. Никто из разработчиков в таком поведении не сознается. Я все свои скрипты уже три раза перепроверил - нет нигде таких запросов.
Вопрос: можно ли как-то вычислить откуда идут подобные запросы? С какого ip? Или хоть какую-то идентифицирующую информацию получить.

Answer 1

[Вячеслав Грачунов]

БЛИН! ХА-ХА! И еще БЛИН!

Извините)))

Вычислил диверсанта)
Короче, я пытал разработчиков, а этот мордор устроил ЗАКАЗЧИК

Короче, есть 2 части веб-приложения с разными командами разработки. Связаны между собой посредством апи, без прямого доступа в бд друг-друга. В обоих частях есть список пользователей, и он должен совпадать. И если в первой пользователь поменял почту, к примеру, то вторая часть откажется его пускать. Так вот.. В таких случаях заказчик САМ менял во 2 части соответствующие данные. И да, методом DELETE/INSERT всей строки)) Естественно id менялся.

Нахрена он это делал сам и почему не поручил никому автоматизировать - хрен его знает)

Объяснил ему, что он немного не то делает) Вроде понял) Автоматизация, естественно, на мне, раз я предложил.

Можно я еще поржу немного?))

Answer 2

[Rsa97]

Чтобы такого не происходило, задайте внешние ключи (FOREIGN KEY) с блокировкой удаления/изменения (ON DELETE RESTRICT ON UPDATE RESTRICT).
Внешние ключи как раз предназначены для автоматического поддержания связности данных между таблицами.
Ну и, заодно, увидите, у кого скрипты начнут ошибки выдавать.

Comments

[ThunderCat]

Это все хорошо и правильно, но я бы смотрел и в сторону перепроверки кода на предмет косяков апдейта не тех полей. Насчет ошибок кстати в точку, хоть видно будет где косяки.

[Rsa97]

ThunderCat, Так апдейт ключа тоже не прокатит, если есть хоть одна связанная строка.

[ThunderCat]

Rsa97, я обеими руками за, просто в любом случае имхо надо понять "что пошло не так", ибо оно же потом полюбому вылезет в самый подходящий момент.

Answer 3

[Exploding]

Повесьте триггеры на after insert и before delete события для нужной таблицы и пишите в отдельную таблицу все, что нужно, для раскрытия этого громкого преступления века: логин пользователя, метка времени, нужные ID и т.д.

Answer 4

[ThunderCat]

Только UPDATE должен применяться

почему бы и нет?

update `users` 
set id = 42
where username = 'Duglas Adams'

UPD: как вариант логировать запросы на уровне прослойки бд, например по регулярке или вообще все. Хорошим решением так же будет по совету Rsa97 повесить внешние ключи на таблицу и отслеживать ошибки нарушения связанности.

Comments

[Вячеслав Грачунов]

Но в логах будут только сами запросы? А откуда они пришли информации там не будет как понимаю?

[ThunderCat]

Вячеслав Грачунов, что значит откуда пришли? У вас логика раскидана по машинам и запросы в базу с каждой машины идут отдельно? IP пользователя вызвавшего скрипт можно логировать из $_SERVER['REMOTE_ADDR'], но я думаю вам нужен код (и метод) вызвавший тот или иной запрос. Тут можно использовать debug_backtrace для отслеживания цепочки вызовов.

[Вячеслав Грачунов]

ThunderCat, да раскидано по машинам. Но подключение к mysql через ssh.
Дело в том что это может быть не код вообще, а вручную кем-то правилось. Т.к. для ошибки в коде слишком мало испорчено (пару десятков из 5 тысяч)

[ThunderCat]

Вячеслав Грачунов, так а руками то вообще можно все что хочешь с консоли нафигачить... Вешайте внешние ключи и внимательно наблюдайте за реакцией окружающих )

[Вячеслав Грачунов]

ThunderCat,
>наблюдайте за реакцией окружающих )
Удаленка.
А вручную могли операторы "поправить" пользователей, которые не смогли зайти в кабинет или ещё по какой причине. Но вот тоже говорят, что этих не редактировали