Аварийное восстановление
Минимальная отказоустойчивая конфигурация Tarantool – это репликационный кластер, содержащий мастер и реплику или два мастера.
Основная рекомендация – настраивать все экземпляры Tarantool в кластере таким образом, чтобы они регулярно создавали файлы-снимки.
Ниже дано несколько инструкций для типовых аварийных сценариев.
Конфигурация: один мастер и одна реплика.
Проблема: мастер вышел из строя.
План действий:
- Убедитесь, что мастер полностью остановлен. Например, подключитесь к мастеру и используйте команду
systemctl stop tarantool@<имя_экземпляра>
. - Переключите реплику в режим мастера, установив параметру box.cfg.read_only значение false. Теперь вся нагрузка пойдет только на реплику (по сути ставшую мастером).
- Настройте на свободной машине замену вышедшему из строя мастеру, установив параметру replication в качестве значения URI реплики (которая в данный момент выполняет роль мастера), чтобы новая реплика начала синхронизироваться с текущим мастером. Значение параметра box.cfg.read_only в новом экземпляре должно быть установлено на true.
Все немногочисленные транзакции в WAL-файле мастера, которые он не успел передать реплике до выхода из строя, будут потеряны. Однако если удастся получить .xlog-файл мастера, их можно будет восстановить. Для этого:
Узнайте позицию вышедшего из строя мастера – эта информация доступна из нового мастера.
Посмотрите UUID экземпляра в xlog-файле вышедшего из строя мастера:
$ head -5 *.xlog | grep Instance Instance: ed607cad-8b6d-48d8-ba0b-dae371b79155
Используйте этот UUID на новом мастере для поиска позиции:
tarantool> box.info.vclock[box.space._cluster.index.uuid:select{'ed607cad-8b6d-48d8-ba0b-dae371b79155'}[1][1]] --- - 23425 <...>
Запишите транзакции из .xlog-файла вышедшего из строя мастера в новый мастер, начиная с позиции нового мастера:
Локально выполните эту команду на новом мастере, чтобы узнать его ID экземпляра:
tarantool> box.space._cluster:select{} --- - - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2'] ...
Запишите транзакции в новый мастер:
$ tt play <new_master_uri> <xlog_file> --from 23425 --replica 1
Конфигурация: два мастера.
Проблема: мастер #1 вышел из строя.
План действий:
- Пусть вся нагрузка идет только на мастер #2 (действующий мастер).
2. Follow the same steps as in the master-replica recovery scenario to create a new master and salvage lost data.
Конфигурация: мастер-мастер или мастер-реплика.
Проблема: данные были удалены на одном мастере, а затем эти изменения реплицировались на другом узле (мастере или реплике).
Эта инструкция применима только для данных, хранящихся на движке memtx. План действий:
- Перевести все узлы в режим read-only и не разрешать функции box.backup.start() удалять старые контрольные точки. Это не даст сборщику мусора в Tarantool удалять файлы, созданные во время предыдущих контрольных точек, до тех пор пока не будет вызвана функция box.backup.stop().
- Get the latest valid .snap file and
use
tt cat
command to calculate at which lsn the data loss occurred. - Start a new instance (instance#1) and use
tt play
command to play to it the contents of .snap/.xlog files up to the calculated lsn. - Настройте новую реплику с помощью восстановленного мастера (экземпляра #1).