Рейтинг@Mail.ru

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

Замечание

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

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

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

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

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

Master-replica

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

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

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

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

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

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

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

      $ 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-lsn 23425 --replica 1
      

Master-master

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

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

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

  1. Пусть вся нагрузка идет только на мастер #2 (действующий мастер).

2. Follow the same steps as in the master-replica recovery scenario to create a new master and salvage lost data.

Потеря данных

Конфигурация: master-master или master-replica.

Проблема: данные были удалены на одном мастере, а затем эти изменения реплицировались на другом узле (мастере или реплике).

Эта инструкция применима только для данных, хранящихся на движке memtx. План действий:

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