Как отследить изменения в БД?

Question

[Алексей]

Хочется узнать все изменения после редактирования/создания поста в Wordpress с множеством плагинов. Каким образом мне посмотреть, что добавилось/изменилось в MySQL? Может есть возможность в phpMyAdmin это смотреть?

Answer 1

[Владимир Коротенко]

1. дамп
2. внесение изменений
3. дамп
4. сравнить с помощью diff (или подобной)

Comments

[Immortal_pony]

Владимир Коротенко вы, я смотрю, легких путей не ищите

[Владимир Коротенко]

Immortal_pony, Человек спросил про изменения. Diff дает наиболее легкий путь найти их.
Как по мне триггер вообще ни о чем в данном случае. Он сработает на событие, которое нужно еще и узнать.
Перелопачивать исходный код всех плагинов?

Вот кстати пример. Не смотря на размер дампа в 20 килобайт, diff показывает изменения только в 2 строчках.

Как по мне так удобно

[Immortal_pony]

Владимир Коротенко, я вот не могу понять, вы невероятно тупой или пытаетесь троллить.
Я постараюсь описать минусы вашего подхода, хотя по мне это как описывать, почему не стоит срать посередение стола сразу после того как пришел в гости.

В системе много компонентов, которые вносят изменения при каждом действии пользователя. Diff будет невероятной простыней, в которой будет асболюбтно непонятно, какой компонент системы каким образом изменил данные. Снимать дамп надо вручную, ковырять diff надо вручную, обе эти операции чрезвычайно затратные как по ресурсам сервера, так и по человеческим и нет никакого смысла так поступать, когда есть другие способы для решения вопроса.

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

Вы уверены, что поннимате как работают триггеры в БД? Я ведь даже дал ссылку на документацию.

[Владимир Коротенко]

Immortal_pony, а вы понимаете что предлагаете? Изучить все DDL, которые делают левые плагины и навесить на них эти тригеры. Причем вопрос человека был в том "Каким образом мне посмотреть, что добавилось/изменилось в MySQL?"

Мой подход позволяет даже понять что за изменения были сделаны на уровне схемы, и инсерты, не изучая логику этих плагинов.
Вы же решили козырнуть "знаниями" sql, почему не UDT ?

Если уж поперли на рожон, приведите пример кода, в котором триггер логгирует какие то события без знания структуры БД .

CREATE TRIGGER ins_sum BEFORE INSERT ON account
       FOR EACH ROW SET @sum = @sum + NEW.amount;

[Immortal_pony]

Владимир Коротенко, я не предлагаю ничего изучать. Я предлагаю повесить триггеры на все интересующие таблицы. Для этого нам потребуется только БД, в код глядеть не придется.

Если уж поперли на рожон, приведите пример кода, в котором триггер логгирует какие то события без знания структуры БД .

Я приведу пример запроса, который генерирует триггеры для логгирования всех insert'ов.
Для начала создам таблицу для логов:

CREATE TABLE `dblog` ( 
	`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, 
	`created` DATETIME NOT NULL, 
	`action` ENUM('insert','update','delete'), 
	`new_value` JSON, 
	`old_value` JSON, 
	`description` TEXT, 
	PRIMARY KEY (`id`) 
);

И вот запрос, который сгенерирует запросы для создания триггеров:

SELECT 
	CONCAT(
		'DELIMITER $$\n',
		'DROP TRIGGER IF EXISTS `log_insert_', `COLUMNS`.`TABLE_NAME`, '`$$\n',
		'CREATE TRIGGER `log_insert_', `COLUMNS`.`TABLE_NAME`, '` AFTER INSERT ON `', `COLUMNS`.`TABLE_NAME`, '`\n',
		'FOR EACH ROW BEGIN\n',
			'INSERT INTO `dblog` VALUES (\n',
				'NULL,\n',
				'NOW(),\n',
				'\'insert\',\n',
				'JSON_OBJECT(\n',
					GROUP_CONCAT(CONCAT('\'', COLUMN_NAME, '\', NEW.`', COLUMN_NAME, '`') SEPARATOR ',\n'),
				'),\n',
				'NULL,\n',
				'\'New row inserted\'',
			');'
		'END$$\n',
		'DELIMITER ;\n'
	) AS 'trigger'
FROM 
	`information_schema`.`COLUMNS` 
WHERE 1
	AND `TABLE_SCHEMA`='my_wp'
	AND `TABLE_NAME` != 'dblog'
GROUP BY 
	`TABLE_NAME`

[Владимир Коротенко]

Immortal_pony, Что будет если запустить mysqld c ключом --skip-show-databases
?
Как по мне, то вы попытались доказать что можно.

[Immortal_pony]

Владимир Коротенко А что будет если вообще не устанавливать mysql? Что будет если попытаться выполнить этот запрос в mssql? И самое главное - что будет, если вы перестаните троллить тупыми вопросами?

[Владимир Коротенко]

Immortal_pony, Я задал вполне вероятный вопрос, на шаред хостингах, такое практикуют.
Потому что не стоит знать всем соседям структуру БД.

[Immortal_pony]

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

Answer 2

[Immortal_pony]

Если на уровне БД, то используя триггеры можно отслеживать все изменения. Единственный минус - узнать, какой плагин отправил запрос не представляется возможным.

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

Comments

[Владимир Коротенко]

Триггер вы цеплять на что будете?

[Immortal_pony]

Владимир Коротенко в смысле "на что"? На интересующие таблицы, на события insert, update, delete

[Владимир Коротенко]

Immortal_pony, Откуда вы их узнаете?
Почему вы думаете что запись происходит именно туда, а не в таблицу WP_Some_Table_OF_Developer_Left_Leg

И почему вы предлагаете проводить это на боевом сервере, а не на дампе в лабораторных условиях?

[Immortal_pony]

Владимир Коротенко из information_schema, конечно.

Почему вы думаете что запись происходит именно туда, а не в таблицу WP_Some_Table_OF_Developer_Left_Leg

Я так не думаю. Я думаю, что на эту таблицу можно повесить триггер.

И почему вы предлагаете проводить это на боевом сервере, а не на дампе в лабораторных условиях?

Потому что на "дампе в лабораторных условиях" есть веротяность не получить нужных событий

[Владимир Коротенко]

Immortal_pony,

Я так не думаю. Я думаю, что на эту таблицу можно повесить триггер.

И откуда вы узнаете что эта таблица создана?

Потому что на "дампе в лабораторных условиях" есть веротяность не получить нужных событий

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

[Immortal_pony]

Владимир Коротенко Какой TDD, когда речь у нас о WP-сайте? О чем вы вообще?

И откуда вы узнаете что эта таблица создана?

Из information_schema, конечно

[Владимир Коротенко]

Immortal_pony, О создании песочницы для тестов, где минимальное влияние внешних факторов.
А ваш код даст портянку непонятного jsona, в котором еще и разобраться нужно.

Хотя и будет действовать. Кстати чем вам так Diff не угодил? Плохие мержи были?

[Immortal_pony]

Владимир Коротенко TDD - это методология разработки. При этом данная методология не применяется при разработке WP-сайтов и плагинов. Если вы о чем-то другом, то поясните.

Кстати чем вам так Diff не угодил?

Я процитируя себя:

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

А ваш код даст портянку непонятного jsona, в котором еще и разобраться нужно.

Мой код залоггирует информацию по каждому запросу. Данные будут в JSON и MySQL-таки поддержживает поиск по нему. Что вам тут опять непонятно?

[Владимир Коротенко]

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

Разницу между 1 дампом и другим, причем это будут именно простые

create table
alter table
create index
.......
select, update, delete

А на тестовом стенде еще будет крайне мало "мусора".

[Immortal_pony]

Владимир Коротенко я повторюсь:

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

[Владимир Коротенко]

Immortal_pony, diff будет 1 строка на 1 инсерт.
Откуда невероятная простыня?
Я же вам приводил пример.

Кстати если уж совсем заморочится. То задифить можно и файловые бэкапы и тогда ваша проблема, решиться сама собой. Получите список изменений, где простым поиском можно искать, кто и что натворил.

Если на уровне БД, то используя триггеры можно отслеживать все изменения. Единственный минус - узнать, какой плагин отправил запрос не представляется возможным.