Tarantool DataBase 3.1¶

Узлы-обработчики¶

В Tarantool DataBase 3.1.0 представлен новый тип экземпляров, который называется обработчик (worker). Узел-обработчик представляет собой Go-приложение, которое позволяет вынести бизнес-логику работы с данными отдельно от хранения данных в Tarantool DataBase и предоставляет удобный интерфейс для работы с базой данных. Такое приложение подключается к Tarantool DataBase через Go-коннектор и отслеживает изменения конфигурации и смену мастер-узла.

В Tarantool DataBase 3.1.0 попробовать работу с новым типом узлов можно в запускаемом Docker-примере tdb_worker. В примере запущены два узла-обработчика, у которых подключен мониторинг и интеграция с веб-интерфейсом Tarantool Cluster Manager (TCM). Для обработчиков настроен доступ к спейсу для чтения и записи данных. Чтобы продемонстрировать, как обработчики отслеживают изменения в конфигурации, в примере вручную добавлен новый экземпляр роутера.

Tarantool DataBase поддерживает отображение обработчиков в веб-интерфейсе TCM. В TCM обработчики отображаются на вкладке Stateboard в отдельной группе узлов workers.

Подробная информация об обработчиках и запускаемый Docker-пример работы с ними приведены в разделе Использование узлов-обработчиков.

type: nontarantool
instrumentation:
    url:            worker-1:9080
    metrics_url:    /metrics
    metrics_format: "prometheus"
    liveness_url:   /alive
    info_url: /info
    binary: ./bin/http-server
config:
    addr: localhost:10000
    tarantool_cluster_prefix: /tdb/config/all
    tarantool_user: admin
    tarantool_pass: secret-cluster-cookie

Безопасный режим работы кластера при балансировке сегментов¶

После изменения конфигурации шардированного кластера, например, при добавлении нового набора реплик или изменении веса шардов, начинается балансировка сегментов. При балансировке выполняется миграция сегментов – перенос сегментов с более нагруженных шардов на менее нагруженные.

Начиная с версии Tarantool DataBase 3.1.0 при старте балансировки кластер автоматически включает безопасный режим, чтобы обеспечить согласованность и целостность данных. Производительность кластера в этом режиме снижается (примерно на 15% для операций REPLACE). Безопасный режим включается независимо на каждом хранилище, участвующем в балансировке сегментов. Запросы к спейсам на движке vinyl всегда выполняются в безопасном режиме независимо от текущего статуса безопасного режима.

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

• вызвать метод crud.rebalance_safe_mode_status();

• проверить значение метрики tnt_crud_storage_safe_mode_enabled.

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

1. Дождитесь полного завершения миграции сегментов.

2. Очистите кэш карты маршрутов на каждом роутере:

   crud.rebalance.router_cache_clear()
   

   Проверить время последней очистки кэша можно с помощью метрики tnt_crud_router_cache_clear_ts.

3. Отключите безопасный режим вручную на каждом хранилище – как на мастер-узлах, так и на репликах:

   crud.rebalance_safe_mode_disable()
   

Кроме того, существуют следующие особенности, касающиеся балансировки сегментов:

• Поскольку во время миграции сегмента невозможно выполнять операции с кортежами в этом сегменте, CRUD-операции при балансировке могут завершаться с ошибками. Для исправления ошибок требуется повторно выполнить соответствующие запросы;

• Когда *_many-запрос выполняется над данными из нескольких шардов, на роутере эти данные автоматически разбиваются на пачки по шардам и параллельно отправляются на соответствующие узлы хранилища. Во время балансировки запрос может завершиться с ошибкой на некоторых хранилищах. В этом случае операция будет выполнена частично, а пользователю вернется ошибка с указанием хранилища, где не удалось выполнить запрос. Пользователю нужно быть готовым к тому, что операция может быть выполнена не полностью, и при необходимости повторить соответствующие запросы или выполнить другие необходимые действия;

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

Проверка работоспособности кластера¶

Начиная с версии Tarantool DataBase 3.1.0 работоспособность (здоровье) узлов кластера и репликации можно контролировать с помощью встроенного модуля healthcheck. Подробная информация о модуле и запускаемый Docker-пример работы с ним приведены в разделе Проверка работоспособности кластера.

Модуль позволяет:

• получать текущее состояние здоровья экземпляра;

• устанавливать оповещения (alerts) в кластере при проблемах с работоспособностью узла;

• настраивать запуск дополнительных проверок;

• задавать свой формат ответа;

• создавать пользовательские проверки здоровья в коде миграции или роли, например, чтобы отслеживать размер спейса.

Встроенные проверки модуля отслеживают:

• текущее состояние экземпляра (значение box.info.status);

• наличие директории для снимков данных snapshot.dir;

• наличие директории журнала упреждающей записи wal.dir;

• наличие upstream-узла, с которого принимаются данные репликации;

• репликационный статус текущего экземпляра (значение box.info.replication[{n}].upstream.status).

Для проверки здоровья узлов используется отдельная технологическая роль roles.healthcheck. Роль задается на экземплярах кластера и позволяет настроить HTTP-адрес обработчика запросов для отправки GET-запросов. Чтобы задать HTTP-сервер для запросов, используется модуль roles.httpd.

Настроить модуль можно в YAML-конфигурации кластера, указав роли roles.healthcheck и roles.httpd в секции roles, а также настройки этих ролей в roles_cfg:

roles_cfg:
  roles.healthcheck:
    http:
      - endpoints:
        - path: /healthcheck
    set_alerts: true
    checks:
      include: [all]
      exclude: ['replication.upstream_absent', 'replication.state_bad']   
groups:
  routers:
    roles: [roles.httpd, roles.healthcheck]
    replicasets:
      router-msk:
        leader: router-msk
        instances:
          router-msk:
            roles_cfg:
              roles.httpd:
                default:
                  listen: tarantool-router-msk:8181
                  #...

Здесь:

• roles.healthcheck.http.endpoints.path – адрес обработчика запросов на работоспособность;

• healthcheck.http.set_alerts – включить оповещения в кластере при проблемах со здоровьем узла;

• healthcheck.http.checks.include и exclude – список запускаемых и отключенных проверок соответственно. В примере запускаются все проверки, кроме проверок репликации;

• roles.httpd.default.listen – адрес и порт, на которых запущен HTTP-сервер.

Полный список опций конфигурации для роли roles.healthcheck можно найти в Справочнике по конфигурации.

Поддержка координатором отказоустойчивости синхронной репликации в топологии 2.5 ЦОДа¶

Начиная с версии Tarantool DataBase 3.1.0 в режиме восстановления после сбоев supervised добавлена поддержка синхронной репликации в спейсах для топологии с хранилищами данных в двух центрах обработки данных (ЦОД).

До версии Tarantool DataBase 3.1.0 координатор отказоустойчивости поддерживал синхронную репликацию для топологий только с тремя и более ЦОД. Если в наборе реплик было N экземпляров, минимальный размер кворума мог составлять N/2 + 1. Топологии с двумя ЦОД не поддерживались, поскольку размер кворума было невозможно динамически уменьшить при потере связи с одним из ЦОД. В минимальном наборе реплик из двух узлов размер кворума по умолчанию равен 2 (рассчитывается как 2/2 + 1 = 2). Если один из узлов вышел из строя, новые транзакции не могут пройти коммит из-за невозможности получить подтверждение от второго экземпляра. Новые транзакции при этом будут утеряны.

Начиная с версии Tarantool DataBase 3.1.0 поддерживается синхронная репликация для топологий с хранилищами данных, расположенными в двух ЦОД. При потере связи со вторым ЦОД координатор отказоустойчивости автоматически уменьшает размер кворума и восстанавливает работоспособность кластера в пределах доступного ЦОД. Когда связь со вторым ЦОД восстановлена, координатор отказоустойчивости автоматически возвращает нормальный размер кворума. Транзакции при этом не теряются.

При этом существуют следующие ограничения: хотя хранилища данных могут быть развернуты всего в двух ЦОД, требуется еще один так называемый кворумный ЦОД для дополнительного хранилища конфигурации на основе etcd или Tarantool. Таким образом, эффективная топология, также известная как топология 2,5 ЦОДа, подразумевает в общей сложности три ЦОД: два центра обработки данных с полным набором компонентов (хранилища данных, роутеры, хранилища конфигурации) и ЦОД с хранилищем конфигурации.

Ниже приведены сценарии, в которых топология с хранилищами данных, развернутыми в двух ЦОД, может выйти из строя. При других сценариях кластер продолжит работать.

Сценарий 1: прерывание обогащения данных после сбоя ЦОД

1. ЦОД #1 выходит из строя, ЦОД #2 при этом работает. Координатор отказоустойчивости уменьшает размер кворума до 1. Кластер продолжает обслуживать клиентов.

2. ЦОД #1 запускается и начинает получать недостающие данные с ЦОД #2. Размер кворума по-прежнему равен 1.

3. Процесс обогащения данных для ЦОД #1 все еще продолжается, но ЦОД #2 отключается. В этом случае кластер становится недоступен.

Сценарий 2: нет множественного уменьшения кворума

1. Отключается ЦОД #1 (2 узла), ЦОД #2 (2 узла) при этом работает.

2. Один из двух экземпляров в ЦОД #2 отключается. В этом случае кластер также становится недоступным.

Сценарий 3: оба ЦОД отключаются – крайний случай, когда кластер становится недоступен.

Идентификатор ULID¶

Начиная с Tarantool DataBase 3.1.0 добавлена поддержка модуля ulid – встроенного модуля платформы Tarantool. Идентификатор ULID – 128-битный универсальный уникальный лексикографически сортируемый идентификатор, который состоит из 48-битной временной метки в миллисекундах от эпохи Unix и 80-битной случайной части.

Идентификаторы ULID:

• лексикографически сортируются по времени создания;

• полностью помещаются в 26 ASCII-символов;

• избегают визуально неоднозначных символов, таких как I, L, O или U;

• имеют 128 бит общей уникальности – как UUID v4.

Строки ULID кодируются с использованием алфавита Crockford Base32. В бинарном виде ULID представлен 16-байтным значением в порядке байт big-endian. Это гарантирует, что лексикографический порядок бинарных ULID совпадает с их хронологическим порядком, как и требует спецификация ULID.

Tarantool использует монотонный генератор ULID. Если в пределах одной миллисекунды созданы несколько ULID, их значения строго возрастают с учетом порядка их создания.

Объекты ULID поддерживают полный набор операторов сравнения Lua: равенство и неравенство (== и ~=), а также лексикографическое сравнение (<, <=, > и >=). Сравнение работает как между объектами ULID, так и между объектом ULID и строкой ULID. Перед сравнением объекта ULID со строкой строка преобразуется в ULID.

ulid = require('ulid')
tarantool> u1 = ulid.new()
tarantool> u2 = ulid.new()
tarantool> u1 < u2, u1 <= u2, u1 == u2, u1 ~= u2, u1 > u2, u1 >= u2
---
- true
- true
- false
- true
- false
- false

Подробная информация о модуле ulid, справочник методов и примеры использования приведены в документации платформы Tarantool.

Обновление примера шифрования трафика¶

В Tarantool DataBase 3.1.0 улучшен запускаемый пример traffic_encryption, демонстрирующий шифрование трафика. Теперь в примере поддерживается TLS-шифрование для следующий соединений:

• между узлами кластера Tarantool DataBase;

• между клиентами и узлами Tarantool DataBase;

• между веб-интерфейсом TCM и узлами Tarantool DataBase;

• между TCM и etcd (backend store);

• между узлами Tarantool DataBase и etcd (централизованным хранилищем конфигурации кластера);

• между пользователем и веб-интерфейсом TCM (HTTPS);

• между узлами Tarantool DataBase и системой Prometheus для экспорта метрик по протоколу HTTPS.

В примере также был добавлен мониторинг с экспортом метрик по SSL и информация о настройке поддерживаемых наборов шифров для соединений Tarantool DataBase и TCM.

Улучшение документации¶

В Tarantool DataBase 3.1.0 добавлены следующие разделы документации:

• Обновление схемы данных – общая информация и рекомендации по обновлению схемы данных, запускаемый пример обновления схемы данных с помощью утилиты tt CLI;

• Понижение версии схемы данных – рекомендации по понижению версии схемы данных;

• Шардирование – общая информация о механизме шардирования в Tarantool DataBase, архитектура и настройка конфигурации;

• Поиск кортежей в TCM – поиск кортежей по спейсу на вкладке Tuples и через SELECT-запрос с помощью модуля CRUD;

• Работа со словарями через пользователя с ограниченными правами – запускаемый Docker-пример, демонстрирующий запись, чтение, экспорт и импорт данных словарей через пользователя словарей.