
Alexey
24.10.2018
15:55:33
lock файл остался видимо, попробуй удалить его
А вот удалять лок файл вручную нельзя. Он заблокирован другим процессом - это работает надёжно. Если файл существует, но никем не заблокирован, clickhouse-server пересоздаст его сам при запуске.


Алексей
24.10.2018
16:00:00
Алексей, спасибо за ответы. Осталось теперь найти откуда ещё один процесс берется

Google

Konstantin
24.10.2018
16:00:45

Алексей (OPS)
24.10.2018
16:00:49

Alexey
24.10.2018
16:05:38

Mike
24.10.2018
16:42:52

Alexey
24.10.2018
16:49:28
Смотрите в первую очередь на то, что показывает в качестве rows read клиент. Также можно смотреть на selected ... marks в логе сервера.
Конечно, порядок в order by очень важен.

Mike
24.10.2018
16:57:49
Еще вопрос: я попробовал сделать минимальный тест, когда в таблице очень мало строк, но index_granularity = 2.
Клиент после запроса не печатает rows read. Это нормально?

Alexey
24.10.2018
17:37:26

Denis
24.10.2018
20:52:21

Sergey
24.10.2018
23:13:01

Google

Igor
25.10.2018
06:34:26
люди,а по этой баге нет никаких подвижек ? https://github.com/yandex/ClickHouse/issues/3411
бага кретичная для нас, т.к. мы не можем на новом кластере восстановить данные из бэкапа

Kirill
25.10.2018
07:00:07

Igor
25.10.2018
07:00:53
тем что мы делаем select \ insert в\из distributed таблицы

Wolf
25.10.2018
07:09:22

Igor
25.10.2018
07:17:43
а потом перелить из локальной в дистрибьютед, спс, как вариант, пробнем если обновление?

Kirill
25.10.2018
07:48:31

Igor
25.10.2018
07:49:54
дамп - это просто seleсt into output file format native. Кол -во и размер не имеет значения, т.к. вставка маленькими частями тоже не помогает

Vladimir
25.10.2018
07:53:00

Kirill
25.10.2018
07:56:23

Igor
25.10.2018
07:56:52
да, но там не совсем понятно как это все делать, если кластер совсем другой
конкретно наш кейс - это переливка данных из одного кластера в другой, с разнимы шардами и репликацией

Kirill
25.10.2018
07:57:30

Igor
25.10.2018
07:57:50
нет, мы просто переезжаем

Paul
25.10.2018
07:58:56

Kirill
25.10.2018
07:58:58

Igor
25.10.2018
07:59:56

Paul
25.10.2018
08:00:50
Просто есть "дешевый" бекап через freeze partition
С ним много возни при переносе на кластер другой конфигураци. Сначала нужно с одной из реплик всех шардов собрать необходимые партиции, а потом руками их размазать по репликам нового кластера. Крайне неудобно. Сделать select из distributed-таблицы а потом insert в нее же на новом кластере - две команды в консоли

Google

Paul
25.10.2018
08:05:26
или вообще одна

Igor
25.10.2018
08:06:16
да, согласен. Есть как вариант, я его сейчас пробую, INSERT INTO <table> SELECT * FROM remote(<table>)
пока выполняется, думаю получится
но это как перенос между кластерами, для бэкапа это конечно не подходит

Paul
25.10.2018
08:08:14

Denis
25.10.2018
08:10:28
а что если объявить ноды нового кластера репликами нод старого, они всё сами выкачают. когда догонят, начинайте писать в новый кластер. ещё через время все старые записи среплицируются. и тогда старый кластер из зукипера можно будет вывести

Igor
25.10.2018
08:12:33
если бы был конкурс на самый сложный способ - вы бы его выиграли =)

Kirill
25.10.2018
08:14:59

Denis
25.10.2018
08:16:38
возможно, но меня беспокоит перераспределение записей из-за distributed. очень много лишних вычислений, а значит что-то может пойти не так

Paul
25.10.2018
08:16:59
У нас, например, есть задача иметь staging-кластер, который повторял бы production-кластер по хранимым данным (с допустимным отставанием в сутки), но не по конфигурации (staging менее нагружен и состоит из меньшего числа шардов и реплик). Когда мы это поднимали, clickhouse-copier еще не существовал. Копировать данные месячными партициями, когда нужно перенести только предыдущий день, с ручным распределением партиций по нодам нового кластера - не очень эффективное решение. Посему, мы просто делаем дамп из distributed-таблиц на production, и вставляем его в distributed-таблицы на staging.
Если и есть какое-то другое, более эффективное решение - буду рад узнать. К сожалению, сам других вариантов не нашел


Kirill
25.10.2018
08:24:47
Есть - если вам нужен стейджинг с копией данных продакшена то просто ходите в продакшен, зачем вам все эти проблемы и трата денег на железо

Stanislav
25.10.2018
08:25:36
Иногда в стейдж надо писать

Denis
25.10.2018
08:26:09
если надо писать, то старые данные не важны. пишите в пустой

Stanislav
25.10.2018
08:26:43
Точнее, принимать решение на имеющихся данных и писать результат.

Paul
25.10.2018
08:26:48

Stanislav
25.10.2018
08:26:54
И этот результат точно не нужен в проде.

Paul
25.10.2018
08:28:43
Еще одна причина - иметь раздельные среды для production и dev/staging. С невозможностью прочитать/записать данные из/в кластер(а) другой среды
Мне, кстати, очень интересно, как эту задачу решают в Я.

Google

Kirill
25.10.2018
08:35:54
У нас, например, разные продакшен/стейджинг
* вытаскиваем данные с продакшена за определенную дату для определеного"юзера"
* генерация данных
Копия никак не нужна

Stanislav
25.10.2018
08:38:48
У нас не Я, так что тупо делаем select ... from remote за нужное время.

Paul
25.10.2018
08:40:32
Понял, спасибо. Видимо, мы пошли по простому пути, и вместо генерации данных используем имеющиеся. Тем не менее, разные подходы к организации staging/production не отменяют факта существования бага :)
И необходимости его починки, я надеюсь

Kirill
25.10.2018
08:41:45
Да, надо чинить. Скоро https://opensourcefriday.com, надо брать за привычку фиксить хоть даже мелкий, но 1 баг

Paul
25.10.2018
08:44:15
Мы при обновлении сначала наступили на этот баг (в 18.12.17): https://github.com/yandex/ClickHouse/issues/3141
А потом на этот, когда решили обновиться на последнюю версию: https://github.com/yandex/ClickHouse/issues/3411
:(

Aleksandr
25.10.2018
08:54:02
Ребят на сколько сейчас стабильно работает update?

Alexandr
25.10.2018
09:20:41
Всем привет. Я тут создал некоторый view и получаю странный результат. Если сделать запрос из view я получаю в результате в поле nan, но если просто выполнить запрос из view, то все норм
Результат из view ┌─processing_date─┬─dom─┐
│ 2018-10-25 │ nan │
└─────────────────┴─────┘
Просто запрос ┌─processing_date─┬───────────────dom─┐
│ 2018-10-25 │ 0.537928671768169 │
└─────────────────┴───────────────────┘

Stanislav
25.10.2018
09:33:29
Кстати о вью... Мы таки дожили до того, что оно нам понадобилось на тех данных, что льём в кх. Есть вопрос по документации. Там буквально сказано следующее:
Запрос SELECT может содержать DISTINCT, GROUP BY, ORDER BY, LIMIT...
Входит ли в многоточие WHERE?
В документации и тестах ничего про это пока не нашел.

Wolf
25.10.2018
09:36:15
ну конечно where можно

Stanislav
25.10.2018
09:37:51
ну конечно where можно
Тогда что нельзя? И почему нельзя было написать "...может содержать те же параметры, что и для обычных таблиц, кроме..."?

Alexandr
25.10.2018
09:57:56
При этом если просто выполнить запрос все норм. Бага?


Sergey
25.10.2018
10:00:14
Вопрос по DateTime при использовании clickhouse_driver
Создаю таблицу
CREATE TABLE if not exists tbl (
datetime DateTime,
...
при попытке вставить в таблицу получаю ошибку-
Если это str в виде '2018-10-10 00:01:12', то AttributeError: 'str' object has no attribute 'tzinfo'
Ну и дальше чего только не перепробовал
pandas._libs.tslibs.timestamps.Timestamp -> AttributeError: 'numpy.datetime64' object has no attribute 'tzinfo'
time.struct_time -> AttributeError: 'time.struct_time' object has no attribute 'tzinfo'
и т.д.
Шохарактерно, если создаю поле только из даты (Date), то всё норм - не ломается и никаких ошибок не выдаёт
Че делать-то? =)

Alexey
25.10.2018
10:11:47
Добрый день всем !
Хотим обновить ClickHouse до последней версии.
Как понять какой релиз является стабильным.
Я вот вижу есть 18.12.17 и 18.14.8
Какой из них подходит для использования на проде ?
Может в названии должно быть слово stable ?

Google

Alexey
25.10.2018
10:12:51
Или можно без страха брать последнюю версию, потому что они все stable ?

Wolf
25.10.2018
10:13:34
страх есть всегда , но я весь год всегда брал последнюю из репо
она вседа считается стабильной, но совершенно не значит что стабильна, в кх есть определенное количество проблема как и в любом другом софте, слава богу опенсоурс и гит открыт и ишью можно почитать

Pavel
25.10.2018
10:14:44

Alexey
25.10.2018
10:15:10
Спасибо

Sergey
25.10.2018
10:15:30

Pavel
25.10.2018
10:16:00

Wolf
25.10.2018
10:18:48

Alexey
25.10.2018
10:19:19
Ладно спасибо !)

Wolf
25.10.2018
10:20:17

Alexey
25.10.2018
10:20:46

Wolf
25.10.2018
10:21:24
ну в будущем и обновитесь не каждый же день обновляться

Pavel
25.10.2018
10:23:54
я в обоих случаях не вижу питонячьих дейттаймов из стандартной библиотеки, которые вы вставляете. вижу нампишный, вижу стрингу. но это не очень-то похоже на то, что ждёт кликхаус-драйвер.