Кластеризация Prostore

Содержание раздела
  1. Согласованность данных
  2. Подключение к кластеру
  3. Как работает кластер
    1. Обработка запросов при сбое лидера кластера
    2. Автоматическая отмена неуспешных операций записи
    3. Журнал изменений и снимок состояния
  4. Ограничения кластера

Система поддерживает кластеризацию сервиса исполнения запроса — подключение нескольких нод в одну инсталляцию.

Каждая нода кластера работает со своей сервисной БД, и все ноды работают с общим хранилищем данных. Для отказоустойчивости рекомендуется разворачивать кластер из нечетного количества нод больше одной. Подробнее о вариантах развертывания кластера см. в разделе Схемы развертывания.

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

Допустимо объединять в кластер только одинаковые версии Prostore.

Согласованность данных

Кластер поддерживает линеаризуемость чтения и записи данных, гарантируя получение самых свежих данных на любой из нод кластера. При этом гарантии линеризуемости не распространяются на логические схемы данных, и ноды могут кратковременно отставать от лидера в части DDL-изменений.

Подключение к кластеру

Чтобы начать работать с кластером, необходимо подключиться к любой из его нод. Подробнее о способах подключения к ноде см. в разделе Подключение.

Как работает кластер

Кластер использует алгоритм консенсуса Raft. Одна нода автоматически выбирается лидером, а остальные ноды становятся ведомыми. Все ноды могут выполнять любые запросы.

Для полной работоспособности запросов и функций кластер должен иметь кворум активных нод — большинство от общего числа сконфигурированных нод (например, 2 из 3 или 3 из 5). При наличии кворума нод сбой ведомых нод не влияет на работу кластера, а сбой лидера вызывает временную недоступность некоторых операций на время перевыбора лидера.

Обработка запросов при сбое лидера кластера

При сбое лидера кластер временно (до выбора нового лидера) возвращает ошибку на запросы, требующие участия лидера, — DDL-запросы, запросы к версионируемым данным и другие. Остальные запросы продолжают исполняться, включая:

Автоматическая отмена неуспешных операций записи

Кластер с кворумом нод самостоятельно управляет операциями записи при типовых сбоях (перебои в сети, сбой ноды и т.п.), не требуя вмешательства администратора.

Для этого лидер периодически проверяет выполнение операций в кластере и отменяет те, обработка которых не была подтверждена за заданное время. Если отмена операции не удается, попытки повторяются до успешной отмены. При смене лидера новый лидер продолжает работу прошлого: завершает отмену операций, начатую прошлым лидером, и следит за выполнением новых операций.

Автоматическая отмена операций регулируется настройками:

  • WRITE_OPERATION_ACTIVITY_CHECK_PERIOD_MS — интервал проверки операций на ведомых нодах (по умолчанию — 30 секунд);
  • WRITE_OPERATION_ACTIVITY_CHECK_TIMEOUT_MS — время ожидания подтверждения обработки операции (по умолчанию — 5 минут);
  • WRITE_OPERATION_ROLLBACK_RETRY_COUNT — число попыток отмены операции (по умолчанию — 0, без ограничений).

При высокой вероятности сетевого разделения кластера увеличьте значения параметров загрузки данных: KAFKA_JET_RETRY_COUNT и KAFKA_JET_CHECK_TIMEOUT_MS для коннектора Kafka Jet writer, ADP_MPPW_CONNECTOR_RETRY_COUNT и ADP_MPPW_CONNECTOR_CHECK_TIMEOUT_MS для коннектора Kafka-Postgres writer.

Журнал изменений и снимок состояния

Для обеспечения консенсуса в кластере каждая нода ведет журнал, куда записывает все изменения логических схем, версионируемых данных и дельт в окружении. Журнал хранится в сервисной базе данных ноды. Расхождения в журналах нод, если такие есть, устраняются лидером по алгоритму Raft.

Каждая нода периодически сохраняет снимок своего состояния с периодичностью, равной значению параметра конфигурации RAFT_SNAPSHOT_PERIOD_MS. По умолчанию снимки состояния нод сохраняются раз в 10 минут. Изменения, сохраненные в снимке состояния ноды, удаляются из журнала ноды, что уменьшает объем хранимых изменений и ускоряет восстановление состояния ноды при ее перезапуске. Журналы нод очищаются от сохраненных изменений, только если все ноды кластера доступны и активны.

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

Ограничения кластера

  • Кластер не имеет встроенного балансировщика нагрузки между нодами.
  • Время нод кластера должно быть синхронизировано внешними средствами, например с помощью NTP-сервиса.
  • Для полноценной работы кластера в нем должно быть активно и доступно большинство сконфигурированных нод.
  • Если в существующий кластер добавляется новая нода, ее сервисная БД должна быть скопирована внешними средствами с сервисной БД любой активной ноды кластера.
  • При сбое лидера до выбора нового лидера кластер перестает:
  • Если лидер недоступен для остальных нод и при этом доступен для внешней системы, запросы к лидеру могут возвращать устаревшие данные, пока связность сети в кластере не восстановится.