Аварийное восстановление | Tarantool
Документация на русском языке
поддерживается сообществом
Администрирование Аварийное восстановление

Аварийное восстановление

Минимальная отказоустойчивая конфигурация Tarantool’а – это репликационный кластер, содержащий мастер и реплику или два мастера.

Основная рекомендация – настраивать все экземпляры Tarantool’а в кластере таким образом, чтобы они регулярно создавали файлы-снимки.

Ниже дано несколько инструкций для типовых аварийных сценариев.

Конфигурация: один мастер и одна реплика.

Проблема: мастер вышел из строя.

План действий:

  1. Убедитесь, что мастер полностью остановлен. Например, подключитесь к мастеру и используйте команду systemctl stop tarantool@<имя_экземпляра>.
  2. Переключите реплику в режим мастера, установив параметру box.cfg.read_only значение false. Теперь вся нагрузка пойдет только на реплику (по сути ставшую мастером).
  3. Настройте на свободной машине замену вышедшему из строя мастеру, установив параметру replication в качестве значения URI реплики (которая в данный момент выполняет роль мастера), чтобы новая реплика начала синхронизироваться с текущим мастером. Значение параметра box.cfg.read_only в новом экземпляре должно быть установлено на true.

Все немногочисленные транзакции в WAL-файле мастера, которые он не успел передать реплике до выхода из строя, будут потеряны. Однако если удастся получить .xlog-файл мастера, их можно будет восстановить. Для этого:

  1. Узнайте позицию вышедшего из строя мастера – эта информация доступна из нового мастера.

    1. Посмотрите UUID экземпляра в xlog-файле вышедшего из строя мастера:

      $ head -5 *.xlog | grep Instance
      Instance: ed607cad-8b6d-48d8-ba0b-dae371b79155
      
    2. Используйте этот UUID на новом мастере для поиска позиции:

      tarantool> box.info.vclock[box.space._cluster.index.uuid:select{'ed607cad-8b6d-48d8-ba0b-dae371b79155'}[1][1]]
      ---
      - 23425
      <...>
      
  2. Запишите транзакции из .xlog-файла вышедшего из строя мастера в новый мастер, начиная с позиции нового мастера:

    1. Локально выполните эту команду на новом мастере, чтобы узнать его ID экземпляра:

      tarantool> box.space._cluster:select{}
      ---
      - - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2']
      ...
      
    2. Запишите транзакции в новый мастер:

      $ tarantoolctl <uri_нового_мастера> <xlog_файл> play --from 23425 --replica 1
      

Конфигурация: два мастера.

Проблема: мастер #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. План действий:

  1. Перевести все узлы в режим read-only и не разрешать функции box.backup.start() удалять старые контрольные точки. Это не даст сборщику мусора в Tarantool удалять файлы, созданные во время предыдущих контрольных точек, до тех пор пока не будет вызвана функция box.backup.stop().
  2. Возьмите последний корректный .snap-файл и, используя команду tarantoolctl cat, выясните, на каком именно lsn произошла потеря данных.
  3. Запустите новый экземпляр (экземпляр #1) и с помощью команды tarantoolctl play скопируйте в него содержимое .snap/.xlog-файлов вплоть до вычисленного lsn.
  4. Настройте новую реплику с помощью восстановленного мастера (экземпляра #1).
Нашли ответ на свой вопрос?
Обратная связь