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

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

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

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

• Логируется полный текст запроса, где это возможно.
• Логируются ошибки и предупреждения.
• Логи запросов можно воспроизводить.
• Логируются дополнительные счетчики производительности (в данный момент, времена распределенных запросов по агентам).
• Каждая запись лога является валидным SQL/JSON-запросом Manticore, который воспроизводит полный запрос, за исключением случаев, когда запрос слишком велик и для производительности он сокращён.
• 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 — время в миллисекундах, затраченное CPU на обработку запроса.
• 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 позволяет задать другие права доступа. Это может быть полезно, например, для предоставления другим пользователям (например, системам мониторинга, работающим не под root) доступа к файлам логов.

Чтобы отключить бинарное логирование глобально, установите 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, контролируемые директивой binlog_flush:

• 0 - данные записываются на диск (сбрасываются) каждую секунду, и Manticore инициирует их защиту на диске (syncing) сразу после сброса. Этот метод самый быстрый, но если сервер или компьютер внезапно упадет, некоторые недавно записанные данные, которые еще не были защищены, могут быть потеряны.
• 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 будет поддерживать отдельный поток, который проверяет, нужно ли записывать RT-чанки обратно на диск. После этого соответствующие binlog могут быть (и будут) безопасно удалены.

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