Логирование запросов можно включить, установив директиву query_log в разделе searchd конфигурационного файла.

Запросы также могут отправляться в syslog, если указать syslog вместо пути к файлу. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом LOG_INFO, с префиксом [query] вместо временной метки. Для syslog поддерживается только формат лога plain.

Формат лога SQL является настройкой по умолчанию. В этом режиме Manticore логирует все успешные и неуспешные select-запросы. Запросы, отправленные как SQL или через бинарный API, логируются в формате SQL, но JSON-запросы логируются как есть. Этот тип логирования работает только с обычными файлами логов и не поддерживает службу 'syslog' для логирования.

Особенности формата лога SQL Manticore по сравнению с простым форматом включают:

• Полные данные оператора логируются там, где это возможно.
• Ошибки и предупреждения логируются.
• Лог запросов может быть воспроизведен.
• Логируются дополнительные счетчики производительности (в настоящее время - время распределенных запросов на агента).
• Каждая запись в логе является валидным оператором Manticore SQL/JSON, который восстанавливает полный запрос, за исключением случаев, когда записанный запрос слишком велик и его необходимо сократить по соображениям производительности.
• JSON-запросы логируются как комментарии, пропуская лишние пробелы между элементами.
• Дополнительные сообщения, счетчики и т.д. логируются как комментарии.

При формате лога plain Manticore логирует все успешно выполненные поисковые запросы в простом текстовом формате. Не-полнотекстовые части запросов не логируются. JSON-запросы записываются как однострочные записи. Запросы, обработанные через Buddy, не логируются.

Формат лога следующий:

[query-date] real-time wall-time [match-mode/filters-count/sort-mode total-matches (offset,limit) @groupby-attr] [table-name] {perf-stats} query

где:

• real-time - время от начала до завершения запроса.
• wall-time - аналогично real-time, но исключает время ожидания агентов и слияния результирующих наборов от них.
• perf-stats - включает статистику CPU/IO, когда Manticore запущен с --cpustats (или это было включено через SET GLOBAL cpustats=1) и/или --iostats (или это было включено через SET GLOBAL iostats=1):
  • ios - количество выполненных операций ввода-вывода с файлами;
  • kb - объем данных в килобайтах, прочитанных из файлов таблиц;
  • ms - время, затраченное на операции ввода-вывода.
  • cpums - время в миллисекундах, затраченное на обработку запроса процессором.
• match-mode может иметь одно из следующих значений:
  • "all" для режима SPH_MATCH_ALL;
  • "any" для режима SPH_MATCH_ANY;
  • "phr" для режима SPH_MATCH_PHRASE;
  • "bool" для режима SPH_MATCH_BOOLEAN;
  • "ext" для режима SPH_MATCH_EXTENDED;
  • "ext2" для режима SPH_MATCH_EXTENDED2;
  • "scan" если использовался режим полного сканирования, либо указанный с SPH_MATCH_FULLSCAN, либо если запрос был пустым.
• sort-mode может иметь одно из следующих значений:
  • "rel" для режима SPH_SORT_RELEVANCE;
  • "attr-" для режима SPH_SORT_ATTR_DESC;
  • "attr+" для режима SPH_SORT_ATTR_ASC;
  • "tsegs" для режима SPH_SORT_TIME_SEGMENTS;
  • "ext" для режима SPH_SORT_EXTENDED.

Примечание: режимы SPH* специфичны для устаревшего интерфейса sphinx. Интерфейсы SQL и JSON будут логировать, в большинстве случаев, ext2 как match-mode и ext и rel как sort-mode.

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

Ожидаемая единица измерения - миллисекунды, но также можно использовать выражения с временными суффиксами.

По умолчанию файлы логов searchd и запросов создаются с правами доступа 600, поэтому только пользователь, под которым работает Manticore, и root могут читать файлы логов. Опция query_log_mode позволяет установить другие права доступа. Это может быть полезно для предоставления доступа на чтение файлов логов другим пользователям (например, решениям мониторинга, работающим под непривилегированными пользователями).

Для глобального отключения бинарного логирования установите binlog_path в пустое значение в конфигурации searchd. Отключение бинарного логирования требует перезапуска демона и повышает риск потери данных при внезапном отключении системы.

Для задания пользовательского пути можно использовать следующую директиву:

Для более гибкого управления бинарное логирование можно отключить на уровне таблиц реального времени, установив параметр таблицы binlog в значение 0. Эта опция недоступна для таблиц типа percolate.

Для существующих RT-таблиц бинарное логирование также можно отключить, изменив параметр binlog.

Если бинарное логирование было ранее отключено, его можно вновь включить, установив параметр binlog обратно в 1:

Во время обычной работы, когда объём записанных данных достигает определённого предела (устанавливаемого параметром binlog_max_log_size), начинается новый лог-файл. Старые логи сохраняются до тех пор, пока все изменения в них полностью не обработаются и не сохранятся на диск в виде дискового чанка. Если этот предел установлен в 0, лог-файлы сохраняются пока система не будет корректно завершена. По умолчанию ограничений на размер файлов нет.

Каждый binlog-файл именуется с ведущими нулями, например binlog.0000, binlog.0001 и так далее, обычно с четырьмя цифрами. Количество цифр в номере файла можно изменить настройкой binlog_filename_digits. Если количество binlog-файлов превысит вместимость текущего количества цифр, количество цифр будет автоматически увеличено.

Важно: для изменения количества цифр необходимо сначала сохранить все данные таблиц и корректно завершить работу системы. Затем удалить старые лог-файлы и перезапустить систему.

Вы можете выбрать один из двух способов управления бинарными лог-файлами с помощью директивы binlog_common:

• Отдельный файл на каждую таблицу (по умолчанию, 0): каждая таблица сохраняет изменения в собственном лог-файле. Такая конфигурация удобна, если у вас много таблиц, обновляющихся в разное время. Это позволяет обновлять таблицы независимо друг от друга. Также если возникает проблема с лог-файлом одной таблицы, это не влияет на другие.
• Один файл для всех таблиц (1): все таблицы используют один общий бинарный лог-файл. Этот метод упрощает работу с файлами, так как их меньше. Однако при этом файлы могут дольше храниться, если хотя бы одной таблице нужно сохранить обновления. Также данная настройка может замедлять работу при одновременном обновлении многих таблиц, так как все изменения должны записываться в один файл.

Существует четыре различных стратегии сброса бинарного лога, которые регулируются директивой binlog_flush:

• 0 - Данные записываются на диск (сбрасываются) каждую секунду, и Manticore инициирует их защиту на диске (синхронизацию) сразу после сброса. Этот метод самый быстрый, но если сервер или компьютер внезапно выйдут из строя, некоторые недавно записанные данные, которые не были защищены, могут быть потеряны.
• 1 - Данные записываются в binlog и синхронизируются сразу после каждой транзакции. Этот метод самый безопасный, так как гарантирует немедленное сохранение каждого изменения, но замедляет запись.
• 2 - Данные записываются после каждой транзакции, а синхронизация инициируется каждую секунду. Этот подход предлагает баланс, записывая данные регулярно и быстро. Однако, в случае сбоя компьютера, часть данных, которые находились в процессе защиты, может не успеть сохраниться. Кроме того, синхронизация может занимать больше одной секунды в зависимости от диска.
• 3 - Похоже на 2, но также гарантирует, что файл binlog синхронизируется перед закрытием из-за превышения binlog_max_log_size.

Режим по умолчанию — 2, который записывает данные после каждой транзакции и запускает их синхронизацию каждую секунду, балансируя скорость и безопасность.

В кластере с использованием Galera важна правильная обработка восстановления узла. Обычно Galera решает проблему рассогласования узла с помощью IST (incremental state transfer — инкрементальная передача состояния), если узел был корректно завершён и его последний номер последовательности (seqno) был правильно сохранён. Однако в случае сбоя, когда seqno не сохранён, Galera инициирует SST (state snapshot transfer — передача снимка состояния), что требует больших ресурсов и может значительно замедлить кластер из-за высокой активности ввода-вывода.

Для решения этой проблемы введена поддержка кластерного binlog. Эта функция расширяет существующую двоичную запись изменений, помогая снизить необходимость SST, позволяя восстанавливающемуся узлу воспроизводить недостающие транзакции из локальных binlog и снова присоединяться к кластеру с корректным seqno.

Кластерный binlog включен по умолчанию для любых операций кластера. Однако его можно отключить, установив переменную окружения:

Интенсивные обновления небольшой таблицы RT, полностью помещающейся в RAM-чунк, могут привести к постоянно растущему binlog, который невозможно удалить до чистого завершения работы. Binlog фактически служит в виде дельты, добавляемой к последнему известному хорошему состоянию на диске, и не может быть удалён, пока RAM-чунк не сохранён. Постоянно растущий binlog нежелателен с точки зрения использования диска и времени восстановления после сбоя. Для решения этой проблемы можно настроить searchd на периодический сброс RAM-чунк с помощью директивы rt_flush_period. При включённых периодических сбросах searchd запускает отдельный поток, проверяющий, нужно ли записать RAM-чунк RT таблицы обратно на диск. Как только это происходит, соответствующие binlog могут быть безопасно (и действительно) удалены.

Период сброса RT по умолчанию установлен на 10 часов.