В логах zookeeper нашел варнинг: 2018-10-19 18:27:55,723 - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@368] - caught end of stream exception EndOfStreamException: Unable to read additional data from client sessionid 0xa667edeb7ca000e, likely client has closed socket at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:241) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203) at java.base/java.lang.Thread.run(Thread.java:844) 2018-10-19 18:27:55,724 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1044] - Closed socket connection for client /10.75.0.84:18840 which had sessionid 0xa667edeb7ca000e 10.75.0.84 - это адрес нового ch сервера

Еслм у вас 4 реплики, вы на всех 4х серверах должны таблицу создавать, почему вы пишите - создаю на старых или на новых.

Эксперементальным путем дошли до того что репликация данных с новых серверов не работает. Таблицы на новых серверах создавались для того чтобы проверить будет ли работать репликация

Таблицы со старых серверов реплицируются на новые. Но если создать новую таблицу на новом сервере - она на старый не синкается. Ошибка про read 0 bytes

Ну вот я например когда переносил данные со старого кластера на новый, просто добавил новые сервера в текущий кластер, создал там таблицы, данные со старых серверов отреплицировались, а потом просто удалил старые сервера из конфигов, таких ошибок не встречал

Мы все так же и планируем, но - при insert в таблицу на старых серверах данные реплицируются на новые; при insert на новых - данные не реплицируются: остаются на хосте, на котором была произведена вставка.

Вероятно нет доступа с новых северов на старые

Проверьте фаервол и прочее

[root@ch10 ~]# curl ch1.local:9000 Port 9000 is for clickhouse-client program. You must use port 8123 for HTTP. [root@ch10 ~]# curl ch1.local:9009 Ok. [root@ch10 ~]# curl ch1.local:8123 Ok. ch10 - новый ch1 - старый

Обратно тоже порядок

А какой порт для реплик

Не 9000?

tcp_port: 9000

упс, сорян парни

чатом промазал

Всем привет Есть два старых и два новых clickhouse сервера: везде версии одинаковые. Создаем таблицу на старом сервере - она реплицируется на новый. Создаем на новом - не реплицируется с ошибкой: DB::Exception: Cannot read all data. Bytes read: 0. Bytes expected: 8 Репликация новый -> новый так же не запускается с такой же ошибкой. Вопрос - что означает эта ошибка и куда нужно копать? - версии идентичные вплоть до ревизии - iptables и тд точно верные - конфиги правильные - из отличий: добавил опцию listen_reuse_port 1 на новых репликах, так как не стартовал

Он не стартовал так как кто-то уже слушал этот порт, сечас его слушают 2-а приложения, одно из которых вообще не факт что КХ.

tcp_port: 9000

Дима, может что-то симтемное заняло 9000 порт?

Дима, может что-то симтемное заняло 9000 порт?

У КХ по дефолту 3-и порта: * 8123 HTTP интерфейс * 9000 Native интерфейс * 9009 репликация

Дима, может что-то симтемное заняло 9000 порт?

Проверил - clickhouse слушает эти порты

подскажите, когда делю запрос вида WITH '2018-10-16' as temp_date temp_date можно пробросить в подзапросы?

Нашлось ли решение?

А подскажите пожалуйста чтобы например поправить документацию достаточно ли выкачать репозиторий, сделать свою ветку и фоормить пул-реквест? Или нужно обязательно заводить issue какое то чтобы посмотрели и смержили?

Можно пул реквест конечно

А подскажите пожалуйста чтобы например поправить документацию достаточно ли выкачать репозиторий, сделать свою ветку и фоормить пул-реквест? Или нужно обязательно заводить issue какое то чтобы посмотрели и смержили?

PR достаточно, можно прямо из веб интерфейса GitHub

привет. вставляю в distributed-таблицу (3 шарда, на двух вес = 10, на одном = 0): на локальную все записывается, на другой шард – нет, данные лежат в distributed-таблице. в логах: DB::Exception: Logical error: empty block received as table structure юзер default без пароля (т.е. в конфиге шардов указаны только хост и порт). Куда смотреть?

Привет. Для балансировки запросов(insert, select) до серверов ch(2 шарда, 2 реплики), какой прокси балансировщик использовать? Я обычно haproxy(проверенный временем) использую. Есть еще chproxy, который якобы специально для ch созданный. Но как-то двоякое впечатление он оставляет(нет полноценного логирования, для запуска как сервиса, вручную собрать надо)

у нас - просто nginx, пока хватает.

+ к nginx

+ haproxy

Кстати, а что нужно логировать, чтоб было полноценно?

Лучше chproxy. Он ещё проверяет кол-во запросов на каждом сервере. И запускает запрос на менее загруженном кластере / сервере. Плюс проверяет доступность каждого из серверов. Собирать не нужно. Можно скачать бинарник

Если у вас реплики ещё. То можно настроить что наиболее тяжёлые запросы будут выполняться на определенной группе серверов

Что удобно

Кто быстрее отвечает тот и менее загружен по логике же

Не факт

Количество запросов тоже не факт

Можно не париться, любая прокся, желательно с хелсчеком, будет работать одинаково плюс минус незначительные отклонения

Это да. Но в chproxy ещё можно настроить кеширование. Если поверх клика бежит много одинаковых запросов

То в этом кейсе ответ моментальный с кеша

"много" - это сколько?

От настроек зависит

У меня, кстати, в основном запись... Много однотипных запросов.

Для записи любая прокся подойдёт с хелсчеком

Это да. Предпочёл бы что-то более умное и склеивающее запросы в один, но работающего так, как надо - не нашел. Обхожусь Buffer.

Через fluentd заверните :) складывает в буффер, потом пачку засылает

Но buffer по сути тоже самое

у нас всё ж не логи

Будут ли участвовать в формировании ответов на запросы недавно добавленные и ещё не синхронизированные реплики?

Или лучше поставить load_balancing in_order?

Кажись да

Будут ли участвовать в формировании ответов на запросы недавно добавленные и ещё не синхронизированные реплики?

Да, но можно покрутить настройки чтоб КХ чекал отставание.

replicated_can_become_leader - оно, получается, если в секции merge_tree в config.xml, будет serve-wide, т.е на все таблицы распространяться? И сервер-реплика никогда не будет претендовать на то, чтобы быть лидером?

Подскажите, пожалуйста. Есть две таблицы с идентичной структурой: А (replicated) и Б (non-replicated). Как быстрее/правильнее скопировать все данные из Б в А: insert into A select * from Б, или отключить все партииции у Б, скопировать их в А/detached и приаттачить к А? (К таблице Б запросов не происходит, поэтому дэтачить партиции можно)

По логике копированием партиций вроде должно быть быстрее, но вдруг у insert select есть какие-то специальные оптимизации?

Да, перемещением кусков будет быстрее, вот в документации ваш кейс описан: https://clickhouse.yandex/docs/ru/operations/table_engines/replication/#mergetree-replicatedmergetree

replicated_can_become_leader - оно, получается, если в секции merge_tree в config.xml, будет serve-wide, т.е на все таблицы распространяться? И сервер-реплика никогда не будет претендовать на то, чтобы быть лидером?

Всё так

Можно ли как-то из CH запросом получить сервера zookeeper, c которыми работает CH?

посмотри в конфиге просто

Этот вариант не подходит) Планирую свап серверов зукипера, думаю ввести новые сервера ЗК, сообщить их КХ через конфиг, вывести старые, и как-то отследить, с какими серверами ЗК будут работать сервера КХ. С новыми или старыми.

Когда-то Татьяна помню что-то такое отвечала человеку на вопрос о свапе зукипера, но уже минут 40 пытаюсь по чату найти

Этот вариант не подходит) Планирую свап серверов зукипера, думаю ввести новые сервера ЗК, сообщить их КХ через конфиг, вывести старые, и как-то отследить, с какими серверами ЗК будут работать сервера КХ. С новыми или старыми.

эм это же один и тот же кластер зк

посмотрите просто тисипидампом куда ходит

в принципе надо прописать новые и перезапустить кх

в принципе надо прописать новые и перезапустить кх

Хм, а если в zookeeper.xml доменные имена? Может будет достаточно просто поменять ip зукиперов в dns и в КХ сделать SYSTEM DROP DNS CACHE ?

а как у вас кластер будет зк работать ?

Не понял сути вопроса. ЗК сервера же отличаются только виртуально ролями, лидер и фолловеры, данные везде одинаковые. И если подсунуть вместо одних серверов зк другие из того же кластера разницы для КХ вроде как и быть не должно

А есть ли планы сделать официальные билды под ARM64? Надоело собирать руками каждый раз ;) да и компиляция - не самая сильная сторона arm машинок, по 2 часа на сборку

Не понял сути вопроса. ЗК сервера же отличаются только виртуально ролями, лидер и фолловеры, данные везде одинаковые. И если подсунуть вместо одних серверов зк другие из того же кластера разницы для КХ вроде как и быть не должно

ну у вас так сойдут с ума сервера зк

А есть ли планы сделать официальные билды под ARM64? Надоело собирать руками каждый раз ;) да и компиляция - не самая сильная сторона arm машинок, по 2 часа на сборку

собирайте автоматом

Worksonarm дает машины для подобного без проблем, у них Cavium Thunder X (не X 2)

Да, перемещением кусков будет быстрее, вот в документации ваш кейс описан: https://clickhouse.yandex/docs/ru/operations/table_engines/replication/#mergetree-replicatedmergetree

Спасибо

Не понял сути вопроса. ЗК сервера же отличаются только виртуально ролями, лидер и фолловеры, данные везде одинаковые. И если подсунуть вместо одних серверов зк другие из того же кластера разницы для КХ вроде как и быть не должно

В самом зукипере видно в stat подключен туда кх или нет. Это проще всего.

Кстати, а что нужно логировать, чтоб было полноценно?

использование прокси, фактически убирает ip клиента и запрос на ch для acl приходит уже от ip прокси. Поэтому уже в проксе надо настраивать acl на доступность пользователям + tls авторизация. Соответственно по логам прокси уже видимость, кто приходил, зачем, что ответили или банальный handshake не проходит, а не то что сервер ch недоступен. В haproxy это все есть, в chproxy сообщения в stdout отправляет, т. е. их в системном message надо отлавливать, с кучей другой информацией системы

я использую как http доступ, так и в качестве альтернативы драйвер ClickHouse-Native-JDBC, а там уже tcp на 9000 порт. Соответсвенно nginx уже слабо подходит. Chproxy на конфигурацию tcp для биндинга еще не "ковырял"

я использую как http доступ, так и в качестве альтернативы драйвер ClickHouse-Native-JDBC, а там уже tcp на 9000 порт. Соответсвенно nginx уже слабо подходит. Chproxy на конфигурацию tcp для биндинга еще не "ковырял"

А в чем проблема с нгинкс он давно умеет и хттп и тисипи

Посмотрите в документации нгинкс stream

Я вообще отошёл от всяких хапрокси и прочего в нгинкс как только там появился stream

Есть вопрос. В КХ пишу все логи с веб-серверов. На основе matview хотелось бы высчитывать сразу часть статистики. Как правильнее организовать, к примеру, подсчет ответов с разбивкой по кодам ответов и HTTP-методам? Для каждого кода ответа отводить отдельную колонку или иметь одну колонку "http code" и для каждого кода высчитывать число запросов в новой строке? Хотелось бы понять как лучше именно для КХ?

Есть вопрос. В КХ пишу все логи с веб-серверов. На основе matview хотелось бы высчитывать сразу часть статистики. Как правильнее организовать, к примеру, подсчет ответов с разбивкой по кодам ответов и HTTP-методам? Для каждого кода ответа отводить отдельную колонку или иметь одну колонку "http code" и для каждого кода высчитывать число запросов в новой строке? Хотелось бы понять как лучше именно для КХ?

т.е. все возможные httpcode заранее известны и добавляться новые не будут? Иначе придется запросы менять или строить их как-то. Ну и меньше строк лучше, тут просто если в MV будет group by server, method, date то будет и так достаточно мало строк, вряд-ли у вас миллионы серверов, поэтому я бы не морочился и сделал group by server, method, code, date

сейчас преддполагаем что коды заранее известны, остальные в опр. колонку. Интересней как правильней именно в логике КХ.

меньше строк лучше.

Есть вопрос по select_sequential_consistency и insert_quorum. Вот была у нас таблица, в которую писались данные до включения этих двух опций. Включили. Не пропадут ли из SELECT-ов данные, записанные, когда не были активированы эти опции консистентности?

использование прокси, фактически убирает ip клиента и запрос на ch для acl приходит уже от ip прокси. Поэтому уже в проксе надо настраивать acl на доступность пользователям + tls авторизация. Соответственно по логам прокси уже видимость, кто приходил, зачем, что ответили или банальный handshake не проходит, а не то что сервер ch недоступен. В haproxy это все есть, в chproxy сообщения в stdout отправляет, т. е. их в системном message надо отлавливать, с кучей другой информацией системы

Не убирает ip клиента - Prepends User-Agent request header with remote/local address and in/out usernames before proxying it to ClickHouse, so this info may be queried from system.query_log.http_user_agent. tls - Supports automatic HTTPS certificate issuing and renewal via Let’s Encrypt. По доступности - вы можете настроить доступ для разных пользователей и лимитировать доступ по IP/IP-mask.

"много" - это сколько?

кеширование отлично подходит для графаны, когда несколько пользователей смотрят одни и те же дашборды

Есть вопрос по select_sequential_consistency и insert_quorum. Вот была у нас таблица, в которую писались данные до включения этих двух опций. Включили. Не пропадут ли из SELECT-ов данные, записанные, когда не были активированы эти опции консистентности?

Опция select_sequential_consistency неправильно работает с партициями: https://github.com/yandex/ClickHouse/issues/2581 Её лучше не включать, пока не будет замержен фикс (уже готов).

Опция select_sequential_consistency неправильно работает с партициями: https://github.com/yandex/ClickHouse/issues/2581 Её лучше не включать, пока не будет замержен фикс (уже готов).

Спасибо! А что касается данных, записанных до включения select_sequential_consistency? Будут считаться консистентно записанными? Ведь для старых данных, записанных "до", подтверждения кворума не требовалось.

Будут считаться, иначе тяжело было бы переключаться на существующей таблице

Коллеги, а DATETRUNC в Tableau заработал? Были обещаны улучшения совместимости с Tableau в Q3 2018