Автоматическое восстановление после сбоев в режиме supervised¶
В Tarantool DB поддерживается механизм автоматического восстановления после сбоев (supervised failover], который позволяет контролировать назначение лидера в наборе реплик с помощью внешнего координатора отказоустойчивости. Лидер – экземпляр в наборе реплик, доступный для записи данных. Остальные узлы в наборе реплик принимают только запросы на чтение. Если в какой-то момент экземпляр лидера станет недоступен, вместо него будет выбран и назначен новый лидер из набора реплик.
Запускаемый пример с координатором отказоустойчивости можно найти в разделе Использование координаторов отказоустойчивости.
Подробная информация об отказоустойчивой архитектуре и поддерживаемых режимах работы приведена в документации Tarantool.
Внешний координатор отказоустойчивости¶
Внешние координаторы отказоустойчивости – это отдельные экземпляры Tarantool DB. Поскольку на таких экземплярах не исполняется клиентский код, работу координаторов ничего не тормозит. Координатор читает конфигурацию кластера из файла или из централизованного хранилища конфигурации на основе etcd или Tarantool, опрашивает экземпляры об их состоянии, а затем назначает лидера для каждого набора реплик в зависимости от доступности и здоровья узлов. Для повышения отказоустойчивости вы можете запустить два узла-координатора или более. В этом случае кластер хранилища конфигурации обеспечивает синхронизацию между такими узлами. Если координаторов несколько, для управления лидерством в наборе реплик используется только один из них – такой координатор называется активным. Активным координатором считается узел, захвативший блокировку во внешнем поставщике состояния.
Примечание
Рекомендуемое количество узлов-координаторов на один кластер – 2–3 экземпляра (по числу центров обработки данных).
Использование координатора для кластера выглядит так:
Настройте кластер для работы с внешним координатором. Для этого задайте в опции replication.failover значение
supervisedдля всех наборов реплик, которые нужно отслеживать через внешний координатор.Запустите настроенный кластер. Когда внешний координатор еще не запущен, экземпляры в наборах реплик запускаются в следующих режимах:
если набор реплик уже настроен (bootstrapped), все экземпляры запускаются в режиме только для чтения;
если набор реплик не настроен (bootstrapped), один экземпляр запускается в режиме, доступном для записи.
Запустите координатор отказоустойчивости. Для повышения отказоустойчивости вы можете запустить два узла-координатора или более. В этом случае один координатор будет активным, а остальные – пассивными.
Когда кластер и координаторы запущены, координатор назначает один экземпляр в качестве лидера, если в наборе реплик еще его нет.
Если лидер станет недоступен, координатор выполнит автоматическое переключение лидера на резервный экземпляр. Если станет недоступен активный координатор, вместо него активным станет новый координатор.
Внешний поставщик состояния¶
Tarantool DB использует внешний поставщик состояния (stateboard) для отслеживания состояния координаторов. Поддерживается два типа поставщика состояния:
удаленное хранилище на основе etcd;
хранилище конфигурации на основе Tarantool.
В режиме supervised тип поставщика состояния выбирается автоматически на основе предоставленной
конфигурации.
Указанные поставщики состояния используют те же настройки подключения, что и централизованное хранилище конфигурации
на основе etcd или Tarantool.
Если конфигурация кластера хранится в etcd или хранилище на основе Tarantool по ключу <prefix>/config/*,
то координатор хранит свое состояние по ключу <prefix>/failover/*.
Вот несколько примеров ключей, используемых для различных целей:
<prefix>/failover/info/by-uuid/<uuid>: состояния координатора по заданному UUID;<prefix>/failover/active/lock: уникальный идентификатор (UUID) активного узла-координатора;<prefix>/failover/active/term: тип fencing-токена. Позволяет задать порядок, в котором координаторы становятся активными (захватывают блокировку) с течением времени;<prefix>/failover/command/<id>: ключ, использующийся для выполнения ручного восстановления после сбоев (режимmanual).
Назначение нового лидера¶
После назначения лидера узел-координатор опрашивает все экземпляры в наборе реплик об их состоянии, отправляя запросы каждые probe_interval секунд. Экземпляр, доступный для записи, берёт лидерство только на время. При этом координатор отслеживает крайний срок для режима чтения и записи, который обновляется каждые renew_interval секунд. Это время известно всем другим узлам, и ни один другой экземпляр не может стать лидером, пока не истечёт это время с запасом на разницу во времени на узлах. Если все попытки обновить крайний срок в течение указанного интервала времени (lease_interval) терпят неудачу, лидер переходит в режим только для чтения. Затем координатор назначает лидером новый экземпляр.