6.3.11.4. Контрольный Плагин Журнала, Регистрирующий Управление

Этот раздел описывает как audit_log плагин выполняет журналирование и системные переменные, которые управляют, как журналирование происходит. Это принимает знакомство с форматом файла журнала, описанным в Разделе 6.3.11.3, "Контрольный Файл журнала".

Когда контрольный плагин журнала открывает свой файл журнала, он проверяет ли объявление XML и открытие <AUDIT> корневой тег элемента должен быть записан и пишет им раз так. Когда контрольный плагин журнала завершается, он пишет закрытие </AUDIT> тегируйте к файлу.

Если файл журнала существует в открытое время, сменные проверки, заканчивается ли файл </AUDIT> тегируйте и усекает это раз так прежде, чем записать любому <AUDIT_RECORD> элементы. Если файл журнала существует, но не заканчивается </AUDIT> или </AUDIT> тег не может быть усеченным, плагин считает файл уродливым и не в состоянии инициализировать. Это может произойти, если сервер отказывает или уничтожается с контрольным выполнением плагина журнала. Никакое журналирование не происходит, пока проблема не исправляется. Проверьте журнал ошибок на диагностическую информацию:

[ERROR] Plugin 'audit_log' init function returned error.

Чтобы иметь дело с этой проблемой, следует или удалить или переименовать уродливый файл журнала и перезапустить сервер.

Сервер MySQL вызывает контрольный плагин журнала, чтобы записать <AUDIT_RECORD> элемент всякий раз, когда auditable событие имеет место, такой как тогда, когда это завершает выполнение SQL-оператора, полученного от клиента. Обычно первое <AUDIT_RECORD> у элемента, записанного после запуска сервера, есть описание сервера и опции запуска. Элементы после того представляют события, такие как клиент, соединяют и разъединяют события, выполняемые SQL-операторы, и т.д. Только высокоуровневые операторы регистрируются, не операторы в пределах сохраненных программ, таких как триггеры или хранимые процедуры. Содержание файлов, на которые ссылаются операторы такой как LOAD DATA INFILE не регистрируются.

Разрешать управление тем, как журналирование происходит, audit_log плагин обеспечивает несколько системных переменных, описанных после. Для получения дополнительной информации см. Раздел 6.3.11.5, "Контрольные Опции Плагина Журнала и Переменные".

audit_log_file: Имя файла журнала. По умолчанию имя audit.log в каталоге серверных данных. Для соображений безопасности контрольный файл журнала должен быть записан каталогу, доступному только для сервера MySQL и пользователей с законной причиной просмотреть журнал.
audit_log_policy: Какие виды информации сменные записи. По умолчанию эта переменная устанавливается в ALL (запишите все auditable события), но также и разрешает значения LOGINS или QUERIES зарегистрировать только вход в систему или события запроса, или NONE отключить журналирование.
audit_log_strategy: Метод используется для записей журнала. По умолчанию значение стратегии ASYNCHRONOUS и плагин регистрирует асинхронно к буферу, ожидая, если буфер полон. Возможно сказать плагину не ожидать (PERFORMANCE) или зарегистрировать синхронно, любое кэширование файловой системы использования (SEMISYNCHRONOUS) или принуждение вывода с a sync() вызовите после каждого запроса записи (SYNCHRONOUS).

У асинхронной стратегии журналирования есть эти характеристики:
- Минимальное воздействие на производительность сервера и масштабируемость.
- Блокирование потоков, которые генерируют события аудита в течение самого короткого времени; то есть, время, чтобы выделить буфер плюс время, чтобы скопировать событие в буфер.
- Вывод идет в буфер. Записи от буфера до файла журнала обрабатываются отдельным потоком.
Недостаток PERFORMANCE стратегия состоит в том, что это отбрасывает события, когда буфер полон. Для в большой степени загруженного сервера более вероятно, что контрольный журнал будет пропускать события.

С асинхронным журналированием может поставиться под угрозу целостность файла журнала, если проблема происходит во время записи с файлом или если плагин не завершает работу чисто (например, когда узел сервера отказывает). Чтобы уменьшить этот риск, установить audit_log_strategy используйте синхронное журналирование. Независимо от стратегии журналирование происходит на основе максимальных усилий без гарантии непротиворечивости.
audit_log_buffer_size: Размер буфера для асинхронного журналирования. Плагин использует единственный буфер, который он выделяет, когда он инициализирует и удаляет, когда он завершается. Плагин выделяет этот буфер, только если журналирование является асинхронным.
audit_log_rotate_on_size, audit_log_flush: Эти переменные разрешают контрольное вращение файла журнала и сбрасывание. У контрольного файла журнала есть потенциал, чтобы стать очень большим и использовать большое дисковое пространство. Чтобы управлять использованным пространством, или включить автоматическому вращению журнала, или вручную переименовывают контрольный файл и сбрасывают журнал, чтобы открыть новый файл. Переименованный файл может быть удален или поддержан как требующийся.

По умолчанию, audit_log_rotate_on_size=0 и нет никакого вращения журнала. В этом случае контрольный плагин журнала закрывает и вновь открывает файл журнала когда audit_log_flush оцените изменяется от отключенного до включенного. Переименование файла журнала должно быть сделано внешне к серверу. Предположите, что Вы хотите поддержать три новых файла журнала, который цикл через имена audit.log.1 через audit.log.3. На Unix выполните вращение вручную как это:
1. Из командной строки переименуйте текущие файлы журнала:
```
shell> mv audit.log.2
                                audit.log.3shell> mv audit.log.1
                                audit.log.2shell> mv audit.log
                                audit.log.1
```
  В этой точке плагин все еще пишет в текущий файл журнала, который был переименован к audit.log.1.
2. Соединитесь с сервером и сбросьте файл журнала, таким образом, плагин закрывает это и вновь открывает новое audit.log файл:
```
mysql> SET GLOBAL
                                audit_log_flush = ON;
```
Если audit_log_rotate_on_size больше чем 0, устанавливая audit_log_flush не имеет никакого эффекта. В этом случае контрольный плагин журнала закрывает и вновь открывает свой файл журнала всякий раз, когда запись к файлу заставляет свой размер превышать audit_log_rotate_on_size значение. Плагин переименовывает исходный файл, чтобы иметь расширение метки времени. Например, audit.log мог бы быть переименован к audit.log.13440033615657730. Последние 7 цифр являются частью доли секунды. Первые 10 цифр являются значением метки времени Unix, которое может быть интерпретировано, используя FROM_UNIXTIME() функция:
```
mysql> SELECT
                    FROM_UNIXTIME(1344003361);+---------------------------+| FROM_UNIXTIME(1344003361) |+---------------------------+| 2012-08-03 09:16:01       |+---------------------------+
```