Автоматическое восстановление после отказа¶
Механизм автоматического восстановления после отказа (failover) позволяет контролировать назначение лидера в наборе реплик. Лидер – экземпляр в наборе реплик, доступный для записи данных. Остальные узлы в наборе реплик принимают только запросы на чтение. Если в какой-то момент экземпляр лидера станет недоступен, вместо него будет выбран и назначен новый лидер из набора реплик.
Подробная информация об отказоустойчивой архитектуре и поддерживаемых режимах работы приведена в документации Tarantool.
См. также: Настройка автоматического восстановления после отказа в веб-интерфейсе Cartridge.
Режим stateful¶
В Tarantool DB для работы автоматического восстановления после отказа в режиме
stateful используется
технологическая роль failover-coordinator.
Экземпляры в кластере, которым назначена такая роль, называются координаторами.
В режиме stateful один из экземпляров с ролью failover-coordinator управляет процессом переключения на резервные реплики в случае сбоя
узла-лидера.
Если в кластере несколько экземпляров с такой ролью, активным считается узел, захвативший блокировку во внешнем поставщике состояния.
Important
Рекомендуемое количество узлов с ролью failover-coordinator на один кластер – 2–3 экземпляра (по числу центров обработки данных).
Когда основной узел становится недоступным, координатор начинает процесс переключения на
резервные реплики.
Для определения доступных резервных реплик координатор использует карту лидеров – информацию о том,
какие узлы являются лидерами.
В режиме stateful карта лидеров хранится во внешнем поставщике состояния.
Поддерживается два типа поставщика состояния:
Tarantool Stateboard(изолированный экземпляр Tarantool);кластер etcd. Узнать больше: Настройка восстановления после отказа в режиме stateful с etcd. Поддерживается только API etcd версии 2.x. Использовать etcd 3.x можно только с опцией
ETCD_ENABLE_V2=true.Note
etcd версии 3.6.0 и выше не поддерживает опцию
ETCD_ENABLE_V2. Для корректной работы в режимеstatefulс etcd используйте версии etcd ниже 3.6.0.
Процесс переключения на новый экземпляр лидера выглядит так:
определение доступных реплик, которые можно использовать в качестве резервных;
выбор реплики, которая будет использоваться в качестве нового лидер-узла – обычно это реплика с наиболее актуальными данными;
перенаправление всех запросов к выбранной реплике;
обновление метаданных системы для отображения новой конфигурации.