Комментарии 17
Спасибо за интересный пост. Какая версия и какая лицензия у вас используется? Смотрели ли вы в сторону Kibana+Clickhouse или Loki?
Мы используем бесплатный Elasticsearch, нам его хватает с лихвой.
Да мы смотрели Kibana+Clickhouse, нам показалось это не жизнеспособным, поэтому мы отказались от этой идеи.
Loki стоит использовать совместно с k8s. Но у нас нет кубера.
Судя по тому, что автор не совсем понимает, как ES-кластер работает он и изобретает какие-то лютые велосипеды. А по сути все уже придумано до наc:
https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-ccr.html
Пробежался по статье, как я понял она про репликацию. Это хорошо когда у тебя мало данных.
Но что делать если в кластерах очень много данных и кластеров не 3, а 10, 20 или больше? Тратить ещё пару миллионов ради поиска, как мне кажется плохая идея.
Или я что то упустил? Если да, то просвяти пожалуйста.
Не очень понял Ваш пассаж про "много данных", почему Вы считаете, что репликация не будет работать, если данных много?
Данная репликация как раз и предусматривает тот случай, что у автора - два кластера с ненадежным соединением между ними.
Чтобы хранить на клиенте столько же данных как в кластерах, мне не удастся обойтись одним серверов. Мне придётся делать ещё один полноценный кластер.
Согласитесь, помимо необходимых кластеров платить за VDS которая делает только запросы в кластер намного дешевле. Чем иметь несколько железный серверов с хорошим ядром, много RAM и с дисками несколько сот терабайт.
Если я где то ошибся, поправьте меня пожалуйста
В статье упомянуто что Elastic кеширует результаты. В этой конфигурации он не закеширует отсутствующий ответ? Он же не знает что кластер вернулся, может выдать старый пустой ответ. Или в нем есть механизмы это предотвращающие?
Да, эта функция действительно работает только в том случае, если упал только один сервер из всего кластера
Я не очень поняла, откуда это взялось. Раздел в документации называется "Skip unavailable clusters", в описании - "but none of its nodes", которое вроде бы значит "ни одна из нод", а не "одна из нод". И тем более не поняла, почему в другом режиме этот параметр взял и заработал иначе. Можно этот момент поподробнее осветить?
На превью должен быть Цекало, а не Укупник.
Оказывается, в режиме proxy параметр «skip_unavailable» всё же может пропускать целые кластера.
Объясните пожалуйста, почему в режиме proxy работает, а в режиме sniff нет.
skip_unavailable пропускает только в том случае, если сервер ответил "Я не работаю"
В режиме sniff когда один кластер упал, сказать я не работаю некому, поэтому кластер не пропускается.
В режиме прокси когда кластер падает, haproxy переключает на локальный ElasticSearch, который выдет ошибку, аналог "я не работаю", по этому кластер пропускается.
Под фразой "я не работаю" я имею ввиду любой ответ с сервера.
ElasticSearch: отказоустойчивый сервер отказал