Статус orphan (одиночный) | Tarantool
Документация на русском языке
поддерживается сообществом

Статус orphan (одиночный)

Начиная с версии Tarantool 1.9, процедура подключения реплики к набору реплик изменяется. Во время box.cfg() экземпляр попытается подключиться ко всем мастерам, указанным в box.cfg.replication. Если не было успешно выполнено подключение к количеству мастеров, указанному в replication_connect_quorum, экземпляр переходит в статус orphan (одиночный). Когда экземпляр находится в статусе orphan, он доступен только для чтения.

Чтобы «подключиться» к мастеру, реплика должна «установить соединение» с узлом мастера, а затем «выполнить синхронизацию».

«Установка соединения» означает контакт с мастером по физической сети и получение подтверждения. Если нет подтверждения соединения через box.replication_connect_timeout секунд (обычно 4 секунды), и повторные попытки подключения не сработали, то соединение не установлено.

«Синхронизация» означает получение обновлений от мастера для создания локальной копии базы данных. Синхронизация завершена, когда реплика получила все обновления или хотя бы получила достаточное количество обновлений, чтобы отставание реплики (см. replication.upstream.lag в box.info()) было меньше или равно количеству секунд, указанному в box.cfg.replication_sync_lag. Если значение replication_sync_lag не задано (nil) или указано как «TIMEOUT_INFINITY», то реплика пропускает шаг «синхронизация» и сразу же переходит на «отслеживание».

Чтобы вывести узел из одиночного статуса, нужно синхронизировать его с достаточным (т.е. равным replication_connect_quorum) количеством других узлов. Этого можно добиться, выполнив любое из следующих действий:

  • Уменьшить значение replication_connect_quorum.
  • Убрать из списка box.cfg.replication недоступные и прочие узлы, с которыми нельзя синхронизироваться.
  • Вообще задать "" (пустую строку) в качестве значения box.cfg.replication.

Возможны следующие ситуации.

Ситуация 1: настройка

Здесь впервые происходит вызов box.cfg{}. Реплика подключается, но набора реплик пока нет.

  1. Установка статуса „orphan“ (одиночный).

  2. Попытка установить соединение со всеми узлами из box.cfg.replication или с количеством узлов, указанным в параметре replication_connect_quorum. Допускаются три повторные попытки за 30 секунд, поскольку идет стадия настройки, параметр replication_connect_timeout не учитывается.

  3. Прекращение работы и выдача ошибки в случае отсутствия соединения со всеми узлами в box.cfg.replication или replication_connect_quorum.

  4. Экземпляр может быть выбран в качестве лидера „leader“ в наборе реплик. Критерии выбора лидера включают в себя значение vclock (чем больше, тем лучше), а также доступность только для чтения или для чтения и записи (лучше всего для чтения и записи, кроме случаев, когда других вариантов нет). Лидер является мастером, к которому должны подключиться другие экземпляры. Лидер является мастером, который выполняет функции box.once().

  5. Если данный экземпляр выбран лидером набора реплик, выполняется «самонастройка»:

    1. Установка статуса „running“ (запущен).
    2. Возврат из box.cfg{}.

    В противном случае, данный экземпляр будет репликой, которая подключается к существующему набору реплик, поэтому:

    1. Настройка от лидера. См. примеры в разделе Настройка набора реплик.
    2. Синхронизация со всеми остальными узлами в наборе реплик в фоновом режиме.

Ситуация 2: восстановление

Здесь вызов box.cfg{} происходит не впервые, а повторно для осуществления восстановления.

  1. Проведение восстановления из последнего локального снимка и WAL-файлов.
  2. Установить соединение с количеством узлов не меньшим, чем replication_connect_quorum. Если не получается – установить статус „orphan“. (Попытки синхронизации будут повторяться в фоновом режиме, и когда/если они окажутся успешными, статус „orphan“ сменится на „connected“.)
  3. Если соединение установлено - осуществлять синхронизацию со всеми подключенными узлами до тех пор, пока отличия не будут более replication_sync_lag секунд.

Ситуация 3: обновление конфигурации

Здесь вызов box.cfg{} происходит не впервые, а повторно, поскольку изменились некоторые параметры репликации или что-то в наборе реплик.

  1. Попытка установить соединение со всеми узлами из box.cfg.replication или с количеством узлов, указанным в параметре replication_connect_quorum в течение периода времени, указанного в replication_connect_timeout.
  2. Попытка синхронизации со всеми подключенными узлами в течение периода времени, указанного в replication_sync_timeout.
  3. Если предыдущие шаги не выполнены, статус изменяется на „orphan“ (одиночный). (Попытки синхронизации будут продолжаться в фоновом режиме, и когда/если они будут успешны, статус „orphan“ отключится.)
  4. Если предыдущие шаги выполнены, статус изменяется на „running“ (мастер) или „follow“ (реплика).

Ситуация 4: повторная настройка

Здесь не происходит вызов box.cfg{}. В определенный момент в прошлом реплика успешно установила соединение и в настоящий момент ожидает обновления от мастера. Однако мастер не может передать обновления, что может произойти случайно, или же если реплика работает слишком медленно (большое значение lag), а WAL-файлы (.xlog) с обновлениями были удалены. Такая ситуация не является критической – реплика может сбросить ранее полученные данные, а затем запросить содержание последнего файла снимка (.snap) мастера. Поскольку фактически в таком случае повторно проводится процесс настройки, это называется «повторная настройка». Тем не менее, есть отличие от обычной настройки – идентификатор реплики останется прежним. Если он изменится, то мастер посчитает, что в кластер добавляется новая реплика, и сохранит идентификатор экземпляра реплики, которой уже не существует. Полностью автоматизированный процесс повторной настройки появился в версии Tarantool 1.10.2.

Нашли ответ на свой вопрос?
Обратная связь