Если вы решите перейти с 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. Выделяется новое RAM-хранилище для таблицы.
2. Асинхронно загружаются в RAM новые данные атрибутов и словаря таблицы.
3. В случае успеха, старая таблица освобождается, и файлы обеих таблиц переименовываются.
4. В случае неудачи, новая таблица освобождается.
5. В любой момент запросы обслуживаются либо из старой, либо из новой копии таблицы.

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

Пример:

seamless_rotate = 1