Конфигурация Manticore поддерживает синтаксис shebang, позволяющий писать конфигурацию на языке программирования и интерпретировать её при загрузке. Это даёт возможность динамически задавать настройки, например, создавать таблицы, выполняя запросы к таблице базы данных, изменять настройки в зависимости от внешних факторов или включать внешние файлы с объявлениями таблиц и источников.

Файл конфигурации разбирается объявленным интерпретатором, а его вывод используется в качестве фактической конфигурации. Это происходит каждый раз при чтении конфигурации, а не только при запуске searchd.

Примечание: эта функция недоступна на платформе Windows.

В следующем примере используется PHP для создания нескольких таблиц с разными именами и для сканирования определённой папки на наличие файлов с дополнительными объявлениями таблиц:

#!/usr/bin/php
...
<?php for ($i=1; $i<=6; $i++) { ?>
table test_<?=$i?> {
  type = rt
  path = /var/lib/manticore/data/test_<?=$i?>
  rt_field = subject
  ...
 }
 <?php } ?>
 ...
 <?php
 $confd_folder='/etc/manticore.conf.d/';
 $files = scandir($confd_folder);
 foreach($files as $file)
 {
         if(($file == '.') || ($file =='..'))
         {} else {
                 $fp = new SplFileInfo($confd_folder.$file);
                 if('conf' == $fp->getExtension()){
                         include ($confd_folder.$file);
                 }
         }
 }
 ?>

Файл конфигурации Manticore Search поддерживает комментарии, которые помогают предоставлять пояснения или заметки внутри файла конфигурации. Символ # используется для начала секции комментария. Вы можете разместить символ комментария либо в начале строки, либо внутри строки.

При использовании комментариев будьте осторожны при включении символа # в настройки токенизации символов, так как всё, что следует за ним, будет проигнорировано. Чтобы этого избежать, используйте UTF-8 код #, который равен U+23.

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

Наследование в объявлениях index и source позволяет лучше организовать таблицы с похожими настройками или структурами и уменьшить размер конфигурации. Наследование могут использовать как родительские, так и дочерние таблицы или источники.

Для родительской таблицы или источника не требуется никаких специальных настроек.

В объявлении дочерней таблицы или источника укажите имя таблицы или источника, за которым следует двоеточие (:) и имя родителя:

table parent {
path = /var/lib/manticore/parent
...
}
table child:parent {
path = /var/lib/manticore/child
...
}

Дочерняя таблица унаследует всю конфигурацию родителя. Любые настройки, объявленные в дочерней таблице, перезапишут унаследованные значения. Обратите внимание, что для настроек с несколькими значениями определение одного значения в дочерней таблице очистит все унаследованные значения. Например, если у родителя есть несколько объявлений sql_query_pre, а у дочерней таблицы одно объявление sql_query_pre, все унаследованные объявления sql_query_pre будут очищены. Чтобы переопределить некоторые унаследованные значения от родителя, явно объявите их в дочерней таблице. Это также применимо, если вам не нужно значение от родителя. Например, если значение sql_query_pre от родителя не нужно, объявите директиву с пустым значением в дочерней таблице, например sql_query_pre=.

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

Поведение наследования применяется к полям и атрибутам, а не только к опциям таблицы. Например, если у родителя есть два целочисленных атрибута, а дочерней таблице нужен новый целочисленный атрибут, объявления целочисленных атрибутов от родителя должны быть скопированы в конфигурацию дочерней таблицы.

SET [GLOBAL] server_variable_name = value
SET [INDEX table_name] GLOBAL @user_variable_name = (int_val1 [, int_val2, ...])
SET NAMES value [COLLATE value]
SET @@dummy_variable = ignored_value

Оператор SET в Manticore Search позволяет изменять значения переменных. Имена переменных не чувствительны к регистру, и изменения значений переменных не сохраняются после перезапуска сервера.

Manticore Search поддерживает оператор SET NAMES и синтаксис SET @@variable_name для совместимости с клиентскими библиотеками MySQL, коннекторами и фреймворками сторонних разработчиков, которые могут требовать выполнения этих операторов при подключении. Однако эти операторы не влияют на сам Manticore Search.

В Manticore Search существует четыре класса переменных:

1. Переменная сервера на сессию: set var_name = value
2. Глобальная переменная сервера: set global var_name = value
3. Глобальная пользовательская переменная: set global @var_name = (value)
4. Глобальная распределённая переменная: set index dist_table_name global @var_name = (value)

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

// in session 1
mysql> SET GLOBAL @myfilter=(2,3,5,7,11,13);
Query OK, 0 rows affected (0.00 sec)
// later in session 2
mysql> SELECT * FROM test1 WHERE group_id IN @myfilter;
+------+--------+----------+------------+-----------------+------+
| id   | weight | group_id | date_added | title           | tag  |
+------+--------+----------+------------+-----------------+------+
|    3 |      1 |        2 | 1299338153 | another doc     | 15   |
|    4 |      1 |        2 | 1299338153 | doc number four | 7,40 |
+------+--------+----------+------------+-----------------+------+
2 rows in set (0.02 sec)

Manticore Search поддерживает переменные сервера на сессию и глобальные переменные сервера, которые влияют на определённые настройки сервера в соответствующих областях видимости. Ниже приведён список известных переменных сервера на сессию и глобальных переменных сервера:

Известные переменные сервера на сессию:

• AUTOCOMMIT = {0 | 1} определяет, должны ли операторы изменения данных автоматически оборачиваться в BEGIN и COMMIT.

• COLLATION_CONNECTION = collation_name выбирает сортировку для ORDER BY или GROUP BY по строковым значениям в последующих запросах. Список известных имён сортировок см. в разделе Collations.

• MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE> переопределяет max_threads_per_query во время выполнения. Переменная на сессию влияет только на запросы, выполняемые в той же сессии (подключении), то есть до отключения. Значение 0 означает «без ограничений». Если установлены обе переменные — на сессию и глобальная, приоритет выше у переменной на сессию.

• net_write_timeout = <value>: Настраивает сетевой таймаут для операций записи, то есть отправки данных. Глобальное значение можно изменить только с привилегиями VIP.

• optimize_by_id = {0 | 1}: Внутренний флаг, используемый в некоторых командах debug.

• PROFILING = {0 | 1} включает профилирование запросов в текущей сессии. По умолчанию 0. См. также show profile.

• ro = {1 | 0} переключает сессию в режим только для чтения или обратно. В выводе show variables переменная отображается под именем session_read_only.

• throttling_period = <INT_VALUE>: Интервал (в миллисекундах), через который текущий выполняющийся запрос будет перепланирован. Значение 0 отключает ограничение, то есть запрос будет занимать CPU до завершения. Если в это время поступают параллельные запросы из других подключений, они будут распределены на свободные ядра или приостановлены до освобождения ядра. Указание отрицательного значения (-1) сбрасывает ограничение до значения по умолчанию, заданного при компиляции (100 мс), что означает перепланирование запроса каждые 100 мс, давая возможность выполнять параллельные запросы. Глобальное значение (устанавливаемое через set global) можно задать только с VIP-подключения.

• thread_stack = <value>: Изменяет значение по умолчанию на лету, ограничивающее размер стека, выделяемого одной задаче. Обратите внимание, что здесь «поток» — это не поток ОС, а поток в пространстве пользователя, также известный как корутина. Это может быть полезно, например, если вы загружаете таблицу percolate с неожиданно высокими требованиями. В таких случаях 'call pq' может завершиться с сообщением о недостаточном размере стека. Обычно следует остановить демон, увеличить значение в конфиге и перезапустить. Однако можно попробовать новое значение без перезапуска, установив его через эту переменную. Глобальное значение также можно изменить онлайн с помощью set global thread_stack, но это доступно только с VIP-подключения.

• threads_ex (диагностическая): Заставляет Manticore вести себя так, как если бы он работал на CPU с указанным профилем. Краткий пример: set threads_ex='4/2+6/3' означает «у вас 4 свободных ядра CPU, при планировании нескольких запросов их следует группировать по 2. Также у вас есть 6 свободных ядер для псевдо-шардинга, части следует группировать по 3». Эта опция диагностическая, так как очень полезна, например, чтобы увидеть, как ваш запрос будет выполняться на конфигурации, которой у вас нет локально. Например, на 128-ядерном CPU. Или, наоборот, быстро ограничить демон однопоточным режимом, чтобы найти узкое место или исследовать сбой.

  MORE
  * `WAIT_TIMEOUT/net_read_timeout = ` задаёт таймаут соединения, либо для сессии, либо глобально. Глобально можно установить только на VIP-соединении.

  Известные глобальные переменные сервера:

  • ACCURATE_AGGREGATION: задаёт значение по умолчанию для опции accurate_aggregation будущих запросов.
  • AUTO_OPTIMIZE = {1|0} Включает/выключает auto_optimize.
  • cluster_user = name Задаёт имя пользователя, используемое с mysqldump / mariadb-dump для включения режима репликации.
  • COREDUMP= {1|0} Включает/выключает сохранение core-файла или минидампа сервера при сбое. Подробнее здесь.
  • CPUSTATS= {1|0} Включает/выключает отслеживание времени CPU.
  • DISTINCT_PRECISION_THRESHOLD: задаёт значение по умолчанию для опции distinct_precision_threshold будущих запросов.
  • ES_COMPAT = {on/off/dashboards} При установке в on (по умолчанию) поддерживаются запросы на запись, похожие на Elasticsearch; off отключает поддержку; dashboards включает поддержку и также разрешает запросы из Kibana (эта функциональность экспериментальная).
  • EXPANSION_MERGE_THRESHOLD_DOCS: изменяет значение настройки конфигурации expansion_merge_threshold_docs на лету.
  • EXPANSION_MERGE_THRESHOLD_HITS: изменяет значение настройки конфигурации expansion_merge_threshold_hits на лету.
  • GROUPING_IN_UTC = {0 | 1} При установке в 1 функции группировки по времени (day(), month(), year(), yearmonth(), yearmonthday()) вычисляются в UTC. Подробнее см. документацию по параметрам конфигурации grouping_in_utc.
  • IOSTATS = {0 | 1} Включает или отключает отчётность о I/O операциях (кроме атрибутов) в журнале запросов.
  • LOG_DEBUG_FILTER = <string value> Фильтрует избыточные сообщения журнала. Если значение установлено, то все логи с уровнем > INFO (то есть DEBUG, DEBUGV и т. п.) будут сравниваться со строкой и выводиться только если начинаются с данного значения.
  • LOG_LEVEL = {info | debug | replication | debugv | debugvv} Изменяет текущий уровень подробности журнала.
  • MAINTENANCE = {0 | 1} При установке в 1 переводит сервер в режим обслуживания. В этом режиме запросы могут выполнять только клиенты с VIP-соединениями. Все новые не-VIP соединения отклоняются. Существующие соединения остаются без изменений.
  • MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE> Переопределяет max_threads_per_query во время работы. Как глобальная переменная, изменяет поведение для всех сессий. Значение 0 означает «без ограничений». Если установлены и переменная на сессию, и глобальная, приоритет выше у переменной на сессию.
  • NET_WAIT = {-1 | 0 | POSITIVE_INT_VALUE} Изменяет значение настройки net_wait_tm searchd.
  • OPTIMIZE_CUTOFF = <value>: изменяет значение настройки конфигурации optimize_cutoff на лету.
  • PSEUDO_SHARDING = {1|0} Включает/выключает поиск с использованием псевдо-шардинга.
  • QCACHE_MAX_BYTES = <value> Изменяет лимит использования оперативной памяти query_cache на заданное значение.
  • QCACHE_THRESH_MSEC = <value> Изменяет минимальный порог времени выполнения query_cache на заданное значение.
  • QCACHE_TTL_SEC = <value> Изменяет TTL для кэшированного результата в query_cache на заданное значение.
  • QUERY_LOG_FORMAT = {plain | sphinxql} Изменяет текущий формат журнала.
  • QUERY_LOG_MIN_MSEC = <value> Изменяет значение настройки query_log_min_msec для searchd. В этом случае ожидается значение именно в миллисекундах, и суффиксы времени, как в конфиге, не обрабатываются.

    Внимание: это очень специфичная и «жёсткая» переменная; отфильтрованные сообщения просто не будут записаны в журнал. Лучше фильтровать журнал с помощью чего-то вроде 'grep', в этом случае у вас будет хотя бы полный оригинальный журнал в резервной копии.

  • RESET_NETWORK_TIMEOUT_ON_PACKET = {1|0} изменяет параметр reset_network_timeout_on_packet. Изменять эту переменную могут только клиенты с VIP-подключениями.
  • SECONDARY_INDEXES = {1|0} Включает/выключает вторичные индексы для поисковых запросов.
  • TIMEZONE = <value> Указывает часовой пояс, используемый функциями, связанными с датой и временем. Подробнее см. документацию по параметру конфигурации timezone.

  Примеры:

  mysql> SET autocommit=0;
  Query OK, 0 rows affected (0.00 sec)
  mysql> SET GLOBAL query_log_format=sphinxql;
  Query OK, 0 rows affected (0.00 sec)
  mysql> SET GLOBAL @banned=(1,2,3);
  Query OK, 0 rows affected (0.01 sec)
  mysql> SET INDEX users GLOBAL @banned=(1,2,3);
  Query OK, 0 rows affected (0.01 sec)

  Чтобы сделать пользовательские переменные постоянными, убедитесь, что включён sphinxql_state.