@clickhouse_ru

Страница 718 из 723
Alexey
24.10.2018
15:55:33
Всем, привет. Подскажите кто-нибудь сталкивался с ошибкой 2018.10.23 18:00:02.165703 [ 1 ] <Error> Application: DB::Exception: Cannot lock file /opt/data/clickhouse/status. Another server instance in same directory is already running. Проблема появилась после рестарта сервера, запущен один процесс clickhouse-server
Это значит, что ещё один clickhouse-server пытается стартовать. К счастью, есть проверка, которая не позволяет ему это делать. Но при этом, сообщение попадает в тот же лог файл, что и у запущенного сервера.

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

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

Google
Konstantin
24.10.2018
16:00:45
А в каком формате надо получить эти данные?
в mysql если развернуть через ST_AsText там лежит POLYGON((...)), так что String был бы за глаза

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


Alexey
24.10.2018
16:05:38
'Aggregator: Aggregation method: without_key' - это же не значит, что индекс не используется?
Да, это всего лишь говорит о том, какой выбран способ для вычисления group by.

Mike
24.10.2018
16:42:52
Да, это всего лишь говорит о том, какой выбран способ для вычисления group by.
То есть перестановка полей в order by повлияла на то, используется ли индекс?

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

Конечно, порядок в order by очень важен.

Mike
24.10.2018
16:57:49
Конечно, порядок в order by очень важен.
Тут вопрос у меня скорее в следующем: почему не используется индекс по user_id в первом варианте запроса, с "неправильным" порядком.

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

Alexey
24.10.2018
17:37:26
Тут вопрос у меня скорее в следующем: почему не используется индекс по user_id в первом варианте запроса, с "неправильным" порядком.
Посмотрите, есть статья о том, как работает индекс в MergeTree. В том числе, в документации, в разделе MergeTree. Всё зависит от распределения значений поля, которое стоит перед user id.

Denis
24.10.2018
20:52:21
Тут вопрос у меня скорее в следующем: почему не используется индекс по user_id в первом варианте запроса, с "неправильным" порядком.
там не видно сколько партиций и сколько гранулярность, теоритически можно размазать 1млн по 255 партициям, и будет 8192*255 > 1млн строк прочитано по индексу.

Google
Igor
25.10.2018
06:34:26
люди,а по этой баге нет никаких подвижек ? https://github.com/yandex/ClickHouse/issues/3411

бага кретичная для нас, т.к. мы не можем на новом кластере восстановить данные из бэкапа

Kirill
25.10.2018
07:00:07
бага кретичная для нас, т.к. мы не можем на новом кластере восстановить данные из бэкапа
А чем поломаная запись в distributed мешает разворачиванию бекапа (я намекаю на то, что у вас и до поломки distributed было что-то не так)

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

Wolf
25.10.2018
07:09:22
тем что мы делаем select \ insert в\из distributed таблицы
сделайте на локальную таблицу

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

Kirill
25.10.2018
07:48:31
тем что мы делаем select \ insert в\из distributed таблицы
У вас, видимо, данных не сильно много. Как дамп снимаете, таблиц много, данные связаны?

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

Vladimir
25.10.2018
07:53:00


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
нет, мы просто переезжаем
Понятно, да, в этом случае удобно через distributed или можно clickhouse-copier заюзать

Igor
25.10.2018
07:59:56
чем этот воркараунд лучше, чем исправление существующего бага?
ничем, но работать пока не пофиксили как-то надо

Paul
25.10.2018
08:00:50
конкретно наш кейс - это переливка данных из одного кластера в другой, с разнимы шардами и репликацией
у нас, кстати, тот же случай. clickhouse-copier удобен на постоянной основе (когда надо один кластер в другой среплицировать). А когда нужно просто перелить кусок данных их одного кластера в другой (с другой схемой шардирования и репликации), сделать логический дамп удобнее и быстрее

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

Просто есть "дешевый" бекап через 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
люди,а по этой баге нет никаких подвижек ? https://github.com/yandex/ClickHouse/issues/3411
А пока вы можете отметиться в issue на гитхабе. Я не уверен, что это как-то повлияет на скорость фикса, но все же. Я тоже жду фикса этого бага

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

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

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 можно

Ребят на сколько сейчас стабильно работает update?
стабильно в своих рамках которые надо учитывать

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

Alexandr
25.10.2018
09:57:56
Всем привет. Я тут создал некоторый view и получаю странный результат. Если сделать запрос из view я получаю в результате в поле nan, но если просто выполнить запрос из view, то все норм
Проблема решилась. Вьюха была вида CREATE VIEW default.`view_name` ( id String, dom Float64 ) AS SELECT 'name' AS id, sum(field1) / sum(field2) AS dom FROM ( any select ) помогло явное преобразования каждой sum() во Float64 (toFloat64(sum(field1) / toFloat64(sum(field2)))

При этом если просто выполнить запрос все норм. Бага?

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
страх есть всегда , но я весь год всегда брал последнюю из репо

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

Alexey
25.10.2018
10:15:10
страх есть всегда , но я весь год всегда брал последнюю из репо
То есть на свой страх и риск, и перед обновлением всегда лучше предварительно бэкапится.

Спасибо

Pavel
25.10.2018
10:16:00
Вот мне ни разу не очевидно )
это вы еще его волшебных енумов не видели.

Wolf
25.10.2018
10:18:48
То есть на свой страх и риск, и перед обновлением всегда лучше предварительно бэкапится.
Ну кх все таки предназначен для крупных систем, где есть всегда тестовая инсталляция, ну и правило работает не обновляй всегда пригождается

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
я в обоих случаях не вижу питонячьих дейттаймов из стандартной библиотеки, которые вы вставляете. вижу нампишный, вижу стрингу. но это не очень-то похоже на то, что ждёт кликхаус-драйвер.

Страница 718 из 723