Наверное это касается ODBC драйвера Postgres-а? Дело в том, что мы не используем prepared statements явно...

хм, посмотрим мб его скофигурировать можно на отключение prepared statements

А как можно сделать так, чтобы пользователь видел только базы, которые в allow_databases?

Такой возможности нет - пользователь видит все базы, но имеет доступ только к своим.

https://github.com/yandex/ClickHouse/releases/v1.1.54342-stable was tagged

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

@milovidov_an пытался сегодня собрать образ докера по инструкции https://clickhouse.yandex/docs/en/development/build.html бинарник 600 метров вышел,

Это нормально, если не отделять отладочную информацию. Например, в обычных пакетах это отделено и идёт бинарник ~150 МБ. PS. А если в целом, то более-менее пофиг на размер бинарника.

Это нормально, если не отделять отладочную информацию. Например, в обычных пакетах это отделено и идёт бинарник ~150 МБ. PS. А если в целом, то более-менее пофиг на размер бинарника.

может тогда сделаете версию докера где собирается образ прямо наместе, с определенной версией, что бы без deb пакетов

Это значит - качаешь Dockerfile и ждёшь в районе часа перед тем, как этим пользоваться? Хотя вроде бы полезно ещё, чтобы сделать ещё один пример воспроизводимой сборки. @proller, что думаешь?

Это значит - качаешь Dockerfile и ждёшь в районе часа перед тем, как этим пользоваться? Хотя вроде бы полезно ещё, чтобы сделать ещё один пример воспроизводимой сборки. @proller, что думаешь?

нет... локальная ci билдит указанный коммит , а ты качаешь и быстро обновляешь или откатываешь образ ... ну и патчи свои можно быстро собирать .. модно на alpine еще делать

Сделать Docker образ, в котором внутри все готовые бинарники и работает сразу, ничего не скачивая внутри и не устанавливая?

Сделать Docker образ, в котором внутри все готовые бинарники и работает сразу, ничего не скачивая внутри и не устанавливая?

ну в мире докера обычно так и делают, только пинарники и пара вспомогательных скриптов на баше запускать эти бинарники..

Да, я всё перепутал.

Да, я всё перепутал.

в общем получится примерно такой же образ, но будет гибкий пример "воспроизводимой сборки"

Имеется ввиду - сделать Dockerfile, который собирает ClickHouse из исходников любой нужной версии или коммита. Получится примерно тот же Docker образ, но зато можно собирать даже если нет соответствующих пакетов?

Имеется ввиду - сделать Dockerfile, который собирает ClickHouse из исходников любой нужной версии или коммита. Получится примерно тот же Docker образ, но зато можно собирать даже если нет соответствующих пакетов?

ага, что бы не было ситуаций когда где то там удалилсиь пакеты и нет нужной версии

типа такого - https://github.com/docker-library/php/blob/f4baf0edbc4e05e241938c68bcc7c9635707583d/7.2/stretch/cli/Dockerfile

Выглядит, как будто очень легко сделать. Есть даже два варианта. Первый вариант годится, если делаем образ на основе Ubuntu или Debian. Тогда достаточно запустить ./release --pbuilder. Он соберёт .deb пакеты и положит их директорией выше. Затем достаточно их установить. Второй вариант - примерно как сборка по инструкции... короче, вариация на тему make, make install. PS. Я совсем не разбираюсь, зачем нужен Alpine - чтобы облегчить образ? На Alpine, скорее всего, не соберётся, так как там musl libc, а мы с ним не проверяли.

Выглядит, как будто очень легко сделать. Есть даже два варианта. Первый вариант годится, если делаем образ на основе Ubuntu или Debian. Тогда достаточно запустить ./release --pbuilder. Он соберёт .deb пакеты и положит их директорией выше. Затем достаточно их установить. Второй вариант - примерно как сборка по инструкции... короче, вариация на тему make, make install. PS. Я совсем не разбираюсь, зачем нужен Alpine - чтобы облегчить образ? На Alpine, скорее всего, не соберётся, так как там musl libc, а мы с ним не проверяли.

да и на убунте норм, я сегодня делал, там рельно очень мало получается.. прям как в иснтрукции , только сделать красивее , объединить слои и удалить лишее. .. я просто не знаю что там за опции , как правилньо собрать что бы не 600 меторов бинарник получился

obj-copy -g

Выглядит, как будто очень легко сделать. Есть даже два варианта. Первый вариант годится, если делаем образ на основе Ubuntu или Debian. Тогда достаточно запустить ./release --pbuilder. Он соберёт .deb пакеты и положит их директорией выше. Затем достаточно их установить. Второй вариант - примерно как сборка по инструкции... короче, вариация на тему make, make install. PS. Я совсем не разбираюсь, зачем нужен Alpine - чтобы облегчить образ? На Alpine, скорее всего, не соберётся, так как там musl libc, а мы с ним не проверяли.

да, alpine для размера, сам он всего ~5мб

@milovidov_an вряд ли у вас будут проблемы с маслом, если вы не используете что-то очень сильно зависящее от glibc

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

вот разработчики strace на масл жаловались, да

@milovidov_an вряд ли у вас будут проблемы с маслом, если вы не используете что-то очень сильно зависящее от glibc

Особо не используем. Скорее всего всякие мелочи. Было бы хорошо использовать musl везде ради уменьшения зависимостей. Есть несколько причин, почему не сделали: - сложно встроить в систему сборки; - какие-то проблемы с dlopen, риски несоответствия ABI, если открывать с помощью dlopen библиотеки, собранные с использованием заголовочных файлов от glibc - библиотеки типа ODBC драйверов; - предположительно, некоторые важные функции работают медленнее - создание потока, блокировка mutex, strchr и подобные.

ну, я свою поделку собираю, но мне все эти проблемы некритичны для тех, кому нужна такая сборка - а это все любители эмбедщины

с dlopen проблемы не должно быть, если не используется tls

TLS где - у нас или в .so? В нашем коде точно используется.

в .so

скорость функций - спорный момент

glibc активно использует sse4.2, но выигрыш от него не такой существенный

я когда-то сравнивал и нашел разницу незаметной

Неплохо было бы потестировать. Но я пока не собирал - много сложностей. Если получится - скажите.

Это значит - качаешь Dockerfile и ждёшь в районе часа перед тем, как этим пользоваться? Хотя вроде бы полезно ещё, чтобы сделать ещё один пример воспроизводимой сборки. @proller, что думаешь?

Поставить virtualbox, в него docker и в нем собирать через pbuilder - we need to go deeper!

несколько старых версий можно собрать в pbuilder ручным запуском

Поставить virtualbox, в него docker и в нем собирать через pbuilder - we need to go deeper!

завязывай с троллингом, не все каждый день докер крутят)

На любой deb-based системе

С докерами есть смысл связываться если из какой-нибудь венды собрать нужно

Ну и надо помнить что памяти захочет 2g*num_cpu

ну вот если бы я таки смог запустить параллельную сборку (пока не смог), то собирал бы на aws или tencent - поднял сервера, собрал, забрал билд, погасил сервера

(у меня где-то в этих pbuild-ах бага, так-то допустим тот же llvm собирается параллельно)

на tencent билды дешевле будут, наверное (или кто там китайский aws сейчас)

Поставить virtualbox, в него docker и в нем собирать через pbuilder - we need to go deeper!

А виртуалку запустить на сервере под KVM

ну вот если бы я таки смог запустить параллельную сборку (пока не смог), то собирал бы на aws или tencent - поднял сервера, собрал, забрал билд, погасил сервера

А в чем именно проблема? что и как собираете?

да я вроде прокинул все переменные - в скрипт release (как временное решение, конечно) - типа: debuild -e DISTCC_VERBOSE=0 -e DISTCC_LOG=/home/ubuntu/distcc.log -e DISTCC_FALLBACK=0 -e PATH=/usr/lib/ccache:$PATH -e CCACHE_PREFIX=distcc но ccache подхватывается, а вот распределенной сборки - нет

может надо конечно в девелоперскую документацию смотреть было и напрямую с pbuild собирать

но сама связка ccache + distcc на трех серверах точно работает - и на примере типа hello_world.c и на сборке llvm

это бага, подсказка есть в скрипте ./release: debuild -e DEB_BUILD_OPTIONS=parallel=$THREAD_COUNT

Доброе утро. У меня есть один скорее архитектурный, чем программистский вопрос. Как лучше организовать хранение dimension-ов? В соседней строковой БД? Или в файликах рядом просто? Или загружать их в табличку с движком Memory?

dimensions лучше хранить в Dictionary

Привет, я со вчерашинм вопросом <Error> Application: DB::Exception: Cannot lock file /var/lib/clickhouse/status. Another server instance in same directory is already running. дропнуть файл попробовал

А ps aux | grep clickhouse-server уже ведь делали?

Привет, я со вчерашинм вопросом <Error> Application: DB::Exception: Cannot lock file /var/lib/clickhouse/status. Another server instance in same directory is already running. дропнуть файл попробовал

была такая фигня на убунте, дело было в том, что сервер запускался через systemd, пришлось вручную отключать его убедиться в наличии проблемы можно по команде sudo service clickhouse-server status. если там /etc/systemd/system/clickhouse-server.service - то проблема есть sudo systemctl disable clickhouse-server.service sudo mv /etc/systemd/system/clickhouse-server.service /etc/systemd/system/clickhouse-server.service.backup sudo systemctl daemon-reload

либо вроде как в последнем релизе исправили этот баг с systemd - https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

Но при апгрейде со старой версии придется потушить старый сервер через killall

ИЛИ sudo service clickhouse-server stop ДО апгрейда

пытаюсь сделать ALTER TABLE ... ON CLUSTER ... ADD COLUMN на локальной таблице ReplicatedMergeTree с 2 репликами на 2 шардах получаю: DB::Exception: Table ... is replicated, but shard #2 isn\'t replicated according to its cluster definition, как пофиксить ?

<internal_replication>true</internal_replication> указать ?

стоит по умолчанию, то есть false - писать во все реплики

нужно True, тк ReplicatedMergeTree сама занимается репликацией

там еще Distributed поверх, это не помешает ? достаточно изменить настройки сервера на всех нодах ?

Мой вам совет: просто сделайте альтер на каждом из шардов ;)

да

кстати да. там будет другая беда. альтер для таких таблиц не доделан

"альтер для таких таблиц не доделан" печально, а что будет работать ?

create и drop on cluster - работают

alter table on cluster получется не работает ?

он вероятно работает для merge таблиц, не проверял. но для реплицируемых - нет. не работает.

какой работающий способ добавить поле в реплицируемую таблицу/view таблицу с distributed шардами ?

старый добрый alter на каждом узле.

alter без on cluster ? после этого репликация не слетит ?

без. не слетит. этот альтер реплицируется внутри шарда.

Обновление нод кликхауса как поправильному делать? Просто обновлением пакетов или данные должны перезаливаться на ноду заново?

альтер на каждом шарде, по репликации приедет на другую реплику. по крайней мере, у меня так работает

достаточно сделать alter на шарде или все таки на каждой ноде ?

достаточно сделать alter на шарде или все таки на каждой ноде ?

Рабочая схема: 1) останавливаем запись в шард 2) делаем альтер на одной из нод шарда 3) включаем запись 4) тоже самое с остальными 5) альтерим distributed таблицы

как остановить/включить запись на шард ?

ту штуку которой пишите остановите

коллеги, а в 1.1.54342 запись в syslog выключена?

по умолчанию да, если нужно включить - <logger><console>1</console></logger>

sorry )

а еще есть секретная фича - <logger><use_syslog>1</use_syslog></logger>

отлично, спасибо! ?

а есть какие-то ориентировочные данные насколько скорость работы КХ по tcp и http отличается?

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

а еще есть секретная фича - <logger><use_syslog>1</use_syslog></logger>

А что с тикетом на "конфиги в yaml/json"?

а есть какие-то ориентировочные данные насколько скорость работы КХ по tcp и http отличается?

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

да у меня под го есть два драйвера на оба протокола, я просто хочу понять, будет ли значимый прирост скорости (изначально выбрал http)

для чего прирост ??? на запись или на чтение?

чтение, хочу таблицу в массив элементов считать, сам КХ отрабатывает за доли секунды, у меня же 20 секунд оно все читает, в той же сети

да у меня под го есть два драйвера на оба протокола, я просто хочу понять, будет ли значимый прирост скорости (изначально выбрал http)

отвечу и тут это проблема Гошной реализации database/sql https://github.com/golang/go/issues/22544

roistat драйвер используете?

а, вот Кирилл подсказал в чем проблема может быть https://github.com/golang/go/issues/22544

драйвер http://github.com/mailru/go-clickhouse

В драйвере с tcp сейчас делается "нативный" интерфейс который позволит очень сильно ускорится по сравнению с работой его в режиме драйвра database/sql