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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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-сервиса.
  • Для полноценной работы кластера в нем должно быть активно и доступно большинство сконфигурированных нод.
  • Если в существующий кластер добавляется новая нода, ее сервисная БД должна быть скопирована внешними средствами с сервисной БД любой активной ноды кластера.
  • Если текущий лидер недоступен, а новый еще не выбран, кластер перестает:
  • Если лидер недоступен для остальных нод и при этом доступен для внешней системы, запросы к лидеру могут возвращать устаревшие данные, пока связность сети в кластере не восстановится.