Если вы решите перейти с Plain режима на RT режим или в некоторых других случаях, таблицы реального времени и percolate, созданные в Plain режиме, могут быть импортированы в Manticore, работающий в RT режиме, с помощью оператора IMPORT TABLE. Общий синтаксис следующий:

IMPORT TABLE table_name FROM 'path'

mysql -P9306 -h0 -e 'create table t(f text)'
mysql -P9306 -h0 -e "backup table t to /tmp/"
mysql -P9306 -h0 -e "drop table t"
BACKUP_NAME=$(ls /tmp | grep 'backup-' | tail -n 1)
mysql -P9306 -h0 -e "import table t from '/tmp/$BACKUP_NAME/data/t/t'
mysql -P9306 -h0 -e "show tables"

Выполнение этой команды копирует все файлы таблицы указанной таблицы в data_dir. Все внешние файлы таблицы, такие как wordforms, exceptions и stopwords, также копируются в тот же data_dir. IMPORT TABLE имеет следующие ограничения:

• пути к внешним файлам, которые изначально были указаны в файле конфигурации, должны быть абсолютными
• поддерживаются только таблицы реального времени и percolate
• plain таблицы необходимо предварительно (в plain режиме) конвертировать в таблицы реального времени с помощью ATTACH TABLE

Обратите внимание, что команда IMPORT TABLE не поддерживает таблицы, созданные в версиях старше 5.0.0.

/usr/bin/indexer --rotate --config /etc/manticoresearch/manticore.conf --print-rt my_rt_index my_plain_index > /tmp/dump_regular.sql
mysql -P $9306 -h0 -e "truncate table my_rt_index"
mysql -P 9306 -h0 < /tmp/dump_regular.sql
rm /tmp/dump_regular.sql

Вращение таблицы — это процедура, при которой сервер searchd ищет новые версии определённых таблиц в конфигурации. Вращение поддерживается только в режиме Plain.

Есть два случая:

• для plain-таблиц, которые уже загружены
• таблиц, добавленных в конфигурацию, но ещё не загруженных

В первом случае индексатор не может разместить новую версию таблицы онлайн, поскольку работающая копия заблокирована и загружена searchd. В этом случае indexer нужно вызвать с параметром --rotate. Если используется rotate, indexer создаёт новые файлы таблиц с .new. в названии и посылает сигнал HUP searchd, информируя о новой версии. searchd выполнит проверку и заменит старую версию таблицы на новую. В некоторых случаях может потребоваться создать новую версию таблицы, не выполняя вращение сразу. Например, может понадобиться сначала проверить состояние новых версий таблиц. В этом случае indexer может принимать параметр --nohup, который запрещает посылать сигнал HUP серверу.

Новые таблицы могут быть загружены с помощью вращения; однако обычная обработка сигнала HUP заключается в проверке новых таблиц только если конфигурация изменилась после запуска сервера. Если таблица уже была определена в конфигурации, таблицу следует сначала создать запуском indexer без вращения и выполнить оператор RELOAD TABLES вместо этого.

Также существуют два специализированных оператора, которые могут использоваться для вращения таблиц:

RELOAD TABLE tbl [ FROM '/path/to/table_files' [ OPTION switchover=1 ] ];

Команда RELOAD TABLE позволяет выполнять вращение таблицы через SQL.

Эта команда работает в трёх режимах. В первом режиме, без указания пути, сервер Manticore проверяет наличие новых файлов таблиц в директории, указанной в параметре path. Новые файлы таблиц должны называться tbl.new.sp?.

Если вы указываете путь, сервер ищет файлы таблиц в этой директории, перемещает их в директорию таблицы, указанную в path, переименовывает из tbl.sp? в tbl.new.sp? и выполняет вращение.

Третий режим, активируемый опцией OPTION switchover=1, переключает индекс на новый путь. Здесь демон пытается загрузить таблицу напрямую из нового пути без перемещения файлов. Если загрузка успешна, новый индекс заменяет старый.

Также демон записывает уникальный файл-ссылку (tbl.link) в директории, указанной в path, поддерживая постоянное перенаправление.

Если вы возвращаете перенаправленный индекс к пути, указанному в конфигурации, демон обнаружит это и удалит файл ссылки.

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

indextool следует по файлу ссылки, но другие утилиты (indexer, index_converter и др.) не распознают файл ссылки и используют путь, определённый в конфигурационном файле, игнорируя перенаправление. Таким образом, вы можете просмотреть индекс с помощью indextool, и он прочитает с нового местоположения. Однако более сложные операции, такие как слияние, не учтут файл ссылки.

mysql> RELOAD TABLE plain_table;
mysql> RELOAD TABLE plain_table FROM '/home/mighty/new_table_files';
mysql> RELOAD TABLE plain_table FROM '/home/mighty/new/place/for/table/table_files' OPTION switchover=1;

RELOAD TABLES;

Эта команда работает аналогично системному сигналу HUP, вызывая вращение таблиц. Тем не менее, она не точно повторяет обычный сигнал HUP (который может быть вызван командой kill -HUP или indexer --rotate). Эта команда активно ищет таблицы, требующие вращения, и способна перечитать конфигурацию. Например, если вы запускаете Manticore в режиме plain с конфигурационным файлом, указывающим на несуществующую plain-таблицу, то если вы потом попытаетесь сделать indexer --rotate для этой таблицы, сервер не распознает новую таблицу, пока вы не выполните RELOAD TABLES или не перезапустите сервер.

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

mysql> RELOAD TABLES;
Query OK, 0 rows affected (0.01 sec)

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

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

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

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

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

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

Бесшовное вращение требует большего пикового использования памяти во время вращения (потому что обе копии данных .spa/.spb/.spi/.spm — старые и новые — должны находиться в ОЗУ при предварительной загрузке новой копии). Однако среднее использование остаётся тем же.

Пример:

seamless_rotate = 1