# Вращение таблицы

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

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

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

В первом случае индексатор не может разместить новую версию таблицы онлайн, поскольку работающая копия заблокирована и загружена `searchd`. В этом случае `indexer` нужно вызвать с параметром [--rotate](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-command-line-arguments). Если используется rotate, `indexer` создаёт новые файлы таблиц с `.new.` в названии и посылает сигнал *HUP* `searchd`, информируя о новой версии. `searchd` выполнит проверку и заменит старую версию таблицы на новую. В некоторых случаях может потребоваться создать новую версию таблицы, не выполняя вращение сразу. Например, может понадобиться сначала проверить состояние новых версий таблиц. В этом случае `indexer` может принимать параметр `--nohup`, который запрещает посылать сигнал HUP серверу.

Новые таблицы могут быть загружены с помощью вращения; однако обычная обработка сигнала HUP заключается в проверке новых таблиц только если конфигурация изменилась после запуска сервера. Если таблица уже была определена в конфигурации, таблицу следует сначала создать запуском `indexer` без вращения и выполнить оператор [RELOAD TABLES](../../Data_creation_and_modification/Adding_data_from_external_storages/Rotating_a_table.md#RELOAD-TABLES) вместо этого.

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

## RELOAD TABLE

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

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

Эта команда работает в трёх режимах. В первом режиме, без указания пути, сервер Manticore проверяет наличие новых файлов таблиц в директории, указанной в параметре [path](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#path). Новые файлы таблиц должны называться `tbl.new.sp?`.

Если вы указываете путь, сервер ищет файлы таблиц в этой директории, перемещает их в директорию таблицы, указанную в [path](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#path), переименовывает из `tbl.sp?` в `tbl.new.sp?` и выполняет вращение.

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

Также демон записывает уникальный файл-ссылку (`tbl.link`) в директории, указанной в [path](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#path), поддерживая постоянное перенаправление.

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

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

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

```sql
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

```sql
RELOAD TABLES;
```

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

`RELOAD TABLES` следует рассматривать как асинхронный запрос. Оператор возвращает управление после планирования работы по перезагрузке/повороту, в то время как фактическое обнаружение таблиц и поворот завершаются вскоре после этого в цикле демона. Из-за этого обычная таблица, перестроенная с помощью `indexer --rotate`, может все еще быть временно недоступна сразу после возврата `RELOAD TABLES`.

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

```sql
RELOAD TABLES;
ATTACH TABLE plain_table TO TABLE rt_table WITH TRUNCATE;
```

В таких случаях оператор `ATTACH` может завершиться ошибкой `no such table`, если он выполняется до того, как обычная таблица станет видимой. В качестве обходного пути опрашивайте `SHOW TABLES`, пока обычная таблица не появится, и только затем продолжайте с `ATTACH` или другими зависимыми операторами.

В зависимости от значения параметра [seamless_rotate](../../Server_settings/Searchd.md#seamless_rotate), новые запросы могут временно приостанавливаться, и клиенты будут получать временные ошибки.

```sql
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` — старые и новые — должны находиться в ОЗУ при предварительной загрузке новой копии). Однако среднее использование остаётся тем же.

Пример:

```ini
seamless_rotate = 1
```
<!-- proofread -->

