Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или загрязняться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые были ранее удалены с помощью операторов DELETE.

Начиная с Manticore 4, этот процесс происходит автоматически по умолчанию. Однако вы также можете использовать следующие команды для ручного запуска компактирования таблицы.

OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]]

OPTIMIZE TABLE rt;

OPTIMIZE TABLE rt OPTION cutoff=4;

OPTIMIZE TABLE rt OPTION sync=1;

Оптимизация может быть длительным и интенсивным по вводу-выводу процессом. Чтобы минимизировать влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор OPTIMIZE просто добавляет задачу в его очередь. Фоновый поток оптимизации может быть ограничен по вводу-выводу, и вы можете контролировать максимальное количество операций ввода-вывода в секунду и максимальный размер ввода-вывода с помощью директив rt_merge_iops и rt_merge_maxiosize соответственно.

Во время оптимизации RT-таблица остаётся онлайн и доступна для поиска и обновлений почти всё время. Она блокируется на очень короткий период, когда успешно объединяется пара дисковых чанков, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы.

Пока auto_optimize не отключён, таблицы оптимизируются автоматически.

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

1. Отключить auto_optimize.
2. Вручную оптимизировать таблицы:

   На одном из узлов удалите таблицу из кластера:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   ALTER CLUSTER mycluster DROP myindex;

   Оптимизируйте таблицу:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   OPTIMIZE TABLE myindex;

   Добавьте таблицу обратно в кластер:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   ALTER CLUSTER mycluster ADD myindex;

   Когда таблица будет добавлена обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера. Любые локальные изменения, сделанные в таблице на других узлах, будут потеряны.

Изменения данных таблицы (вставки, замены, удаления, обновления) должны либо:

1. Быть отложены, либо
2. Направляться на узел, где выполняется процесс оптимизации.

Обратите внимание, что пока таблица отсутствует в кластере, команды insert/replace/delete/update должны обращаться к ней без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся с ошибкой. После того как таблица будет добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова использовать префикс имени кластера, иначе они будут завершаться с ошибкой.

Операции поиска доступны как обычно на любом из узлов в процессе.

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

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

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

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

«Заморозка» таблицы полезна, когда вы хотите сделать физическую копию или резервную копию. Она помечает файлы таблицы как замороженные и показывает, где они хранятся. После заморозки вы можете безопасно скопировать эти файлы в другое место. Вы всё ещё можете добавлять новые документы в замороженную таблицу до тех пор, пока она не достигнет rt_mem_limit, но новые данные остаются в памяти и не записываются на диск, пока таблица не будет разморожена. Если таблица превысит rt_mem_limit, все изменения приостанавливаются до разморозки. Если демон остановится неожиданно, любые несохранённые данные восстанавливаются из binlog.

«Блокировка» таблицы полезна для логических резервных копий. Она не останавливает внутренние задачи обслуживания, такие как операции слияния дисковых чанков или запись RAM-чанка на диск. Она блокирует только операции записи. Это значит, что вы не можете вставлять, заменять или обновлять данные в заблокированной таблице. Это полезно для таких инструментов, как mysqldump, потому что блокировка гарантирует логическую согласованность данных. Например, без блокировки, если вы замените документ во время дампа, старая версия может уже попасть в дамп, а новая версия появится позже, обе с одним и тем же ID документа. Блокировка таблицы предотвращает такую ситуацию.

FREEZE tbl1[, tbl2, ...]

FREEZE t;

+-------------------+---------------------------------+
| file              | normalized                      |
+-------------------+---------------------------------+
| data/t/t.0.spa    | /work/anytest/data/t/t.0.spa    |
| data/t/t.0.spd    | /work/anytest/data/t/t.0.spd    |
| data/t/t.0.spds   | /work/anytest/data/t/t.0.spds   |
| data/t/t.0.spe    | /work/anytest/data/t/t.0.spe    |
| data/t/t.0.sph    | /work/anytest/data/t/t.0.sph    |
| data/t/t.0.sphi   | /work/anytest/data/t/t.0.sphi   |
| data/t/t.0.spi    | /work/anytest/data/t/t.0.spi    |
| data/t/t.0.spm    | /work/anytest/data/t/t.0.spm    |
| data/t/t.0.spp    | /work/anytest/data/t/t.0.spp    |
| data/t/t.0.spt    | /work/anytest/data/t/t.0.spt    |
| data/t/t.meta     | /work/anytest/data/t/t.meta     |
| data/t/t.ram      | /work/anytest/data/t/t.ram      |
| data/t/t.settings | /work/anytest/data/t/t.settings |
+-------------------+---------------------------------+
13 rows in set (0.01 sec)

Столбец file указывает пути к файлам таблицы внутри data_dir запущенного экземпляра. Столбец normalized отображает абсолютные пути к тем же файлам. Чтобы сделать резервную копию таблицы, просто скопируйте указанные файлы без дополнительной подготовки.

Когда таблица заморожена, выполнение запросов UPDATE невозможно; они будут ждать, пока таблица не будет разморожена.

Также запросы DELETE и REPLACE имеют некоторые ограничения во время заморозки таблицы:

• Если DELETE затрагивает документ в текущем RAM-чанке — это разрешено.
• Если DELETE влияет на документ в дисковом чанке, но он был ранее удалён — это разрешено.
• Если DELETE изменит фактический дисковый чанк — запрос будет ждать, пока таблица не будет разморожена.

Ручной FLUSH RAM-чанка замороженной таблицы сообщит об «успехе», но реального сохранения не произойдет.

DROP/TRUNCATE замороженной таблицы разрешены, так как эти операции не являются неявными. Предполагается, что если вы удаляете или очищаете таблицу, вам не нужна её резервная копия; значит, её изначально не следовало замораживать.

INSERT в замороженную таблицу поддерживается, но с ограничениями: новые данные будут храниться в RAM (как обычно) до достижения rt_mem_limit; затем новые вставки будут ждать, пока таблица не будет разморожена.

Если вы завершите работу демона с замороженной таблицей, это будет эквивалентно некорректному завершению работы (например, kill -9): недавно вставленные данные не будут сохранены в RAM-чанке на диске, и при перезапуске они будут восстановлены из бинарного лога (если он есть) или потеряны (если бинарное логирование отключено).

UNFREEZE tbl1[, tbl2, ...]

UNFREEZE tbl;

SHOW TABLE `foo` STATUS LIKE 'locked';

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| locked        | 2     |
+---------------+-------+
1 row in set (0,00 sec)

lock tables tbl1 read[, tbl2 read, ...]

--------------
LOCK TABLES tbl READ
--------------
Query OK, 0 rows affected (0.000 sec)
--------------
LOCK TABLES tbl READ, tbl2 WRITE
--------------
Query OK, 0 rows affected, 1 warning (0.000 sec)
--------------
SHOW WARNINGS
--------------
+---------+------+--------------------------------+
| Level   | Code | Message                        |
+---------+------+--------------------------------+
| warning | 1000 | Write lock is not implemented. |
+---------+------+--------------------------------+
1 row in set (0.000 sec)

UNLOCK TABLES;

SHOW LOCKS;

+-----------+------+-----------+-----------------+
| Type      | Name | Lock Type | Additional Info |
+-----------+------+-----------+-----------------+
| rt        | a    | read      | Count: 1        |
| percolate | bar  | freeze    | Count: 3        |
| rt        | foo  | freeze    | Count: 2        |
+-----------+------+-----------+-----------------+
3 rows in set (0,01 sec)

FLUSH ATTRIBUTES

Команда FLUSH ATTRIBUTES сбрасывает все обновления атрибутов, находящиеся в памяти, во всех активных дисковых таблицах на диск. Она возвращает тег, который идентифицирует результат состояния на диске (что по сути является числом фактически выполненных сохранений атрибутов на диск с момента запуска сервера).

mysql> UPDATE testindex SET channel_id=1107025 WHERE id=1;
Query OK, 1 row affected (0.04 sec)
mysql> FLUSH ATTRIBUTES;
+------+
| tag  |
+------+
|    1 |
+------+
1 row in set (0.19 sec)