Manticore можно установить на Windows несколькими способами. Мы рекомендуем использовать WSL (Подсистема Windows для Linux), так как она поддерживает репликацию и не требует Docker. Ниже приведены рекомендуемые и альтернативные методы.

Для установки Manticore Search на Windows сначала необходимо включить Подсистему Windows для Linux. WSL2 позволяет запускать Linux-бинарные файлы нативно на Windows. Для работы этого метода требуется Windows 10 версии 2004 и выше или Windows 11.

Следуйте официальному руководству Microsoft для пошаговой установки WSL2.

Для установки Manticore на Windows через WSL2 обратитесь к разделу Установка на Debian и Ubuntu.

ПРИМЕЧАНИЕ: Установка Manticore через WSL2 — рекомендуемый метод, так как он обеспечивает лучшую совместимость по сравнению с использованием нативных пакетов Windows.

В качестве альтернативы вы можете установить Manticore как нативные бинарные файлы Windows, для которых требуется Docker для Manticore Buddy, выполнив следующие шаги:

1. Установите Docker Desktop и запустите его.
2. Скачайте установщик Manticore Search (ссылку можно найти на странице установки) и запустите его. Следуйте инструкциям по установке.
3. Выберите каталог для установки.
4. Выберите компоненты, которые хотите установить. Рекомендуется установить все.
5. Manticore поставляется с преднастроенным файлом manticore.conf в RT режиме. Дополнительная настройка не требуется.

ПРИМЕЧАНИЕ: Нативные бинарные файлы Windows не поддерживают репликацию.

Для установки сервера Manticore Search как службы Windows выполните:

\path\to\searchd.exe --install --config \path\to\config --servicename Manticore

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

После установки службу можно запустить через оснастку Службы в Microsoft Management Console.

После запуска вы можете получить доступ к Manticore через интерфейс командной строки MySQL:

mysql -P9306 -h127.0.0.1

Обратите внимание, что в большинстве примеров в этом руководстве мы используем -h0 для подключения к локальному хосту, но в Windows необходимо явно использовать localhost или 127.0.0.1.

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

Для подготовки официальных релизных и девелоперских пакетов мы используем Docker и специальный образ для сборки. Этот образ включает необходимые инструменты и предназначен для использования с внешними sysroots, так что один контейнер может собирать пакеты для всех операционных систем. Вы можете собрать образ, используя Dockerfile и README или использовать образ с Docker Hub. Это самый простой способ создать бинарные файлы для любой поддерживаемой операционной системы и архитектуры. Также вам нужно будет указать следующие переменные окружения при запуске контейнера:

• DISTR: целевая платформа: bionic, focal, jammy, buster, bullseye, bookworm, rhel7, rhel8, rhel9, rhel10, macos, windows, freebsd13
• arch: архитектура: x86_64, x64 (для Windows), aarch64, arm64 (для Macos)
• SYSROOT_URL: URL архивов системных корней. Вы можете использовать https://repo.manticoresearch.com/repository/sysroots, если не собираете sysroots самостоятельно (инструкции можно найти здесь).
• Используйте файлы CI workflow в качестве справочника, чтобы найти другие переменные окружения, которые могут понадобиться:
  • https://github.com/manticoresoftware/manticoresearch/blob/master/.github/workflows/pack_publish.yml
  • https://github.com/manticoresoftware/manticoresearch/blob/master/.github/workflows/build_template.yml

Чтобы узнать возможные значения для DISTR и arch, вы можете использовать каталог https://repo.manticoresearch.com/repository/sysroots/roots_with_zstd/ в качестве справочника, так как он содержит sysroots для всех поддерживаемых комбинаций.

После этого сборка пакетов внутри Docker-контейнера так же проста, как вызов:

cmake -DPACK=1 /path/to/sources
cmake --build .

Например, чтобы создать пакет для Ubuntu Jammy, аналогичный официальной версии, предоставляемой командой Manticore Core, выполните следующие команды в каталоге с исходниками Manticore Search. Этот каталог является корнем клонированного репозитория с https://github.com/manticoresoftware/manticoresearch:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=jammy \
-e boost=boost_nov22 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/dist/build_dockers/cross/linux.cmake
cmake --build .
# or if you want to build packages:
# cmake --build . --target package

Требуется длинный путь к каталогу исходников, иначе сборка может не пройти в некоторых случаях (например, Centos).

Аналогично, вы можете собирать бинарные файлы или пакеты не только для популярных дистрибутивов Linux, но и для FreeBSD, Windows и macOS.

Вы также можете использовать тот же специальный образ Docker для сборки SRPM:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=rhel8 \
-e boost=boost_rhel_feb17 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/../dist/build_dockers/cross/linux.cmake
# The CPackSourceConfig.cmake file is now generated in the build directory
cpack -G RPM --config ./CPackSourceConfig.cmake

Это создаст Source RPM (.src.rpm файл), содержащий весь исходный код.

После создания SRPM вы можете использовать его для сборки полного набора бинарных RPM пакетов:

# Install build tools and dependencies
dnf install -y rpm-build cmake gcc-c++ boost-devel epel-release
# Install SRPM dependencies automatically
dnf builddep -y manticore-*.src.rpm
# Build all binary RPMs from the SRPM
rpmbuild --rebuild manticore-*.src.rpm
# Find the generated packages
ls ~/rpmbuild/RPMS/*/manticore*

ПРИМЕЧАНИЕ: Для сборки RPM из SRPM необходимо убедиться, что все зависимости, указанные в SRPM, полностью установлены, что может быть сложно. SRPM всё равно может быть полезен для:

• Аудита процесса сборки или изучения исходников и spec-файлов
• Внесения пользовательских изменений или патчей в сборку
• Понимания, как были созданы бинарные файлы
• Соблюдения требований лицензий с открытым исходным кодом

Компиляция Manticore без использования Docker для сборки не рекомендуется, но если вам нужно это сделать, вот что может быть полезно знать:

• Компилятор C++
  • В Linux - можно использовать GNU (4.7.2 и выше) или Clang
  • В Windows - Microsoft Visual Studio 2019 и выше (достаточно community edition)
  • На macOS - Clang (из командных инструментов XCode, используйте xcode-select --install для установки).
• Bison, Flex - на большинстве систем доступны как пакеты, в Windows доступны в среде cygwin.
• Cmake - используется на всех платформах (требуется версия 3.19 или выше)

Исходный код Manticore размещён на GitHub. Чтобы получить исходный код, клонируйте репозиторий и затем переключитесь на нужную ветку или тег. Ветка master представляет основную ветку разработки. При выпуске создаётся тег с версией, например 3.6.0, и начинается новая ветка для текущего релиза, в данном случае manticore-3.6.0. Голова версии ветки после всех изменений используется как источник для сборки всех бинарных релизов. Например, чтобы взять исходники версии 3.6.0, выполните:

git clone https://github.com/manticoresoftware/manticoresearch.git
cd manticoresearch
git checkout manticore-3.6.0

Вы можете скачать нужный код с GitHub, используя кнопку "Download ZIP". Подходят форматы .zip и .tar.gz.

wget -c https://github.com/manticoresoftware/manticoresearch/archive/refs/tags/3.6.0.tar.gz
tar -zxf 3.6.0.tar.gz
cd manticoresearch-3.6.0

Manticore использует CMake. Предположим, вы находитесь в корневом каталоге клонированного репозитория:

mkdir build && cd build
cmake ..

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

Вы также можете явно настроить сборку с помощью флагов и опций. Чтобы включить функцию FOO, добавьте -DFOO=1 к вызову CMake. Чтобы отключить, используйте -DFOO=0. Если явно не указано иное, включение функции, которая недоступна((например, WITH_GALERA в сборке для MS Windows)) приведет к ошибке конфигурации. Отключение функции, помимо исключения её из сборки, также отключает её проверку в системе и загрузку/сборку любых связанных внешних библиотек.

• USE_SYSLOG - позволяет использовать syslog в логировании запросов.
• WITH_GALERA - Включает поддержку репликации в поисковом демоне. Поддержка будет настроена для сборки, а исходники библиотеки Galera будут загружены, собраны и включены в дистрибутив/установку. Обычно безопасно собирать с Galera, но не распространять саму библиотеку (то есть без модуля Galera, без репликации). Однако иногда может потребоваться явно отключить её, например, если вы хотите собрать статический бинарный файл, который по конструкции не может загружать библиотеки, так что даже наличие вызова функции 'dlopen' внутри демона вызовет ошибку линковки.
• WITH_RE2 - Сборка с использованием библиотеки регулярных выражений RE2. Это необходимо для функций, таких как REGEX(), и функции regexp_filter.
• WITH_RE2_FORCE_STATIC - Загружает исходники RE2, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки RE2 в вашей системе.
• WITH_STEMMER - Сборка с использованием библиотеки стемминга Snowball.
• WITH_STEMMER_FORCE_STATIC - Загружает исходники Snowball, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки libstemmer в вашей системе.
• WITH_ICU - Сборка с библиотекой ICU (International Components for Unicode). Используется для сегментации китайского текста. Применяется при использовании morphology=icu_chinese.
• WITH_JIEBA - Сборка с инструментом сегментации китайского текста Jieba. Используется для сегментации китайского текста. Применяется при использовании morphology=jieba_chinese.
• WITH_ICU_FORCE_STATIC - Загружает исходники ICU, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки icu в вашей системе. Также включает файл данных ICU в установку/дистрибутив. Цель статической линковки ICU — иметь библиотеку известной версии, чтобы поведение было определённым и не зависело от системных библиотек. Скорее всего, вы предпочтёте использовать системную ICU, так как она может обновляться без необходимости перекомпиляции демона Manticore. В этом случае нужно явно отключить эту опцию. Это также сэкономит место, занимаемое файлом данных ICU (около 30М), так как он не будет включён в дистрибутив.
• WITH_SSL - Используется для поддержки HTTPS, а также зашифрованных MySQL-соединений с демоном. Системная библиотека OpenSSL будет связана с демоном. Это означает, что для запуска демона потребуется OpenSSL. Это обязательно для поддержки HTTPS, но не строго обязательно для сервера (то есть отсутствие SSL означает невозможность подключения по HTTPS, но другие протоколы будут работать). Manticore может использовать версии SSL-библиотеки от 1.0.2 до 1.1.1, однако в целях безопасности настоятельно рекомендуется использовать максимально свежую версию SSL-библиотеки. На данный момент поддерживается только версия 1.1.1, остальные устарели (см. стратегию релизов openssl).
• WITH_ZLIB - используется индексатором для работы с сжатыми колонками из MySQL. Используется демоном для поддержки сжатого протокола MySQL.
• WITH_ODBC - используется индексатором для поддержки индексации источников из ODBC-провайдеров (обычно UnixODBC и iODBC). В MS Windows ODBC — правильный способ работы с источниками MS SQL, поэтому индексация MSSQL также подразумевает этот флаг.
• DL_ODBC - не линкуется с библиотекой ODBC. Если ODBC линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с ODBC. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником ODBC.
• ODBC_LIB - имя файла библиотеки ODBC. Индексатор попытается загрузить этот файл при работе с источником ODBC. Эта опция автоматически устанавливается на основе обнаружения доступной общей библиотеки ODBC. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ODBC_LIB с правильным путём к альтернативной библиотеке перед запуском индексатора.
• WITH_EXPAT - используется индексатором для поддержки индексации источников xmlpipe.
• DL_EXPAT - не линкуется с библиотекой EXPAT. Если EXPAT линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником xmlpipe.
• EXPAT_LIB - имя файла библиотеки EXPAT. Индексатор попытается загрузить этот файл при работе с источником xmlpipe. Эта опция автоматически устанавливается на основе обнаружения доступной общей библиотеки EXPAT. Вы также можете переопределить это имя во время выполнения, задав переменную окружения EXPAT_LIB с правильным путём к альтернативной библиотеке перед запуском индексатора.
• WITH_ICONV - для поддержки различных кодировок при индексации источников xmlpipe с помощью индексатора.
• DL_ICONV - не линкуется с библиотекой iconv. Если iconv линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником xmlpipe.
• ICONV_LIB - имя файла библиотеки iconv. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник xmlpipe. Эта опция записывается автоматически на основе доступных исследованных разделяемых библиотек iconv. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ICONV_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• WITH_MYSQL - используется индексатором для поддержки индексирования источников MySQL.
• DL_MYSQL - не связывать с библиотекой MySQL. Если MySQL связана, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с MySQL. Эта опция заставляет индексатор загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником MySQL.
• MYSQL_LIB -- имя файла библиотеки MySQL. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник MySQL. Эта опция записывается автоматически на основе доступных исследованных разделяемых библиотек MySQL. Вы также можете переопределить это имя во время выполнения, задав переменную окружения MYSQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• WITH_POSTGRESQL - используется индексатором для поддержки индексирования источников PostgreSQL.
• DL_POSTGRESQL - не связывать с библиотекой PostgreSQL. Если PostgreSQL связана, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с PostgreSQL. Эта опция заставляет индексатор загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником PostgreSQL.
• POSTGRESQL_LIB - имя файла библиотеки postgresql. Индексатор попытается загрузить указанный файл библиотеки postgresql при обработке источника postgresql. Эта опция автоматически определяется на основе доступных исследованных разделяемых библиотек postgresql. Вы также можете переопределить имя во время выполнения, задав переменную окружения POSTGRESQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• LOCALDATADIR - путь по умолчанию, где демон хранит binlogs. Если этот путь не указан или явно отключен в конфигурации времени выполнения демона (т.е. в файле manticore.conf, который не связан с этой конфигурацией сборки), binlogs будут размещены в этом пути. Обычно это абсолютный путь, однако он не обязательно должен быть таковым, можно использовать и относительные пути. Вероятно, вам не нужно менять значение по умолчанию, определённое конфигурацией, которое, в зависимости от целевой системы, может быть таким, как /var/data, /var/lib/manticore/data или /usr/local/var/lib/manticore/data.
• FULL_SHARE_DIR - путь по умолчанию, где хранятся все ресурсы. Его можно переопределить переменной окружения FULL_SHARE_DIR перед запуском любого инструмента, который использует файлы из этой папки. Это важный путь, так как многие вещи по умолчанию ожидаются именно там. Сюда входят предопределённые таблицы символов, стоп-слова, модули manticore и файлы данных icu, все размещённые в этой папке. Скрипт конфигурации обычно определяет этот путь как что-то вроде /usr/share/manticore или /usr/local/share/manticore.
• DISTR_BUILD - ярлык для опций выпуска пакетов. Это строковое значение с именем целевой платформы. Его можно использовать вместо ручной настройки всех опций. В Debian и Redhat Linux значение по умолчанию может определяться лёгкой интроспекцией и устанавливаться как общее 'Debian' или 'RHEL'. В противном случае значение не определено.
• PACK - ещё более удобный ярлык. Он читает переменную окружения DISTR, присваивает её параметру DISTR_BUILD, а затем работает как обычно. Это очень полезно при сборке в подготовленных системах сборки, таких как контейнеры Docker, где переменная DISTR установлена на уровне системы и отражает целевую систему, для которой предназначен контейнер.
• CMAKE_INSTALL_PREFIX (путь) - где ожидается установка Manticore. Сборка не выполняет установку, но подготавливает правила установки, которые выполняются при запуске команды cmake --install или создании пакета с последующей установкой. Префикс можно изменить в любое время, даже во время установки, вызвав cmake --install . --prefix /path/to/installation. Однако во время конфигурации эта переменная используется для инициализации значений по умолчанию для LOCALDATADIR и FULL_SHARE_DIR. Например, установка её в /my/custom во время конфигурации зафиксирует LOCALDATADIR как /my/custom/var/lib/manticore/data, а FULL_SHARE_DIR как /my/custom/usr/share/manticore.
• BUILD_TESTING (bool) поддержка тестирования. Если включено, после сборки вы можете запустить 'ctest' и протестировать сборку. Обратите внимание, что тестирование подразумевает дополнительные зависимости, такие как наличие PHP cli, Python и доступного сервера MySQL с тестовой базой данных. По умолчанию этот параметр включён. Поэтому для «просто сборки» вы, возможно, захотите отключить опцию, явно указав значение 'off'.
• BUILD_SRPMS (bool) показывать инструкции по сборке исходных RPM-пакетов (SRPM). Из-за ограничений CPack с упаковкой на основе компонентов, SRPM не могут быть сгенерированы напрямую вместе с бинарными RPM. При включении система сборки покажет инструкции для правильной генерации SRPM с использованием метода конфигурации исходников. По умолчанию этот параметр выключен.
• LIBS_BUNDLE - путь к папке с различными библиотеками. Это в основном актуально для сборки под Windows, но может быть полезно, если вам часто приходится собирать, чтобы избежать загрузки сторонних исходников каждый раз. По умолчанию этот путь не изменяется скриптом конфигурации; вы должны положить всё туда вручную. Например, если нужна поддержка стеммера — исходники будут загружены с домашней страницы Snowball, затем распакованы, сконфигурированы, собраны и т.д. Вместо этого вы можете хранить оригинальный архив исходников (который называется libstemmer_c.tgz) в этой папке. В следующий раз при сборке с нуля скрипт конфигурации сначала проверит наличие стеммера в бандле, и если он там есть, не будет загружать его снова из Интернета.
• CACHEB - путь к папке с сохранёнными сборками сторонних библиотек. Обычно такие функции, как galera, re2, icu и т.д., сначала скачиваются или берутся из бандла, затем распаковываются, собираются и устанавливаются во временную внутреннюю папку. При сборке manticore эта папка затем используется как место, где находятся необходимые для поддержки запрашиваемой функции компоненты. В итоге они либо линкуются с manticore, если это библиотека; либо идут напрямую в дистрибутив/установку (например, galera или данные icu). Когда CACHEB определён либо как параметр конфигурации cmake, либо как системная переменная окружения, он используется как целевая папка для этих сборок. Эта папка может сохраняться между сборками, чтобы сохранённые там библиотеки больше не пересобирались, что значительно сокращает весь процесс сборки. Обратите внимание, что некоторые опции организованы тройками: WITH_XXX, DL_XXX и XXX_LIB — например, поддержка mysql, odbc и т.д. WITH_XXX определяет, будут ли влиять следующие две. То есть, если вы установите WITH_ODBC в 0, нет смысла задавать DL_ODBC и ODBC_LIB, и эти две опции не будут иметь эффекта, если вся функция отключена. Также XXX_LIB не имеет смысла без DL_XXX, потому что если вы не хотите использовать опцию DL_XXX, динамическая загрузка не будет использоваться, и имя, заданное в XXX_LIB, бесполезно. Это используется по умолчанию для интроспекции. Также использование библиотеки iconv предполагает наличие expat и бесполезно, если последний отключён. Кроме того, некоторые библиотеки могут быть всегда доступны, и поэтому нет смысла избегать их линковки. Например, в Windows это ODBC. На macOS это Expat, iconv и, возможно, другие. По умолчанию интроспекция определяет такие библиотеки и фактически генерирует только WITH_XXX для них, без DL_XXX и XXX_LIB, что упрощает ситуацию.

С некоторыми опциями конфигурация может выглядеть так:

mkdir build && cd build

cmake -DWITH_MYSQL=1 -DWITH_RE2=1 ..

Помимо общих значений конфигурации, вы также можете изучить файл CMakeCache.txt, который остаётся в папке сборки сразу после запуска конфигурации. Любые значения, определённые там, могут быть переопределены явно при запуске cmake. Например, вы можете запустить cmake -DHAVE_GETADDRINFO_A=FALSE ..., и этот запуск конфигурации не будет учитывать исследуемое значение этой переменной, а будет использовать то, которое вы указали.

#### Специфические переменные окружения
Переменные окружения полезны для предоставления некоторого рода глобальных настроек, которые хранятся отдельно от конфигурации сборки и всегда присутствуют. Для постоянства их можно задать глобально в системе разными способами — например, добавив их в файл `.bashrc`, или встроив в Dockerfile, если вы создаёте систему сборки на основе Docker, или записав их в системные переменные окружения в настройках Windows. Также их можно задать временно с помощью `export VAR=value` в оболочке. Или ещё короче — предваряя вызов cmake значениями, например `CACHEB=/my/cache cmake ...` — так это будет работать только для этого вызова и не будет видно в следующем.

Некоторые из таких переменных известны и используются в целом cmake и другими инструментами. Это такие вещи, как CXX, определяющая текущий компилятор C++, или CXX_FLAGS для передачи флагов компилятора и т.д.

Однако у нас есть переменные, специфичные для конфигурации manticore, которые придуманы исключительно для наших сборок.

• CACHEB - то же, что и опция конфигурации CACHEB

• LIBS_BUNDLE - то же, что и опция конфигурации LIBS_BUNDLE

• DISTR - используется для инициализации опции DISTR_BUILD при использовании -DPACK=1.

• DIAGNOSTIC - делает вывод конфигурации cmake гораздо более подробным, объясняя всё происходящее

• WRITEB - предполагает LIBS_BUNDLE и, если установлена, будет скачивать исходные архивы для разных инструментов в папку LIBS_BUNDLE. То есть, если выходит свежая версия стеммера — вы можете вручную удалить libstemmer_c.tgz из бандла, а затем выполнить однократный запуск WRITEB=1 cmake ... — он не найдёт исходники стеммера в бандле и скачает их с сайта поставщика в бандл (без WRITEB он скачает их во временную папку внутри сборки, которая исчезнет при очистке папки сборки). В конце конфигурации вы можете увидеть, что доступно и будет использовано, в списке, похожем на этот: -- Enabled features compiled in:

• Galera, replication of tables

• re2, a regular expression library

* stemmer, stemming library (Snowball)
* icu, International Components for Unicode
* OpenSSL, for encrypted networking
* ZLIB, for compressed data and networking
* ODBC, for indexing MSSQL (windows) and generic ODBC sources with indexer
* EXPAT, for indexing xmlpipe sources with indexer
* Iconv, for support of different encodings when indexing xmlpipe sources with indexer
* MySQL, for indexing MySQL sources with indexer
* PostgreSQL, for indexing PostgreSQL sources with indexer
### Сборка
cmake --build . --config RelWithDebInfo
### Установка

Для установки выполните:

cmake --install . --config RelWithDebInfo

чтобы установить в пользовательскую (не по умолчанию) папку, выполните

cmake --install . --prefix path/to/build --config RelWithDebInfo

### Сборка пакетов

Для сборки пакета используйте цель package. Она соберёт пакет согласно выбору, заданному опцией -DDISTR_BUILD. По умолчанию это будет простой архив .zip или .tgz со всеми бинарными файлами и дополнительными файлами.

cmake --build . --target package --config RelWithDebInfo

Если вы не меняли путь к исходникам и сборке, просто перейдите в папку сборки и выполните:

cmake .

cmake --build . --clean-first --config RelWithDebInfo

Если по какой-то причине это не сработает, вы можете удалить файл CMakeCache.txt, расположенный в папке сборки. После этого шага вам нужно снова запустить cmake, указав папку с исходниками и настроив опции.

Если и это не поможет, просто очистите папку сборки и начните заново.
### Типы сборок

Кратко — просто используйте --config RelWithDebInfo, как указано выше. Это не вызовет ошибок. Мы используем два типа сборок. Для разработки — Debug — он задаёт флаги компилятора для оптимизации и других вещей так, чтобы было удобно для разработки, то есть отладка с пошаговым выполнением. Однако получаемые бинарники довольно большие и медленные для продакшена.

Для релиза мы используем другой тип — RelWithDebInfo — что означает «релизная сборка с отладочной информацией». Она создаёт продакшн-бинарники с встроенной отладочной информацией. Последняя затем выносится в отдельные пакеты с отладочной информацией, которые хранятся отдельно от релизных пакетов и могут использоваться в случае проблем, например, с крашами — для расследования и исправления ошибок. Cmake также предоставляет Release и MinSizeRel, но мы их не используем. Если тип сборки недоступен, cmake сделает сборку noconfig.

Существуют два типа генераторов: single-config и multi-config.

• Single-config требует указания типа сборки во время конфигурации через параметр CMAKE_BUILD_TYPE. Если он не определён, сборка по умолчанию будет использовать тип RelWithDebInfo, что подходит, если вы просто хотите собрать Manticore из исходников и не участвовать в разработке. Для явных сборок следует указать тип сборки, например -DCMAKE_BUILD_TYPE=Debug.

• Multi-config выбирает тип сборки во время сборки. Его следует указывать с помощью опции --config, иначе будет собрана некая конфигурация noconfig, что нежелательно. Поэтому всегда указывайте тип сборки, например --config Debug.

Если вы хотите указать тип сборки, но не хотите заботиться о том, является ли генератор 'single' или 'multi' конфигурацией — просто укажите необходимые ключи в обоих местах. Т.е. конфигурируйте с -DCMAKE_BUILD_TYPE=Debug, а затем собирайте с --config Debug. Главное, чтобы оба значения совпадали. Если целевой билд-системой является single-config, она использует параметр конфигурации. Если multi-config, параметр конфигурации игнорируется, но правильная конфигурация сборки выбирается по ключу --config.

Если вы хотите RelWithDebInfo (т.е. просто сборку для продакшена) и знаете, что находитесь на платформе с single-config (то есть на всех, кроме Windows) — можно опустить флаг --config при вызове cmake. Тогда будет настроен и использован параметр по умолчанию CMAKE_BUILD_TYPE=RelWithDebInfo. Все команды для 'сборки', 'установки' и 'сборки пакета' станут короче.

Cmake — это инструмент, который сам по себе не выполняет сборку, а генерирует правила для локальной системы сборки.

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

можете запустить cmake -G и просмотреть список доступных генераторов.

• На Windows, если у вас установлено несколько версий Visual Studio, возможно, потребуется указать, какую использовать,

например: cmake -G "Visual Studio 16 2019" ....

• On all other platforms - usually Unix Makefiles are used, but you can specify another one, such as Ninja, or Ninja Multi-Config, as:

  Multi-Config`, as: cmake -GNinja ...

  или

  cmake -G"Ninja Multi-Config" ... Ninja Multi-Config весьма полезен, так как действительно является 'multi-config' и доступен на Linux/macOS/BSD. С этим генератором вы можете отложить выбор типа конфигурации до времени сборки, а также собирать несколько конфигураций в одной и той же папке сборки, меняя только параметр --config.

  ### Особенности

1. Если вы хотите в итоге собрать полнофункциональный RPM-пакет, путь к директории сборки должен быть достаточно длинным для корректной сборки отладочных символов.

   Например, `/manticore012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789`. Это связано с тем, что инструменты RPM модифицируют путь к скомпилированным бинарникам при сборке отладочной информации, и они могут просто перезаписать существующее место, не выделяя дополнительное. Указанный длинный путь содержит 100 символов, чего достаточно для такого случая.

   Внешние зависимости

Некоторые библиотеки должны быть доступны, если вы хотите их использовать.

• Для индексирования (инструмент indexer): expat, iconv, mysql, odbc, postgresql. Без них можно обрабатывать только источники tsv и csv.

• Для обслуживания запросов (демон searchd): может потребоваться openssl.

• Для всех (обязательно!) нужна библиотека Boost. Минимальная версия — 1.61.0, однако мы собираем бинарники с более свежей версией 1.75.0. Ещё более новые версии (например, 1.76) тоже должны подойти. На Windows можно скачать предсобранный Boost с их сайта (boost.org) и установить в путь по умолчанию (т.е. C:\\boost...). На MacOs версия из brew подходит. На Linux можно проверить доступную версию в официальных репозиториях, и если она не соответствует требованиям, собрать из исходников. Нам нужен компонент 'context', можно также собрать компоненты 'system' и 'program_options', они понадобятся, если вы хотите собрать библиотеку Galera из исходников. Посмотрите в dist/build_dockers/xxx/boost_175/Dockerfile для краткого самодокументированного скрипта/инструкции, как это сделать.

На системе сборки должны быть установлены 'dev' или 'devel' версии этих пакетов (например, libmysqlclient-devel, unixodbc-devel и т.д. Названия конкретных пакетов смотрите в наших докерфайлах). На системах запуска эти пакеты должны присутствовать хотя бы в финальных (не dev) вариантах. (devel варианты обычно больше, так как включают не только целевые бинарники, но и различные средства разработки, такие как заголовочные файлы и т.п.).

Помимо необходимых предварительных условий, вам могут понадобиться предсобранные клиентские библиотеки expat, iconv, mysql и postgresql. Их нужно либо собрать самостоятельно, либо связаться с нами, чтобы получить наш сборочный пакет (простой zip-архив, где находится папка с этими целями).

• ODBC не обязателен, так как это системная библиотека.

• OpenSSL можно собрать из исходников или скачать предсобранный с https://slproweb.com/products/Win32OpenSSL.html (как указано во внутреннем скрипте cmake FindOpenSSL).

• Boost можно скачать предсобранный с https://www.boost.org/ releases.

Запустите indexer -h. Он покажет, какие функции были настроены и собраны (явные или обнаруженные — неважно): Built on Linux x86_64 by GNU 8.3.1 compiler. Configured with these definitions: -DDISTR_BUILD=rhel8 -DUSE_SYSLOG=1 -DWITH_GALERA=1 -DWITH_RE2=1 -DWITH_RE2_FORCE_STATIC=1

-DWITH_STEMMER=1 -DWITH_STEMMER_FORCE_STATIC=1 -DWITH_ICU=1 -DWITH_ICU_FORCE_STATIC=1 -DWITH_SSL=1 -DWITH_ZLIB=1 -DWITH_ODBC=1 -DDL_ODBC=1

-DODBC_LIB=libodbc.so.2 -DWITH_EXPAT=1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DWITH_ICONV=1 -DWITH_MYSQL=1 -DDL_MYSQL=1

-DMYSQL_LIB=libmariadb.so.3 -DWITH_POSTGRESQL=1 -DDL_POSTGRESQL=1 -DPOSTGRESQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/lib/manticore/data
-DFULL_SHARE_DIR=/usr/share/manticore
-DWITH_STEMMER=1 -DWITH_STEMMER_FORCE_STATIC=1 -DWITH_ICU=1 -DWITH_ICU_FORCE_STATIC=1 -DWITH_SSL=1 -DWITH_ZLIB=1 -DWITH_ODBC=1 -DDL_ODBC=1
-DODBC_LIB=libodbc.so.2 -DWITH_EXPAT=1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DWITH_ICONV=1 -DWITH_MYSQL=1 -DDL_MYSQL=1
-DMYSQL_LIB=libmariadb.so.3 -DWITH_POSTGRESQL=1 -DDL_POSTGRESQL=1 -DPOSTGRESQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/lib/manticore/data
-DFULL_SHARE_DIR=/usr/share/manticore

Manticore Buddy — это сайдкар для Manticore Search, написанный на PHP, который помогает с различными задачами. Типичный рабочий процесс таков: перед тем как вернуть ошибку пользователю, Manticore Search спрашивает Buddy, может ли он обработать проблему для демона. PHP-код Buddy облегчает реализацию высокоуровневых функций, которые не требуют чрезвычайно высокой производительности.

Для более глубокого понимания Buddy ознакомьтесь с этими статьями:

• Introducing Buddy: the PHP sidecar for Manticore Search
• Manticore Buddy: challenges and solutions
• Manticore Buddy: pluggable design
• Manticore Buddy GitHub repository

Если вы следуете инструкциям по установке выше или на сайте, вам не нужно беспокоиться об установке или запуске Manticore Buddy: он устанавливается автоматически при установке пакета manticore-extra, а Manticore Search запускает его автоматически при старте.

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

Manticore Search 2.x сохраняет совместимость с Sphinxsearch 2.x и может загружать существующие таблицы, созданные Sphinxsearch. В большинстве случаев обновление сводится к замене бинарных файлов.

Вместо sphinx.conf (в Linux обычно находится в /etc/sphinxsearch/sphinx.conf) Manticore по умолчанию использует /etc/manticoresearch/manticore.conf. Он также работает под другим пользователем и использует другие папки.

Имя службы systemd изменилось с sphinx/sphinxsearch на manticore, и служба работает под пользователем manticore (Sphinx использовал sphinx или sphinxsearch). Также используется другая папка для файла PID.

Папки, используемые по умолчанию: /var/lib/manticore, /var/log/manticore, /var/run/manticore. Вы всё ещё можете использовать существующую конфигурацию Sphinx, но вам нужно вручную изменить права доступа к папкам /var/lib/sphinxsearch и /var/log/sphinxsearch. Или просто глобально переименовать 'sphinx' в 'manticore' в системных файлах. Если вы используете другие папки (для данных, файлов wordforms и т.д.), владение ими также должно быть переключено на пользователя manticore. Местоположение pid_file следует изменить, чтобы оно соответствовало manticore.service на /run/manticore/searchd.pid.

Если вы хотите использовать папку Manticore, файлы таблиц нужно переместить в новую папку данных (/var/lib/manticore), и права доступа должны быть изменены на пользователя manticore.

Обновление с Sphinx / Manticore 2.x до 3.x не является простым, так как движок хранения таблиц претерпел значительное обновление, и новый searchd не может загружать старые таблицы и обновлять их в новый формат на лету.

Manticore Search 3 получил переработанное хранение таблиц. Таблицы, созданные с Manticore/Sphinx 2.x, не могут быть загружены Manticore Search 3 без конвертации. Из-за ограничения в 4 ГБ, таблица реального времени в 2.x могла иметь несколько дисковых чанков после операции оптимизации. После обновления до 3.x эти таблицы теперь можно оптимизировать до одного дискового чанка с помощью обычной команды OPTIMIZE. Файлы индексов также изменились. Единственный компонент, который не претерпел структурных изменений — это файл .spp (hitlists). .sps (строки/json) и .spm (MVA) теперь содержатся в .spb (атрибуты переменной длины). Новый формат содержит файл .spm, но он используется для карты строк (ранее он был предназначен для MVA атрибутов). Добавлены новые расширения: .spt (поиск docid), .sphi (гистограммы вторичных индексов), .spds (хранение документов). Если вы используете скрипты, которые манипулируют файлами таблиц, их следует адаптировать под новые расширения файлов.

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

Есть два специальных требования, которые нужно учесть:

• Таблицы реального времени нужно сбросить с помощью FLUSH RAMCHUNK
• Обычные таблицы с kill-листами требуют добавления новой директивы в конфигурацию таблицы (см. killlist_target)

Manticore Search 3 включает новый инструмент — index_converter — который может конвертировать таблицы Sphinx 2.x / Manticore 2.x в формат 3.x. index_converter поставляется в отдельном пакете, который нужно установить первым. С помощью этого инструмента создайте версии таблиц 3.x. index_converter может записывать новые файлы в существующую папку данных и создавать резервные копии старых файлов, либо записывать новые файлы в выбранную папку.

Если у вас один сервер:

• Установите пакет manticore-converter
• Используйте index_converter для создания новых версий таблиц в другой папке, отличной от существующей папки данных (с помощью опции --output-dir)
• Остановите существующий Manticore/Sphinx, обновитесь до 3.0, переместите новые таблицы в папку данных и запустите Manticore

Чтобы минимизировать время простоя, вы можете скопировать таблицы 2.x, конфигурацию (вам нужно будет отредактировать пути для таблиц, логов и разных портов) и бинарные файлы в отдельное место и запустить это на отдельном порту. Направьте ваше приложение на него. После обновления до 3.0 и запуска нового сервера вы можете вернуть приложение к обычным портам. Если всё работает хорошо, остановите копию 2.x и удалите файлы, чтобы освободить место.

Если у вас есть запасной сервер (например, тестовый или staging сервер), вы можете сначала выполнить обновление таблиц там и даже установить Manticore 3 для проведения нескольких тестов. Если всё в порядке, скопируйте новые файлы таблиц на продуктивный сервер. Если у вас несколько серверов, которые можно вывести из эксплуатации, делайте это по одному и выполняйте обновление на каждом. Для распределённых конфигураций searchd 2.x может работать как мастер с узлами 3.x, так что вы можете сначала обновить узлы данных, а затем мастер-узел.

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

Kill-листы были переработаны в Manticore Search 3. В предыдущих версиях kill-листы применялись к результирующему набору, предоставленному каждой ранее обработанной таблицей во время выполнения запроса.

Таким образом, в 2.x порядок таблиц во время запроса имел значение. Например, если у дельта-таблицы был kill-лист, чтобы применить его к основной таблице, порядок должен был быть основной, дельта (либо в распределённой таблице, либо в операторе FROM).

В Manticore 3 kill-листы применяются к таблице при её загрузке во время запуска searchd или при её ротации. Новая директива killlist_target в конфигурации таблицы указывает целевые таблицы и определяет, какие doc id из исходной таблицы должны использоваться для подавления. Это могут быть id из определённого kill-листа, фактические doc id таблицы или оба варианта.

Документы из kill-листов удаляются из целевых таблиц, они не возвращаются в результатах даже если поиск не включает таблицу, которая предоставила kill-листы. Из-за этого порядок таблиц для поиска больше не имеет значения. Теперь delta, main и main, delta дадут одинаковые результаты.

В предыдущих версиях таблицы ротировались в порядке, указанном в конфигурационном файле. В Manticore 3 порядок ротации таблиц стал гораздо умнее и работает в соответствии с целями killlist. Перед началом ротации таблиц сервер ищет цепочки таблиц по определениям killlist_target. Затем он сначала ротирует таблицы, которые нигде не упоминаются как цели kill-листов. Далее он ротирует таблицы, на которые ссылаются уже ротированные таблицы, и так далее. Например, если мы делаем indexer --all и у нас есть 3 таблицы: main, delta_big (который нацелен на main) и delta_small (с целью на delta_big), сначала ротируется delta_small, затем delta_big и наконец main. Это делается для того, чтобы при ротации зависимой таблицы она получала самый актуальный kill-лист из других таблиц.

• docinfo - теперь всё extern
• inplace_docinfo_gap - больше не нужен
• mva_updates_pool - MVAs больше не имеют выделенного пула для обновлений, так как теперь их можно обновлять напрямую в блобе (см. ниже).

Строковые, JSON и MVA атрибуты можно обновлять в Manticore 3.x с помощью оператора UPDATE.

В версии 2.x строковые атрибуты требовали REPLACE, для JSON можно было обновлять только скалярные свойства (так как они были фиксированной ширины), а MVAs можно было обновлять с помощью пула MVA. Теперь обновления выполняются напрямую в компоненте блоба. Одной из настроек, которую может потребоваться подстроить, является attr_update_reserve, которая позволяет изменять выделенное дополнительное пространство в конце блоба, используемое для избежания частых переразмериваний, если новые значения больше существующих в блобе.

Doc id раньше были беззнаковыми 64-битными целыми числами. Теперь они являются положительными знаковыми 64-битными целыми числами.

Читайте здесь про RT режим

Manticore 3.x распознаёт и парсит специальные суффиксы, что облегчает использование числовых значений со специальным значением. Общая форма — целое число + литерал, например 10k или 100d, но не 40.3s (так как 40.3 не целое), или не 2d 4h (так как это два значения, а не одно). Литералы не чувствительны к регистру, поэтому 10W — то же, что 10w. В настоящее время поддерживаются 2 типа таких суффиксов:

• Суффиксы размера — могут использоваться в параметрах, определяющих размер чего-либо (буфер памяти, файл на диске, лимит ОЗУ и т.п.) в байтах. «Голые» числа в таких местах означают буквально размер в байтах (октетах). Суффиксы размера: k для килобайт (1k=1024), m для мегабайт (1m=1024k), g для гигабайт (1g=1024m) и t для терабайт (1t=1024g).
• Суффиксы времени — могут использоваться в параметрах, задающих временные интервалы, такие как задержки, таймауты и т.п. «Голые» значения для таких параметров обычно имеют документированную шкалу, и вы должны знать, означает ли число, скажем, 100 — «100 секунд» или «100 миллисекунд». Однако вместо догадок можно просто написать значение с суффиксом, и оно будет однозначно определено своим суффиксом. Суффиксы времени: us для микросекунд, ms для миллисекунд, s для секунд, m для минут, h для часов, d для дней и w для недель.

index_converter — это инструмент для конвертации таблиц, созданных в Sphinx/Manticore Search 2.x, в формат таблиц Manticore Search 3.x. Инструмент можно использовать несколькими способами:

$ index_converter --config /home/myuser/manticore.conf --index tablename

$ index_converter --config /home/myuser/manticore.conf --all

$ index_converter  --path /var/lib/manticoresearch/data --all

Новая версия таблицы по умолчанию записывается в ту же папку. Файлы предыдущей версии сохраняются с расширением .old в имени. Исключение — файл .spp (hitlists), который является единственным компонентом таблицы, не изменившимся в новом формате.

Вы можете сохранить новую версию таблицы в другую папку, используя опцию -–output-dir

$ index_converter --config /home/myuser/manticore.conf --all --output-dir /new/path

Особый случай — таблицы, содержащие kill-листы. Поскольку поведение kill-листов изменилось (см. killlist_target), дельта-таблица должна знать, какие таблицы являются целевыми для применения kill-листов. Есть 3 способа получить конвертированную таблицу, готовую для установки целевых таблиц для применения kill-листов:

• Использовать -–killlist-target при конвертации таблицы

  $ index_converter --config /home/myuser/manticore.conf --index deltaindex --killlist-target mainindex:kl

• Добавить killlist_target в конфигурацию перед конвертацией
• Использовать команду ALTER ... KILLIST_TARGET после конвертации

Вот полный список опций index_converter:

• --config <file> (-c <file> для краткости) указывает index_converter использовать данный файл в качестве конфигурации. Обычно он ищет manticore.conf в каталоге установки (например, /usr/local/manticore/etc/manticore.conf, если установлен в /usr/local/sphinx), затем в текущем каталоге, в котором вы вызываете index_converter из оболочки.
• --index указывает, какую таблицу следует конвертировать
• --path - вместо использования конфигурационного файла можно указать путь, содержащий таблицу(ы)
• --strip-path - удаляет путь из имён файлов, на которые ссылается таблица: стоп-слова, исключения и словоформы
• --large-docid - позволяет конвертировать документы с идентификаторами больше 2^63 и выводить предупреждение, иначе при большом идентификаторе программа просто завершится с ошибкой. Эта опция была добавлена, так как в Manticore 3.x идентификаторы документов имеют тип signed bigint, тогда как ранее они были unsigned
• --output-dir <dir> - записывает новые файлы в выбранную папку, а не в то же место, где находятся существующие файлы таблиц. При установке этой опции существующие файлы таблиц останутся нетронутыми на своих местах.
• --all - конвертирует все таблицы из конфигурации
• --killlist-target <targets> задаёт целевые таблицы, к которым будут применяться kill-листы. Эта опция должна использоваться только вместе с опцией --index