Отслеживать все изменения базы данных DML/DDL в таблице журналов с помощью триггера в Mysql

Question

Я хотел бы отслеживать все изменения БД, происходящие в конкретном БД, используя одну таблицу журналов.

Я проверил множество решений, но все они дают одну таблицу аудита для каждой таблицы в БД. Как мы можем отслеживать их в одной таблице с помощью триггера?

Столбцы таблицы могут иметь как:

id - primary key 
    db_name -- DB Name 
    version, -- Ignore it(i have a column in my table) 
    event_type, -- DDL/DML command name 
    object_name, -- Table/Procedure/Trigger/Function name which is changed 
    object_type, -- TYpe like table,procedure,trigger 
    sql_command, -- query executed by user 
    username, -- who executed it 
    updated_on -- timestamp 

Заранее спасибо.

Answer 1

Триггер, вызываемый при выполнении команд ddl (поэтому вы можете их зарегистрировать), не существует в mysql. Но вы можете использовать logfiles, особенно The General Query Log:

Общий журнал запросов общая запись о том, что туздЫ делает. Сервер записывает информацию в этот журнал, когда клиенты подключаются или разъединяются, и регистрирует каждый SQL-запрос, полученный от клиентов. Общий журнал запросов может быть очень полезен, если вы подозреваете ошибку в клиенте и хотите точно знать, что клиент отправил в mysqld.

Журнал по умолчанию отключен, и включение его может немного снизить производительность. И он не будет включать косвенные изменения (например, ddls, выполняемые внутри процедуры).

Если вы можете установить плагин, несколько более конфигурируемая (и более эффективная) альтернатива должна была бы использовать плагин аудита, см. MySQL Enterprise Audit или любую свободную реализацию, например. this one, или вы можете написать your own, но в основном будут записывать те же вещи, что и в общем журнале.

Другим важным источником информации может быть information schema и performance schema. Оттуда вы можете собирать в основном всю необходимую информацию (особенно log of recently executed queries) и генерировать свою таблицу журналов, но для этого потребуется некоторая работа по сбору всех необходимых данных - и это не будет вызвано действиями, поэтому вам придется периодически проверяйте изменения самостоятельно (например, сравните данные в INFORMATION_SCHEMA.TABLES с сохраненной копией, чтобы отслеживать добавленные, удаленные и переименованные таблицы). С другой стороны, периодически mysql_dump, за которым следует diff, к самой последней версии может быть намного проще.