Стратегии горячего резервирования Elasticsearch

Было бы интересно, если бы кто-то мог поделиться своими лучшими стратегиями "горячего резервирования" для ElasticSearch.

Кроме того, не стесняйтесь обмениваться инструментами и библиотеками, связанными с этой проблемой, и можете помочь.

Обновлено: Спасибо @javanna за ваш ответ, он вполне завершен и обеспечивает хорошее направление для дальнейших действий.

Я также провел небольшое исследование и нашел некоторые статьи/дискуссии, которые могут помочь, если кто-то заинтересован.

Стратегии резервного копирования Elasticsearch
Резервное копирование/восстановление индекса Elasticsearch и связанный фрагмент на github: gist
Упрощенный поиск и восстановление (см. комментарий Пола Смита, также он поделился полезной ссылкой на свой инструмент для проверки индексов)

Обновление: Elasticsearch 1.0 имеет "официальное" решение для резервного копирования - Snapshot/Restore API, и это единственный правильный путь к нему сейчас, ElasticSearch будет определять основные осколки и заботиться о согласованности. Резервное копирование будет выполняться постепенно, поэтому вы сможете делать это очень быстро и часто, как вы хотите.

Ответ 1

Реплики - это своего рода резервная копия, и elasticsearch никогда не выделяет один на тот же node, где исходный первичный осколок. Но тогда все еще существует риск потери данных в зависимости от того, сколько черепов, реплик и узлов у вас есть в вашем кластере.

Я бы посмотрел на Gateway модуль, благодаря которому вы можете сохранить индекс и метаданные кластера. Существуют разные типы шлюзов. Например, я бы посмотрел на Shared FS, который позволяет копировать индекс и метаданные в файловую систему, которая совместно используется всеми вашими узлами. Вы также можете вручную запустить моментальный снимок с помощью API снимков шлюза.

Кроме того, вы можете сделать копию каталога данных (на каждом node), как только вы отключите флеш через параметр index.translog.disable_flush index. Таким образом, вы должны удостовериться, что никакая передача lucene не будет выпущена во время копирования. После того, как вы сделали копию, вам нужно снова включить флеш.

UPDATE

Все типы шлюзов, кроме локального, устарели и будут удалены в будущей версии. Elasticsearch 1.0 будет выпущен с лучшим решением для резервного копирования.

Ответ 2

Итак, это противоречит тому, как работает ElasticSearch, но я бы подумал о наличии двух отдельных экземпляров ElasticSearch, которые не знают друг о друге. В вашем коде приложения каждая команда отправляется в оба экземпляра. Если команда не выполняется для 1 экземпляра, повторите эту команду через 1 минуту и продолжайте повторную попытку. Теперь вы можете сохранить один экземпляр в виде горячей резервной копии или использовать его для повышения производительности путем балансировки запросов между двумя экземплярами.

Причина, по которой мне не нравится настраивать реплики в ElasticSearch, - это боль, чтобы настроить, какая из node получает реплику, и если вы хотите перестроить организацию в будущем, вам в основном нужно пройти тонну обручей. ElasticSearch делает тонну перебалансировки за кулисами и пытается сделать все для вас. Что может быть хорошо.. если у вас есть мощные серверы, и все равно, что получится, но может быть болью иначе.