Fiware: предотвращение потери данных

Я работаю с контекстным брокером версии 0.27.0. Я использую общий активатор Cygnus и установил агент MQTT, который подключает внешние устройства к брокеру контекста.

Сейчас меня больше всего беспокоит, как предотвратить потерю данных. Я установил брокер контекста и базы данных Cygnus mongodb как наборы реплик, но это не гарантирует, что все данные будут сохранены в базах данных. Я видел, что Cygnus использует поток Apache. Глядя на его конфигурацию, можно настроить повторные попытки повторной инъекции:

# Number of channel re-injection retries before a Flume event is definitely discarded (-1 means infinite retries) 
cygnusagent.sources.http-source.handler.events_ttl = -1

¿Было бы неплохо установить значение повторных попыток равным -1? Я всегда читал о событиях, которые повторно вводятся в канале. ¿Что можно сделать для сохранения всех данных? ¿Есть ли в экосистеме программного обеспечения какие-либо функции, ориентированные на эту цель?


fiware fiware-orion fiware-cygnus
person Julen    schedule 17.02.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Что касается Cygnus, TTL - это, безусловно, способ контролировать повторные попытки сохранения после ошибки. Повторная попытка означает, что данные повторно вводятся во внутренний канал, связывающий источник (который получает уведомления Orion) и приемник (который сохраняет данные в конечном хранилище) для будущих попыток сохранения.

Возможные значения этого TTL:

  • TTL = 0: повторных попыток нет, т.е. если в первый раз уведомленные данные не могут быть сохранены в конечном хранилище (из-за сбоя сети, ошибки хранилища и т. Д.), То данные удаляются.
  • TTL> 0: количество повторных попыток равно заданному значению TTL. После исчерпания TTL данные удаляются.
  • TTL = -1: бесконечные попытки, т.е. данные повторно вводятся в канал навсегда, пока они не сохранятся или канал не заполнится.

Как уже отмечалось, TTL -1 может потреблять емкость канала, если окончательное хранилище никогда не будет в порядке, избегая того, чтобы новые полученные данные помещались в канал. Тем не менее, если с конечным хранилищем все в порядке, такой недостаток не имеет значения, верно? :)

Таким образом, можно сказать, что правила выбора TTL следующие:

  • Если вы не хотите повторных попыток, просто настройте 0.
  • Если вам нужны повторные попытки, но вы не против потери данных после определенного количества повторных попыток, настройте положительное значение.
  • Если вам нужны повторные попытки, но вы не хотите терять данные, настройте -1 и большую емкость канала, так как последнее хранилище может быть недоступно в течение неизвестного времени.

В любом случае функция TTL меняется во время этого спринта. Поведение будет таким же, но вместо того, чтобы применяться к отдельным событиям, оно будет применяться к пакетам событий (конечно, пакеты могут быть примерно одним событием). Вы увидите это изменение в следующем выпуске Cygnus (0.13.0), и оно будет доступно в конце февраля 2016 года (на момент написания этого, на следующей неделе :)). Я рекомендую дождаться такого релиза, если вы хотите интенсивно использовать функцию TTL.

person frb    schedule 19.02.2016
comment
Если я правильно понимаю, я думаю, что этот новый выпуск не решит нашу текущую проблему. Прямо сейчас, если основной узел набора реплик выйдет из строя, потребуется десять секунд, чтобы установить новый узел в качестве основного. Все события, поступающие в этот промежуток времени, получат отклонение из базы данных и будут отброшены, вместо этого повторно введены в канал, верно? - person Julen; 24.02.2016
comment
Не обязательно. Ничего не будет отброшено, если, например, вы настроите TTL равным -1. Или, если вы настроили достаточно большой TTL, чтобы события все еще находились в канале, готовые к повторной попытке сохранения, когда снова будет установлена ​​реплика MongoDB. - person frb; 26.02.2016
comment
Прямо сейчас я настроил TTL на -1 и увеличил пропускную способность канала до 10.000. Даже в этом случае в течение 10 секунд, которые длится арбитраж для нового первичного узла, все выполненные операции теряются. Похоже, они получают ошибку базы данных и больше не вводятся повторно. - person Julen; 29.02.2016
comment
Вдобавок, используя ту же конфигурацию (event_TTL: -1, channel_capacity: 10000), я видел, что если создается несколько сущностей, оставляя промежуток времени между ними меньше одной секунды, многие из них не будут храниться на cygnus. Я тоже пробовал с последней версией cygnus (0.13) и с batch_TTL до -1. Но я все равно теряю данные. Любые идеи? - person Julen; 11.03.2016