Как стать автором
Обновить

Комментарии 17

Я знаю, об этом и написал в последнем предложении топика.
с релизом ElasticSearch v.1 — он упрощается введением процедуры получения «слепков» индексов, но сути это не меняет
12G индекс, а база? И сколько времени занимает полное переиндексирование, если не хранить индекс эластика?
База порядка 3 гб, если я не ошибаюсь. Времени — я не дождался, ибо производилось это все на AWS инстансе, не самом шустром. Сомневаюсь, что быстрее, чем упаковка (порядка 30 мин.)
Пишут, что graylog хранит сами логи в elasticsearch'е, что объясняет такое необычное соотношение размера индекса и размера базы.

Интересно, почему они не взяли lucene/solr.
Минус и никаких объяснений…

То ли у кого-то такая ненависть к stored полям, то ли к lucene. Тот же logstash умеет хранить и в solr, и в elasticsearch.
На самом деле, если иметь 3 ноды, 1 реплику и больше 2 шардов на индекс в elasticsearch (это дефолтные настройки как минимум), то бекап из статьи будет неполным.
Эмпирически проверяли — восстанавливается без потерь, насколько могу судить. И ноды, и мессаджи.
В описанном мной случае ни одна нода не будет иметь полный набор данных, так что бекап одной не сможет восстановить кластер целиком.
А, это да, немного не о тех нодах подумал. Спасибо, сделаю уточнение в статье завтра.
НЛО прилетело и опубликовало эту надпись здесь
Место == деньги. Снапшот был моей изначальной идеей.
НЛО прилетело и опубликовало эту надпись здесь
О простоте решения никто не говорит, снапшот — проще всего. Может у вас не проблема, но отдать 18-20 гб. под хранение бэкапов не самое разумное решение. 2 гб. — уже другой разговор.
НЛО прилетело и опубликовало эту надпись здесь
Согласен, но опять же — речь тут шла о том, что все stays in cloud. Да и о методах DR, для которых писалось сие — не спорят. У каждого свои ресурсы. On-premises HDD — не был вариантом.
а каков размер дампа mongodb?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий