что шардирование в КХ не поддерживает Replication Factor, об остальных вариантах я вкурсе

Ну как. Насоздавай себе distributed шардов - вот и будет тебе replication factor

https://clickhouse.yandex/docs/ru/single/index.html#distributed

https://github.com/yandex/graphouse/blob/master/doc/cluster.md#sharding-and-replication

Задание кластера из документации - как раз 2 шарда и 2 реплики. Попробовать наворотить что то из серии "3 хоста/3 шарда/2 реплики" - это конечно голову поломать, и не факт что надо (скорее всего именно не надо) - но можно. Поэтому и говорю что прошлый век - это как руками токены кассандре распихивать вместо vnodes.

Ну как. Насоздавай себе distributed шардов - вот и будет тебе replication factor

RF работает иначе все ж

RF - равномерное размазывание второй (или в общем случаи n-ой) копии данных по тем же нодам что уже есть

Это детали имплементации

это суть )

а не детали имплементации

нет

это детали имплементации

@deniszh сорри, но я буду с этим утверждением спорить ) От RF ожидается вполне конкретное поведение при падении нескольких нод

В ES например это настраивается очень гибко, и можно делать очень глупые вещи - но там и близко нет "размазывания"

нельзя утверждать о каком либо поведении RF при падении нод

это абстракция

и она про ноды per se может вообще ничего не знать

если вообще (gasp!) нода не есть ровно 1 инстанс

вот 3 хоста, 3 шарда, 2 реплики.

два инстанса на ноду

не уверен насчет КХ но для многих хранилищ вполне рабочая схема

@deniszh в КХ ты в такой схеме это собираешь руками

чем это не Replication Factor = 2?

чем это не Replication Factor = 2?

это как раз оно, но репликация 1 к 1 несколько отличается свойствами

например

именно. Чего и бухчу на него. ?

Всем привет. Кто-нибудь будет на PromCon 2017 ?

Всем привет. Кто-нибудь будет на PromCon 2017 ?

Из Grafana Carl Bergquist будет доклад читать.

вопросы спама — офтопик.

@pipopolam телеграф. :( systemctl reload telegraf -> метрик нет.

это правила подавления такие

https://github.com/influxdata/telegraf/issues/3049

ERROR: S client not available

А его можно релоадить?

нет:)

но мне нужно

понаписали...

Есть вопрос к тем, кто пробовал Riemann. Исходные данные: на хосте развёрнут Riemann, куда льются метрики по протоколу carbon с других хостов. На римане запущен carbon-сервер, который эти потоки принимает. В римане они трансформирует в нужный вид и отдаются в веб-сокет. К веб-сокету подключается rieman-dash - дашборд для римана. Он представляет собой веб-приложение на рубях и JS. Приложение грузится в браузер и подключается через веб-сокет к риману (там для этого есть отдельное поле "хост:порт"). Вопрос такой - можно ли как-то засекурить этот вебсокет? Пока вариантов вижу всего два: 1) VPN 2) Допилить Riemann и riemann-dash, чтобы какая-то аутентификация была и простое шифрование. Если кто Riemann использует - может есть ещё какой-то вариант "из коробки"? Начинать писать на рубях чот большого желания нет.

м.б. завернуть через nginx

а там уже засекурить?

там веб-сокет, в том то и дело. т.е. riemann-dash не поймёт этого.

Через nginx я загрузку самой аппы заверну и парольный доступ дам. Но, вот что с веб-сокетом делать, пока непонятно.

а чего не гонять вебсокеты через nginx с ssl`ем, или нужна именно аутентификация?

хм... кстати да, это ж типа туннель получится.

Ок, понял. Спасибо за идею! Сразу ещё несколько вариантов появилось. :)

Пришла тут рекламка influx ))) https://www.influxdata.com/press-release-influxdata-supports-billion-time-series/?__s=51fbicfcj8csgnzyjpsb

муахаха

в релизе 1,3 потреблние памяти выросло на 50%