Настройка архивации устаревших данных

Для архивации данных используются модуль cooler и отдельная технологическая роль roles.cooler. Роль roles.cooler задается на экземплярах хранилища кластера и отвечает за запуск и остановку архивации, обработку смены мастер-узла в наборе реплик, а также конфигурацию модуля expirationd.

Перед запуском архивации данных для спейса memtx необходимо задать настройки для создания архивного спейса в vinyl и определить условие, по которому будет запускаться архивация.

Метод cooler.setup() настраивает процесс архивации для заданного спейса memtx. В примере ниже спейс memtx имеет имя sessions. Метод регистрирует условие архивации и создаёт архивный спейс в vinyl с указанными параметрами:

 
cooler.setup('sessions', {    -- Параметры vinyl    vinyl_params = {        bloom_fpr = 0.05,        run_count_per_level = 8,        run_size_ratio = 3.5,    }})

По умолчанию имена функции и архивного спейса формируются автоматически на основе имени исходного спейса memtx следующим образом:

• имя функции-предиката — <space_name>_is_cooled, в данном случае sessions_is_cooled. Может быть задано явно через параметр is_cooled_fun_name.
• имя архивного спейса vinyl — <space_name>_cold, то есть sessions_cold. Может быть задано явно через параметр vinyl_space_name.

Функцию с условием архивации можно задать с помощью метода cooler.set_func(). В примере ниже также создана функция sessions_updated_at_start_key, которая возвращает порог времени для архивации. Условие t.updated_at < ... означает, что нужно архивировать все сессии, обновлённые более 30 минут назад.

 
box.schema.func.create('sessions_updated_at_start_key', {    body = "function() return require('clock').time() - 60 * 30 end",    if_not_exists = true,})cooler.set_func('sessions', "t.updated_at < box.func.sessions_updated_at_start_key:call()")

Чтобы запустить перенос данных, в YAML-конфигурации кластера в файле конфигурации (в файле config.yml или в веб-интерфейсе TCM на вкладке Configuration) добавьте в секцию экземпляров хранилищ (storages) роль roles.cooler и настройки этой роли в roles_cfg:

 
storages:  #...  roles:    - roles.crud-storage    - roles.cooler  roles_cfg:    roles.cooler:      sessions:        expirationd:          primary:  # Явное указание сканирования по первичному индексу            full_scan_time: 300            tuples_per_iteration: 100

Здесь:

• sessions — название спейса memtx, для которого настраивается архивация;
  • primary — название первичного индекса, по которому идет сканирование спейса;
    • full_scan_time — время обхода спейса в секундах;
    • tuples_per_iteration — количество кортежей, которое проверяется за одну итерацию.

Конфигурация выше запускает задачу архивации — фоновую задачу модуля expirationd, которая периодически сканирует спейс sessions по первичному индексу и перемещает старые записи в архивный спейс по заданному условию. Полный список опций конфигурации для роли roles.cooler можно найти в Справочнике по конфигурации.

Задача архивации обходит спейс по первичному или вторичному индексу. На каждый индекс спейса может быть задана только одна задача архивации. При этом можно задать несколько задач на спейс, указав несколько разных индексов. Поведение архивации зависит от индекса, указанного в секции конфигурации roles.cooler.<name>.expirationd.<index_name>:

• если индекс (index_name) не указан, запускается одна задача по первичному индексу с параметрами по умолчанию;
• если указан только вторичный индекс, задача запускается только по нему, задача по первичному индексу не запускается;
• если требуется запуск по первичному индексу вместе с другими или настройка параметров индекса, его необходимо указать явно.

Рекомендации:

• обход по первичному индексу проще в настройке и подходит, когда большая часть данных соответствует условию архивации. Недостаток такого подхода в том, что при каждой итерации выполняется полный проход по всему спейсу;
• обход по вторичному индексу позволяет сразу переходить к кортежам, которые потенциально готовы к охлаждению, избегая полного сканирования "горячих" данных. Рекомендуется, когда условие архивации основано на поле, по которому построен вторичный индекс (например, updated_at).

Эти параметры управляют интенсивностью фонового сканирования спейса:

• full_scan_time — ожидаемое время полного прохода по спейсу в секундах. От этого значения зависят паузы между итерациями: чем больше целевое время, тем реже файбер проверяет кортежи. Значение по умолчанию: 3600 (1 час);
• tuples_per_iteration — количество кортежей, обрабатываемых за одну итерацию. Значение по умолчанию: 1024.

Рекомендации:

• значения по умолчанию подходят для большинства сценариев;
• если архивация не успевает за фактическим ростом спейса, увеличьте tuples_per_iteration — файбер будет обрабатывать больше кортежей за одну итерацию. Следите за нагрузкой на CPU;
• если архивация не должна создавать заметную нагрузку в рабочие часы, увеличьте full_scan_time — проход растянется на более длительный период, паузы между итерациями станут реже.

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

• явным значением — например, start_key: 100500. В примере обход начнется с кортежа, у которого значение индекса больше или равно 100500;
• названием Lua-функции — функция будет вызвана на каждом запуске задачи и вернёт актуальное значение ключа. Это удобно, когда порог архивации динамический (например, текущее время минус N дней).

Пример функции из start_key:

 
box.schema.func.create('sessions_updated_at_start_key', {    body = "function() return require('clock').time() - 60 * 30 end",    if_not_exists = true,})

Параметр iterator_type определяет направление обхода индекса:

• ALL (по умолчанию) — все кортежи без ограничения по start_key. Для TREE-индексов тип итератора ALL совпадает с GE;
• EQ — только кортежи, равные start_key;
• GE — кортежи, начиная с start_key и больше;
• GT — кортежи строго больше start_key;
• LT — кортежи строго меньше start_key;
• LE — кортежи не больше start_key;

Полное описание итераторов приведено в документации платформы Tarantool: index_object:pairs().

Пример конфигурации для обхода по двум индексам одновременно:

 
roles_cfg:  roles.cooler:    sessions:      expirationd:        primary:          full_scan_time: 300          tuples_per_iteration: 100        by_updated_at:          full_scan_time: 1000          tuples_per_iteration: 200          start_key: 'sessions_updated_at_start_key'          iterator_type: 'LT'

В этом примере запускаются две задачи архивации для спейса sessions:

• primary — полный проход по первичному индексу;.
• by_updated_at — обход устаревших сессий по вторичному индексу.

Чтобы отключить фоновый перенос данных, удалите из конфигурации кластера настройки технологической роли roles.cooler, указанные в секции roles_cfg, а затем сохраните и примените изменения:

 
storages:  replication:    failover: election  sharding:    roles: [storage]  roles:    - roles.crud-storage    - roles.cooler  roles_cfg:  # пусто

Проверить, остановлена ли архивация, можно в веб-интерфейсе TCM на вкладке Cluster > Cluster metrics: метрика cooler_on должна быть равна 0 на экземплярах хранилищ.