При использовании Update для изменения атрибутов документа в реальном времени, изменения сначала записываются в копию атрибутов в памяти. Эти обновления происходят в файле с отображением в память, что означает, что ОС решает, когда записывать изменения на диск. При нормальном завершении работы searchd (инициируемом сигналом SIGTERM) все изменения принудительно записываются на диск.

Вы также можете указать searchd периодически записывать эти изменения на диск, чтобы предотвратить потерю данных. Интервал между этими сбросами определяется параметром attr_flush_period, указанным в секундах (или special_suffixes).

По умолчанию значение равно 0, что отключает периодический сброс. Однако сброс все равно происходит при нормальном завершении работы.

Этот параметр управляет автоматическим процессом OPTIMIZE для сжатия таблицы.

По умолчанию сжатие таблицы происходит автоматически. Вы можете изменить это поведение с помощью параметра auto_optimize:

• 0 — отключить автоматическое сжатие таблицы (вы все еще можете вызвать OPTIMIZE вручную)
• 1 — явно включить его
• включить с умножением порога оптимизации на 2.

По умолчанию OPTIMIZE выполняется до тех пор, пока количество дисковых чанков не станет меньше или равно количеству логических ядер CPU, умноженному на 2.

Однако, если в таблице есть атрибуты с KNN индексами, этот порог отличается. В этом случае он устанавливается равным количеству физических ядер CPU, деленному на 2, для улучшения производительности KNN поиска.

Обратите внимание, что переключение auto_optimize в положение вкл/выкл не мешает вам запускать OPTIMIZE TABLE вручную.

Manticore поддерживает автоматическое создание таблиц, которые еще не существуют, но указаны в операторах INSERT. Эта функция включена по умолчанию. Чтобы отключить её, явно установите auto_schema = 0 в вашей конфигурации. Чтобы снова включить, установите auto_schema = 1 или удалите параметр auto_schema из конфигурации.

Имейте в виду, что HTTP-эндпоинт /bulk не поддерживает автоматическое создание таблиц.

ПРИМЕЧАНИЕ: Функциональность авто-схемы требует Manticore Buddy. Если она не работает, убедитесь, что Buddy установлен.

Этот параметр управляет режимом сброса/синхронизации транзакций бинарного лога. Он необязателен, значение по умолчанию — 2 (сброс каждой транзакции, синхронизация каждую секунду).

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

• 0 — сброс и синхронизация каждую секунду. Это обеспечивает лучшую производительность, но при сбое сервера или ОС/аппаратном сбое можно потерять до 1 секунды подтвержденных транзакций.
• 1 — сброс и синхронизация каждой транзакции. Этот режим обеспечивает худшую производительность, но гарантирует сохранение данных каждой подтвержденной транзакции.
• 2 — сброс каждой транзакции, синхронизация каждую секунду. Этот режим обеспечивает хорошую производительность и гарантирует сохранение каждой подтвержденной транзакции при сбое сервера. Однако при сбое ОС/аппаратном сбое можно потерять до 1 секунды подтвержденных транзакций.

Для тех, кто знаком с MySQL и InnoDB, эта директива похожа на innodb_flush_log_at_trx_commit. В большинстве случаев режим 2 по умолчанию обеспечивает хороший баланс скорости и безопасности, с полной защитой данных RT таблиц от сбоев сервера и частичной защитой от аппаратных сбоев.

Этот параметр управляет тем, как управляются файлы бинарного лога. Он необязателен, значение по умолчанию — 0 (отдельный файл для каждой таблицы).

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

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

Этот параметр управляет максимальным размером файла бинарного лога. Он необязателен, значение по умолчанию — 256 МБ.

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

Этот параметр определяет путь для файлов бинарного лога (также известного как журнал транзакций). Он необязателен, значение по умолчанию — каталог данных, настроенный во время сборки (например, /var/lib/manticore/data/binlog.* в Linux).

Двоичные логи используются для восстановления данных таблицы RT после сбоев и для обновления атрибутов простых дисковых индексов, которые в противном случае хранились бы только в ОЗУ до сброса. Когда ведение логов включено, каждая транзакция, зафиксированная (COMMIT) в таблице RT, записывается в файл журнала. Логи затем автоматически воспроизводятся при запуске после некорректного завершения работы, восстанавливая записанные изменения.

Директива binlog_path указывает расположение файлов двоичных логов. Она должна содержать только путь; searchd будет создавать и удалять несколько файлов binlog.* в каталоге по мере необходимости (включая данные binlog, метаданные и файлы блокировок и т.д.).

Пустое значение отключает двоичное логирование, что улучшает производительность, но подвергает данные таблицы RT риску.

Этот параметр управляет значением по умолчанию для опции поиска boolean_simplify. Он необязателен, значение по умолчанию — 1 (включено).

При установке в 1 сервер автоматически применит оптимизацию булевых запросов для улучшения производительности запросов. При установке в 0 запросы будут выполняться без оптимизации по умолчанию. Это значение по умолчанию можно переопределить для каждого запроса с помощью соответствующей опции поиска boolean_simplify.

Этот параметр определяет путь к бинарному файлу Manticore Buddy. Он необязателен, значение по умолчанию — путь, настроенный во время сборки, который варьируется в зависимости от операционной системы. Обычно нет необходимости изменять этот параметр. Однако он может быть полезен, если вы хотите запустить Manticore Buddy в режиме отладки, внести изменения в Manticore Buddy или реализовать новый плагин. В последнем случае вы можете выполнить git clone Buddy с https://github.com/manticoresoftware/manticoresearch-buddy, добавить новый плагин в каталог ./plugins/ и запустить composer install --prefer-source для упрощения разработки после перехода в каталог исходников Buddy.

Для возможности запуска composer на вашей машине должен быть установлен PHP версии 8.2 или выше с следующими расширениями:

--enable-dom
--with-libxml
--enable-tokenizer
--enable-xml
--enable-xmlwriter
--enable-xmlreader
--enable-simplexml
--enable-phar
--enable-bcmath
--with-gmp
--enable-debug
--with-mysqli
--enable-mysqlnd

Вы также можете выбрать специальную версию manticore-executor-dev для Linux amd64, доступную в релизах, например: https://github.com/manticoresoftware/executor/releases/tag/v1.0.13

Если вы выберете этот путь, не забудьте связать dev-версию исполнителя manticore с /usr/bin/php.

Чтобы отключить Manticore Buddy, установите значение в пустое, как показано в примере.

Этот параметр определяет максимальное время ожидания между запросами (в секундах или с использованием special_suffixes) при использовании постоянных соединений. Он необязателен, значение по умолчанию — пять минут.

Локаль libc сервера. Необязательный параметр, по умолчанию C.

Определяет локаль libc, влияющую на сортировки, основанные на libc. Подробнее см. в разделе collations.

Сортировка сервера по умолчанию. Необязательный параметр, по умолчанию libc_ci.

Определяет сортировку по умолчанию, используемую для входящих запросов. Сортировку можно переопределить для каждого запроса. Список доступных сортировок и другие детали см. в разделе collations.

При указании этот параметр включает режим реального времени, который является императивным способом управления схемой данных. Значение должно быть путем к каталогу, в котором вы хотите хранить все ваши таблицы, двоичные логи и все остальное, необходимое для корректной работы Manticore Search в этом режиме. Индексация простых таблиц не разрешена при указании data_dir. Подробнее о различиях между режимом RT и простым режимом читайте в этом разделе.

Таймаут для предотвращения автоматического сброса RAM-чанка, если в таблице нет поисковых запросов. Необязательный параметр, по умолчанию 30 секунд.

Время проверки наличия поисков перед решением о необходимости автоматического сброса. Автоматический сброс произойдет только если в таблице был хотя бы один поиск за последние diskchunk_flush_search_timeout секунд. Работает совместно с diskchunk_flush_write_timeout. Соответствующая настройка на уровне таблицы имеет более высокий приоритет и переопределит это значение по умолчанию, обеспечивая более тонкий контроль.

Время в секундах ожидания без записи перед автоматическим сбросом RAM-чанка на диск. Необязательный параметр, по умолчанию 1 секунда.

Если в течение diskchunk_flush_write_timeout секунд в RAM-чанк не происходит запись, чанк будет сброшен на диск. Работает совместно с diskchunk_flush_search_timeout. Чтобы отключить авто-сброс, явно установите diskchunk_flush_write_timeout = -1 в вашей конфигурации. Соответствующая настройка для каждой таблицы имеет более высокий приоритет и переопределит это значение по умолчанию для всего экземпляра, обеспечивая более тонкий контроль.

Эта настройка задает максимальный размер блоков документов из хранилища документов, которые удерживаются в памяти. Опционально, значение по умолчанию — 16m (16 мегабайт).

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

Движок хранения атрибутов по умолчанию, используемый при создании таблиц в режиме RT. Может быть rowwise (по умолчанию) или columnar.

Эта настройка определяет максимальное количество расширенных ключевых слов для одного подстановочного знака. Опционально, значение по умолчанию — 0 (без ограничений).

При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов (например, сопоставление a* со всем словарем Оксфорда). Эта директива позволяет ограничить влияние таких расширений. Установка expansion_limit = N ограничивает расширения не более чем N наиболее частыми совпадающими ключевыми словами (для каждого подстановочного знака в запросе).

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

При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит количества ключевых слов, которые будут объединены для ускорения сопоставления, но при этом используется больше памяти в поиске.

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

При выполнении поиска подстрок в таблицах с включенным dict = keywords один подстановочный знак может привести к тысячам или даже миллионам совпадающих ключевых слов. Эта директива позволяет увеличить лимит количества ключевых слов, которые будут объединены для ускорения сопоставления, но при этом используется больше памяти в поиске.

Эта настройка контролирует максимальное количество альтернативных вариантов фраз, сгенерированных из-за операторов OR внутри операторов PHRASE, PROXIMITY и QUORUM. Опционально, значение по умолчанию — 1024.

При использовании оператора | (OR) внутри операторов, похожих на фразы, общее количество расширенных комбинаций может расти экспоненциально в зависимости от количества указанных альтернатив. Эта настройка помогает предотвратить чрезмерное расширение запроса, ограничивая количество перестановок, рассматриваемых при обработке запроса.

Если количество сгенерированных вариантов превышает этот лимит, запрос либо:

• завершится с ошибкой (поведение по умолчанию)
• вернет частичные результаты с предупреждением, если включен expansion_phrase_warning

Эта настройка контролирует поведение при превышении лимита расширения запроса, определенного expansion_phrase_limit.

По умолчанию запрос завершится с сообщением об ошибке. При установке expansion_phrase_warning в 1 поиск продолжается с использованием частичной трансформации фразы (до настроенного лимита), и сервер возвращает пользователю предупреждающее сообщение вместе с результатами. Это позволяет запросам, слишком сложным для полного расширения, возвращать частичные результаты без полного сбоя.

Этот параметр задаёт размер окна статистики зеркал агентов в секундах (или с использованием special_suffixes). Он необязателен, значение по умолчанию — 60 секунд.

Для распределённой таблицы с зеркалами агентов (подробнее см. в agent) мастер отслеживает несколько различных счётчиков для каждого зеркала. Эти счётчики затем используются для переключения и балансировки (мастер выбирает лучшее зеркало на основе счётчиков). Счётчики накапливаются блоками по ha_period_karma секунд.

После начала нового блока мастер может продолжать использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. В результате, любая предыдущая история перестаёт влиять на выбор зеркала максимум через 1.5 раза ha_period_karma секунд.

Хотя для выбора зеркала используется максимум два блока, до 15 последних блоков сохраняются для целей инструментирования. Эти блоки можно просмотреть с помощью оператора SHOW AGENT STATUS.

Этот параметр задаёт интервал между пингами зеркал агентов в миллисекундах (или с использованием special_suffixes). Он необязателен, значение по умолчанию — 1000 миллисекунд.

Для распределённой таблицы с зеркалами агентов (подробнее см. в agent) мастер отправляет всем зеркалам команду пинга в периоды простоя. Это необходимо для отслеживания текущего статуса агента (жив или мёртв, время сетевого отклика и т.д.). Интервал между такими пингами определяется этой директивой. Чтобы отключить пинги, установите ha_ping_interval в 0.

Параметр listen_backlog определяет длину очереди TCP listen backlog для входящих соединений. Это особенно актуально для сборок под Windows, которые обрабатывают запросы по одному. Когда очередь соединений достигает предела, новые входящие соединения будут отклоняться. Для сборок не под Windows значение по умолчанию обычно подходит, и обычно нет необходимости настраивать этот параметр.

Строка версии сервера, возвращаемая Kibana или OpenSearch Dashboards. Необязательно — по умолчанию установлено 7.6.0.

Некоторые версии Kibana и OpenSearch Dashboards ожидают, что сервер будет сообщать конкретный номер версии, и могут вести себя по-разному в зависимости от него. Чтобы обойти такие проблемы, вы можете использовать этот параметр, который заставляет Manticore сообщать Kibana или OpenSearch Dashboards пользовательскую версию.

Этот параметр позволяет указать IP-адрес и порт или путь к Unix-доменному сокету, на которых Manticore будет принимать соединения.

Общий синтаксис для listen:

listen = ( address ":" port | port | path | address ":" port start - port end ) [ ":" protocol [ "_vip" ] [ "_readonly" ] ]

Вы можете указать:

• либо IP-адрес (или имя хоста) и номер порта
• либо только номер порта
• либо путь к Unix-сокету (не поддерживается в Windows)
• либо IP-адрес и диапазон портов

Если вы указываете номер порта, но не адрес, searchd будет слушать на всех сетевых интерфейсах. Путь Unix определяется ведущим слэшем. Диапазон портов можно задать только для протокола репликации.

Вы также можете указать обработчик протокола (listener), который будет использоваться для соединений на этом сокете. Слушатели:

• Не указан — Manticore будет принимать соединения на этом порту от:
  • других агентов Manticore (например, удалённой распределённой таблицы)
  • клиентов через HTTP и HTTPS
  • Manticore Buddy. Убедитесь, что у вас есть слушатель такого типа (или http слушатель, как указано ниже), чтобы избежать ограничений в функциональности Manticore.
• mysql — протокол MySQL для соединений от клиентов MySQL. Обратите внимание:
  • Поддерживается также сжатый протокол.
  • Если включён SSL, можно установить зашифрованное соединение.
• replication — протокол репликации, используемый для связи узлов. Подробнее см. в разделе репликация. Можно указать несколько слушателей репликации, но они все должны слушать на одном IP; различаться могут только порты. При определении слушателя репликации с диапазоном портов (например, listen = 192.168.0.1:9320-9328:replication) Manticore не начинает слушать эти порты сразу. Вместо этого он будет брать случайные свободные порты из указанного диапазона только при начале использования репликации. Для корректной работы репликации в диапазоне должно быть не менее 2 портов.
• http — то же, что и Не указан. Manticore будет принимать соединения на этом порту от удалённых агентов и клиентов через HTTP и HTTPS.
• https — протокол HTTPS. Manticore будет принимать только HTTPS-соединения на этом порту. Подробнее см. в разделе SSL.
• sphinx — устаревший бинарный протокол. Используется для обслуживания соединений от удалённых клиентов SphinxSE. Некоторые реализации клиентов Sphinx API (например, Java) требуют явного указания слушателя.

Добавление суффикса _vip к протоколам клиентов (то есть ко всем, кроме replication, например mysql_vip или http_vip или просто _vip) заставляет создавать выделенный поток для соединения, чтобы обойти различные ограничения. Это полезно для обслуживания узла в случае сильной перегрузки, когда сервер в противном случае либо зависнет, либо не позволит подключиться через обычный порт.

Суффикс _readonly устанавливает режим только для чтения для слушателя и ограничивает его приём только запросами на чтение.

The log setting specifies the name of the log file where all searchd run time events will be logged. If not specified, the default name is 'searchd.log'.

Alternatively, you can use the 'syslog' as the file name. In this case, the events will be sent to the syslog daemon. To use the syslog option, you need to configure Manticore with the -–with-syslog option during building.

Ограничивает количество запросов в одном пакете. Необязательно, по умолчанию 32.

Заставляет searchd выполнять проверку разумности количества запросов, отправленных в одном пакете при использовании мультизапросов. Установите в 0, чтобы пропустить проверку.

Максимальное количество одновременных клиентских подключений. По умолчанию неограничено. Обычно это заметно только при использовании любых видов постоянных подключений, таких как cli mysql сессии или постоянные удалённые подключения из удалённых распределённых таблиц. При превышении лимита вы всё ещё можете подключиться к серверу, используя VIP-подключение. VIP-подключения не учитываются в лимит.

Глобальное ограничение количества потоков, которые может использовать одна операция. По умолчанию соответствующие операции могут занимать все ядра CPU, не оставляя места для других операций. Например, call pq к достаточно большой таблице percolate может использовать все потоки в течение десятков секунд. Установка max_threads_per_query в, скажем, половину от значения threads обеспечит возможность запуска нескольких таких операций call pq параллельно.

Вы также можете установить этот параметр как переменную сессии или глобальную переменную во время выполнения.

Кроме того, вы можете управлять поведением для каждого запроса с помощью опции threads OPTION.

Максимально допустимое количество фильтров на запрос. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 256.

Максимально допустимое количество значений в фильтре. Этот параметр используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 4096.

Максимальное количество файлов, которые сервер может открыть, называется "мягким лимитом". Обратите внимание, что обслуживание больших фрагментированных таблиц реального времени может требовать установки этого лимита на высоком уровне, так как каждый диск-чанк может занимать десятки и более файлов. Например, таблица реального времени с 1000 чанков может требовать открытия тысяч файлов одновременно. Если в логах появляется ошибка 'Too many open files', попробуйте изменить этот параметр, это может помочь решить проблему.

Существует также "жёсткий лимит", который нельзя превысить с помощью этой опции. Этот лимит определяется системой и может быть изменён в файле /etc/security/limits.conf на Linux. Другие операционные системы могут иметь другие подходы, поэтому обратитесь к документации для получения дополнительной информации.

Помимо прямых числовых значений, вы можете использовать магическое слово 'max', чтобы установить лимит равным текущему доступному жёсткому лимиту.

Максимально допустимый размер сетевого пакета. Этот параметр ограничивает как пакеты запросов от клиентов, так и пакеты ответов от удалённых агентов в распределённой среде. Используется только для внутренних проверок и не влияет напрямую на использование ОЗУ или производительность. Необязательно, по умолчанию 128M.

Строка версии сервера, возвращаемая через протокол MySQL. Необязательно, по умолчанию пусто (возвращает версию Manticore).

Некоторые придирчивые библиотеки клиентов MySQL зависят от определённого формата номера версии, используемого MySQL, и более того, иногда выбирают другой путь выполнения на основе сообщаемого номера версии (а не на основе указанных флагов возможностей). Например, Python MySQLdb 1.2.2 выбрасывает исключение, если номер версии не в формате X.Y.ZZ; MySQL .NET connector 6.3.x внутренне падает на номерах версий 1.x вместе с определённой комбинацией флагов и т.д. Чтобы обойти это, вы можете использовать директиву mysql_version_string и заставить searchd сообщать другую версию клиентам, подключающимся по протоколу MySQL. (По умолчанию он сообщает свою собственную версию.)

Таймаут чтения/записи запроса клиента сети, в секундах (или с использованием special_suffixes). Необязательно, по умолчанию 5 секунд. searchd принудительно закроет соединение клиента, если тот не отправит запрос или не прочитает результат в течение этого таймаута.

Обратите внимание также на параметр reset_network_timeout_on_packet. Этот параметр изменяет поведение network_timeout с применения к всему query или result на применение к отдельным пакетам. Обычно запрос/результат помещается в один или два пакета. Однако в случаях, когда требуется большой объем данных, этот параметр может быть незаменим для поддержания активных операций.

Этот параметр позволяет указать сетевой адрес узла. По умолчанию он установлен в адрес репликации listen. Это правильно в большинстве случаев; однако бывают ситуации, когда его нужно указать вручную:

• Узел за файрволом
• Включен сетевой транслятор адресов (NAT)
• Развертывания в контейнерах, таких как Docker или облачные развертывания
• Кластеры с узлами в более чем одном регионе

Этот параметр определяет, разрешать ли запросы, содержащие только оператор отрицания полнотекстового поиска. Необязательно, по умолчанию 0 (запросы с только оператором NOT считаются ошибочными).

Устанавливает порог сжатия таблицы по умолчанию. Подробнее здесь — Number of optimized disk chunks. Этот параметр можно переопределить с помощью опции на запрос cutoff. Также его можно динамически изменить через SET GLOBAL.

Этот параметр определяет максимальное количество одновременных постоянных соединений с удалёнными persistent agents. Каждый раз, когда агент, определённый в agent_persistent, подключается, мы пытаемся повторно использовать существующее соединение (если оно есть) или подключиться и сохранить соединение для будущего использования. Однако в некоторых случаях имеет смысл ограничить количество таких постоянных соединений. Эта директива задаёт лимит. Она влияет на количество соединений с хостом каждого агента во всех распределённых таблицах.

Рекомендуется установить значение равным или меньше опции max_connections в конфиге агента.

pid_file — обязательный параметр конфигурации в Manticore search, который указывает путь к файлу, где хранится идентификатор процесса сервера searchd.

Файл с идентификатором процесса searchd пересоздаётся и блокируется при запуске, и содержит идентификатор главного процесса сервера, пока сервер работает. При остановке сервера файл удаляется. Назначение этого файла — позволить Manticore выполнять различные внутренние задачи, такие как проверка, запущен ли уже экземпляр searchd, остановка searchd и уведомление о необходимости ротации таблиц. Файл также может использоваться внешними скриптами автоматизации.

Затраты для модели предсказания времени выполнения запроса, в наносекундах. Необязательно, по умолчанию doc=64, hit=48, skip=2048, match=64.

Прерывание запросов до их завершения на основе времени выполнения (с помощью настройки максимального времени запроса) — это хорошая страховка, но она имеет свой недостаток: неопределённые (нестабильные) результаты. То есть, если повторить один и тот же (сложный) поисковый запрос с ограничением по времени несколько раз, ограничение времени будет достигаться на разных этапах, и вы получите разные наборы результатов.

Директива конфигурации preopen_tables указывает, следует ли принудительно предварительно открывать все таблицы при запуске. Значение по умолчанию — 1, что означает, что все таблицы будут предварительно открыты независимо от настройки preopen для каждой таблицы. Если установлено в 0, то могут применяться настройки для каждой таблицы, которые по умолчанию равны 0.

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

Вот пример конфигурации:

Опция конфигурации pseudo_sharding включает параллелизацию поисковых запросов к локальным plain и real-time таблицам, независимо от того, запрашиваются ли они напрямую или через распределённую таблицу. Эта функция автоматически параллелит запросы до количества потоков, указанного в searchd.threads # потоков.

Обратите внимание, что если ваши рабочие потоки уже заняты, потому что у вас:

• высокая конкуренция запросов
• физическое шардинг любого типа:
  • распределённая таблица из нескольких plain/real-time таблиц
  • real-time таблица, состоящая из слишком большого количества дисковых чанков

то включение pseudo_sharding может не дать никаких преимуществ и даже привести к небольшому снижению пропускной способности. Если вы отдаёте приоритет более высокой пропускной способности над меньшей задержкой, рекомендуется отключить эту опцию.

Включено по умолчанию.

Эта конфигурация задаёт максимальный объём оперативной памяти, выделяемой для кэшированных наборов результатов в байтах. Значение по умолчанию — 16777216, что эквивалентно 16 мегабайтам. Если значение установлено в 0, кэш запросов отключается. Для получения дополнительной информации о кэше запросов смотрите query cache.

Формат журнала запросов. Необязательно, допустимые значения — plain и sphinxql, по умолчанию sphinxql.

Режим sphinxql записывает действительные SQL-запросы. Режим plain записывает запросы в простом текстовом формате (в основном подходит для чисто полнотекстовых случаев использования). Эта директива позволяет переключаться между двумя форматами при запуске поискового сервера. Формат журнала также можно изменить на лету, используя синтаксис SET GLOBAL query_log_format=sphinxql. Подробности см. в разделе Query logging.

Имя файла журнала запросов. Необязательно, по умолчанию пусто (не вести журнал запросов). Все поисковые запросы (например, SELECT ... но не INSERT/REPLACE/UPDATE запросы) будут записываться в этот файл. Формат описан в разделе Query logging. В случае формата 'plain' можно использовать 'syslog' в качестве пути к файлу журнала. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом LOG_INFO, с префиксом '[query]' вместо временной метки. Для использования опции syslog Manticore должен быть собран с опцией -–with-syslog.

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

Директива read_buffer_docs управляет размером буфера чтения на ключевое слово для списков документов. Для каждого вхождения ключевого слова в каждом поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Эта настройка позволяет контролировать размер буфера списка документов.

Больший размер буфера может увеличить использование ОЗУ на запрос, но возможно уменьшит время ввода-вывода. Имеет смысл устанавливать большие значения для медленных хранилищ, но для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.

Значение по умолчанию — 256K, минимальное значение — 8K. Вы также можете установить read_buffer_docs для каждой таблицы отдельно, что переопределит настройки на уровне сервера.

Директива read_buffer_hits задает размер буфера чтения на ключевое слово для списков попаданий в поисковых запросах. По умолчанию размер 256K, минимальное значение 8K. Для каждого вхождения ключевого слова в поисковом запросе существует два связанных буфера чтения: один для списка документов и один для списка попаданий. Увеличение размера буфера может увеличить использование ОЗУ на запрос, но уменьшить время ввода-вывода. Для медленных хранилищ имеет смысл использовать большие размеры буфера, а для хранилищ с высокой производительностью IOPS следует экспериментировать с малыми значениями.

Эта настройка также может быть задана для каждой таблицы отдельно с помощью опции read_buffer_hits в read_buffer_hits, что переопределит настройку на уровне сервера.

Размер чтения без подсказок. Необязательно, по умолчанию 32K, минимальное 1K

При выполнении запросов некоторые чтения заранее точно знают, сколько данных нужно прочитать, а некоторые — нет. Наиболее заметно, что размер списка попаданий в настоящее время заранее не известен. Эта настройка позволяет контролировать, сколько данных читать в таких случаях. Она влияет на время ввода-вывода списка попаданий, уменьшая его для списков, больших, чем размер чтения без подсказок, но увеличивая для меньших списков. Она не влияет на использование ОЗУ, так как буфер чтения уже будет выделен. Поэтому она не должна быть больше, чем read_buffer.

Уточняет поведение сетевых таймаутов (таких как network_timeout и agent_query_timeout).

Если установлено в 0, таймауты ограничивают максимальное время отправки всего запроса/запроса. Если установлено в 1 (по умолчанию), таймауты ограничивают максимальное время между сетевой активностью.

При репликации узлу может потребоваться отправить большой файл (например, 100 ГБ) другому узлу. Предположим, что сеть может передавать данные со скоростью 1 ГБ/с, с серией пакетов по 4-5 МБ каждый. Для передачи всего файла потребуется 100 секунд. Таймаут по умолчанию в 5 секунд позволит передать только 5 ГБ, после чего соединение будет разорвано. Увеличение таймаута могло бы быть обходным решением, но это не масштабируемо (например, следующий файл может быть 150 ГБ, что снова приведет к сбою). Однако при установленном по умолчанию reset_network_timeout_on_packet в 1 таймаут применяется не ко всей передаче, а к отдельным пакетам. Пока передача продолжается (и данные действительно принимаются по сети в течение периода таймаута), соединение поддерживается. Если передача застревает, и таймаут происходит между пакетами, соединение будет разорвано.

Обратите внимание, что если вы настраиваете распределенную таблицу, каждый узел — как мастер, так и агенты — должен быть настроен. На стороне мастера влияет agent_query_timeout; на агентах — network_timeout.

Период проверки сброса чанков RAM RT-таблиц, в секундах (или special_suffixes). Необязательно, по умолчанию 10 часов.

Активно обновляемые RT-таблицы, полностью помещающиеся в чанки RAM, могут приводить к постоянно растущим бинлогам, что влияет на использование диска и время восстановления после сбоев. С помощью этой директивы поисковый сервер выполняет периодические проверки сброса, и подходящие чанки RAM могут быть сохранены, что позволяет последующую очистку бинлогов. Подробнее см. в разделе Binary logging.

Максимальное количество операций ввода-вывода (в секунду), которые поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).

Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов OPTIMIZE. Гарантируется, что все операции оптимизации RT не будут генерировать больше дисковых IOPS (операций ввода-вывода в секунду), чем заданный лимит. Ограничение rt_merge_iops может уменьшить деградацию производительности поиска, вызванную слиянием.

Максимальный размер операции ввода-вывода, которую поток слияния чанков RT может начать. Необязательно, по умолчанию 0 (без ограничений).

Эта директива позволяет ограничить влияние операций ввода-вывода, возникающих из-за операторов OPTIMIZE. Операции ввода-вывода, превышающие этот лимит, будут разбиты на две или более операций, которые затем будут учитываться как отдельные операции в рамках лимита rt_merge_iops. Таким образом, гарантируется, что все операции оптимизации не будут генерировать более (rt_merge_iops * rt_merge_maxiosize) байт дискового ввода-вывода в секунду.

Предотвращает зависания searchd при ротации таблиц с огромным объемом данных для предварительного кэширования. Необязательно, по умолчанию 1 (включена бесшовная ротация). В системах Windows бесшовная ротация по умолчанию отключена.

Таблицы могут содержать данные, которые необходимо предварительно кэшировать в RAM. В настоящее время файлы .spa, .spb, .spi и .spm полностью предварительно кэшируются (они содержат данные атрибутов, данные блоб-атрибутов, таблицу ключевых слов и карту удаленных строк соответственно). Без бесшовной ротации ротация таблицы старается использовать как можно меньше RAM и работает следующим образом:

1. Новые запросы временно отклоняются (с кодом ошибки "retry");
2. searchd ожидает завершения всех текущих запросов;
3. Старая таблица освобождается, и ее файлы переименовываются;
4. Файлы новой таблицы переименовываются, и выделяется необходимая RAM;
5. Данные атрибутов и словаря новой таблицы предварительно загружаются в RAM;
6. searchd возобновляет обслуживание запросов из новой таблицы.

Однако если данных атрибутов или словаря много, этап предварительной загрузки может занять заметное время — до нескольких минут при загрузке файлов размером 1-5+ ГБ.

При включенной бесшовной ротации ротация работает следующим образом:

1. Выделяется RAM для хранения новой таблицы;
2. Данные атрибутов и словаря новой таблицы асинхронно предварительно загружаются в RAM;
3. При успешной загрузке старая таблица освобождается, и файлы обеих таблиц переименовываются;
4. При неудаче новая таблица освобождается;
5. В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.

Бесшовная ротация требует большего пикового использования памяти во время ротации (поскольку обе копии данных .spa/.spb/.spi/.spm — старая и новая — должны находиться в RAM во время предварительной загрузки новой копии). Среднее использование памяти остается прежним.

Этот параметр задает размер кэша блоков, используемого вторичными индексами. Необязательно, по умолчанию 8 МБ. Когда вторичные индексы работают с фильтрами, содержащими много значений (например, фильтры IN()), они читают и обрабатывают метаданные блоков для этих значений. В объединенных запросах этот процесс повторяется для каждой партии строк из левой таблицы, и каждая партия может повторно читать одни и те же метаданные в рамках одного объединенного запроса. Это может значительно повлиять на производительность. Кэш метаданных блоков хранит эти блоки в памяти, чтобы они могли быть повторно использованы последующими партиями.

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

Установка secondary_index_block_cache = 0 отключает кэш.

This option enables/disables the use of secondary indexes for search queries. It is optional, and the default is 1 (enabled). Note that you don't need to enable it for indexing as it is always enabled as long as the Manticore Columnar Library is installed. The latter is also required for using the indexes when searching. There are three modes available:

• 0: Disable the use of secondary indexes on search. They can be enabled for individual queries using analyzer hints
• 1: Enable the use of secondary indexes on search. They can be disabled for individual queries using analyzer hints
• force: Same as enable, but any errors during the loading of secondary indexes will be reported, and the whole index will not be loaded into the daemon.

Integer number that serves as a server identifier used as a seed to generate a unique short UUID for nodes that are part of a replication cluster. The server_id must be unique across the nodes of a cluster and in the range from 0 to 127. If server_id is not set, it is calculated as a hash of the MAC address and the path to the PID file or a random number will be used as a seed for the short UUID.

searchd --stopwait waiting time, in seconds (or special_suffixes). Optional, default is 60 seconds.

When you run searchd --stopwait your server needs to perform some activities before stopping, such as finishing queries, flushing RT RAM chunks, flushing attributes, and updating the binlog. These tasks require some time. searchd --stopwait will wait up to shutdown_time seconds for the server to finish its jobs. The suitable time depends on your table size and load.

A prefix to prepend to the local file names when generating snippets. Optional, default is the current working folder.

This prefix can be used in distributed snippets generation along with load_files or load_files_scattered options.

Note that this is a prefix and not a path! This means that if a prefix is set to "server1" and the request refers to "file23", searchd will attempt to open "server1file23" (all of that without quotes). So, if you need it to be a path, you have to include the trailing slash.

After constructing the final file path, the server unwinds all relative dirs and compares the final result with the value of snippet_file_prefix. If the result does not begin with the prefix, such a file will be rejected with an error message.

For example, if you set it to /mnt/data and someone calls snippet generation with the file ../../../etc/passwd as the source, they will get the error message:

File '/mnt/data/../../../etc/passwd' escapes '/mnt/data/' scope

instead of the content of the file.

Also, with a non-set parameter and reading /etc/passwd, it will actually read /daemon/working/folder/etc/passwd since the default for the parameter is the server's working folder.

Note also that this is a local option; it does not affect the agents in any way. So you can safely set a prefix on a master server. The requests routed to the agents will not be affected by the master's setting. They will, however, be affected by the agent's own settings.

This might be useful, for instance, when the document storage locations (whether local storage or NAS mountpoints) are inconsistent across the servers.

Path to a file where the current SQL state will be serialized.

On server startup, this file gets replayed. On eligible state changes (e.g., SET GLOBAL), this file gets rewritten automatically. This can prevent a hard-to-diagnose problem: If you load UDF functions but Manticore crashes, when it gets (automatically) restarted, your UDF and global variables will no longer be available. Using persistent state helps ensure a graceful recovery with no such surprises.

sphinxql_state cannot be used to execute arbitrary commands, such as CREATE TABLE.

Maximum time to wait between requests (in seconds, or special_suffixes) when using the SQL interface. Optional, default is 15 minutes.

Path to the SSL Certificate Authority (CA) certificate file (also known as root certificate). Optional, default is empty. When not empty, the certificate in ssl_cert should be signed by this root certificate.

Сервер использует файл CA для проверки подписи на сертификате. Файл должен быть в формате PEM.

Путь к SSL-сертификату сервера. Необязательно, по умолчанию пусто.

Сервер использует этот сертификат как самоподписанный открытый ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.

Путь к ключу SSL-сертификата. Необязательно, по умолчанию пусто.

Сервер использует этот приватный ключ для шифрования HTTP-трафика по SSL. Файл должен быть в формате PEM.

Максимальный размер кеша документов общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).

Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. multi-queries). Максимум столько ОЗУ будет потрачено на кеширование записей документов для каждого запроса. Установка лимита в 0 отключает оптимизатор.

Максимальный размер кеша попаданий общего поддерева, на запрос. Необязательно, по умолчанию 0 (отключено).

Эта настройка ограничивает использование ОЗУ оптимизатором общего поддерева (см. multi-queries). Максимум столько ОЗУ будет потрачено на кеширование вхождений ключевых слов (попаданий) для каждого запроса. Установка лимита в 0 отключает оптимизатор.

Количество рабочих потоков (или размер пула потоков) для демона Manticore. Manticore создаёт такое количество потоков ОС при запуске, и они выполняют все задачи внутри демона, такие как выполнение запросов, создание сниппетов и т.д. Некоторые операции могут быть разбиты на подзадачи и выполняться параллельно, например:

• Поиск в таблице реального времени
• Поиск в распределённой таблице, состоящей из локальных таблиц
• Вызов перколяции запроса
• и другие

По умолчанию установлено количество ядер CPU на сервере. Manticore создаёт потоки при запуске и держит их до остановки. Каждая подзадача может использовать один из потоков, когда это необходимо. Когда подзадача завершается, она освобождает поток, чтобы другая подзадача могла его использовать.

В случае интенсивной нагрузки типа I/O может иметь смысл установить значение выше количества ядер CPU.

Максимальный размер стека для задачи (корутина, один поисковый запрос может вызвать несколько задач/корутин). Необязательно, по умолчанию 128K.

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

Установка значения на разумно высоком уровне поможет обрабатывать очень глубокие запросы без значительного увеличения общего потребления ОЗУ. Например, установка 1G не означает, что каждая новая задача будет занимать 1G ОЗУ, но если мы видим, что требуется, скажем, 100M стека, мы выделяем 100M для задачи. Другие задачи в это время будут работать со стандартным стеком 128K. Аналогично, можно запускать ещё более сложные запросы, которым нужен стек в 500M. И только если мы увидим внутренне, что задача требует более 1G стека, мы завершимся с ошибкой и сообщим о слишком низком thread_stack.

Однако на практике даже запрос, требующий 16M стека, часто слишком сложен для парсинга и потребляет слишком много времени и ресурсов для обработки. Поэтому демон обработает его, но ограничение таких запросов настройкой thread_stack выглядит вполне разумным.

Определяет, следует ли удалять копии таблиц с расширением .old после успешной ротации. Необязательно, по умолчанию 1 (удалять).

Поточный сторож сервера. Необязательно, по умолчанию 1 (сторож включён).

Когда запрос Manticore аварийно завершается, он может привести к падению всего сервера. При включённой функции сторожа searchd также поддерживает отдельный лёгкий процесс, который следит за основным процессом сервера и автоматически перезапускает его в случае ненормального завершения. Сторож включён по умолчанию.