Кластеризация Prostore
Содержание раздела
Система поддерживает кластеризацию сервиса исполнения запроса — подключение нескольких нод в одну инсталляцию.
Каждая нода кластера работает со своей сервисной БД, и все ноды работают с общим хранилищем данных. Для отказоустойчивости рекомендуется разворачивать кластер из нечетного количества нод больше одной. Подробнее о вариантах развертывания кластера см. в разделе Схемы развертывания.
Развернутый кластер должен быть сконфигурирован по инструкции, доступной в разделе Конфигурация кластера.
Допустимо объединять в кластер только одинаковые версии Prostore.
Согласованность данных
Кластер поддерживает линеаризуемость чтения и записи данных, гарантируя получение самых свежих данных на любой из нод кластера. При этом гарантии линеризуемости не распространяются на логические схемы данных, и ноды могут кратковременно отставать от лидера в части DDL-изменений.
Подключение к кластеру
Чтобы начать работать с кластером, необходимо подключиться к любой из его нод. Подробнее о способах подключения к ноде см. в разделе Подключение.
Как работает кластер
Кластер работает с использованием алгоритма консенсуса Raft. Одна нода автоматически выбирается лидером, а остальные ноды становятся ведомыми. Все ноды кластера могут выполнять любые запросы.
Кластер исполняет полученные запросы, пока в нем остается кворум активных нод. Достаточным кворумом считается большинство сконфигурированных нод кластера, например 3 ноды из 5 или 2 ноды из 3. Пока в кластере остается кворум нод, сбой ведомой ноды не прерывает работу кластера, а сбой лидера приводит к временной недоступности части операций только на время перевыбора лидера.
Обработка запросов при сбое лидера кластера
Если текущий лидер недоступен, а новый еще не выбран или не может быть выбран из-за отсутствия кворума, все ноды кластера перестают исполнять запросы, требующие участия лидера, и возвращают ошибку в ответе. Обработка остальных запросов продолжается. Примеры запросов, которые продолжают исполняться даже при недоступности лидера:
- запросы на запись и чтение неверсионируемых данных,
- запросы по управлению индексами и числовыми последовательностями.
Журнал изменений и снимок состояния
Для обеспечения консенсуса в кластере каждая нода ведет журнал, куда записывает все изменения логических схем, версионируемых данных и дельт в окружении. Журнал хранится в сервисной базе данных ноды. Расхождения в журналах нод, если такие есть, устраняются лидером по алгоритму Raft.
Каждая нода периодически сохраняет снимок своего состояния с периодичностью, равной значению параметра конфигурации RAFT_SNAPSHOT_PERIOD_MS. По умолчанию снимки состояния нод сохраняются раз в 10 минут. Изменения, сохраненные в снимке состояния ноды, удаляются из журнала ноды, что уменьшает объем хранимых изменений и ускоряет восстановление состояния ноды при ее перезапуске. Журналы нод очищаются от сохраненных изменений, только если все ноды кластера доступны и активны.
Ноды управляют своими снимками состояний самостоятельно, не синхронизуя их с другими нодами. При включении новой ноды в существующий кластер необходимо развернуть ее сервисную БД из копии, снятой с сервисной БД любой активной ноды.
Ограничения кластера
- Кластер не имеет встроенного балансировщика нагрузки между нодами.
- Время нод кластера должно быть синхронизировано внешними средствами, например с помощью NTP-сервиса.
- Для полноценной работы кластера в нем должно быть активно и доступно большинство сконфигурированных нод.
- Если в существующий кластер добавляется новая нода, ее сервисная БД должна быть скопирована внешними средствами с сервисной БД любой активной ноды кластера.
- Если текущий лидер недоступен, а новый еще не выбран, кластер перестает:
- исполнять запросы, требующие участия лидера,
- синхронизировать материализованные представления,
- обрабатывать retention-правила,
- рассчитывать ROWS_COUNT в статистике.
- Если лидер недоступен для остальных нод и при этом доступен для внешней системы, запросы к лидеру могут возвращать устаревшие данные, пока связность сети в кластере не восстановится.