A
конструктор витрин сами делали?
Size: a a a
2021 January 24
A
м.б. кто-нить дружил knex.js с clickhouse
A
?
ИМ
@den_crane Хай, писал когда то про проблему отставаний реплик ровно ночью в 12 (начало случаться после новых дисков в рейд). Сказал что обновим кластер и посмотрим как пойдёт. Так вот обновили кластер до latest и всё стало нормально. Правда всё ещё увеличилось кол-во мерджей с 5к в среднем, до 10к. Немного настораживает, но судя по всему это нормальное поведение
S
Народ, кто нибудь с таким сталкивался?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
в логах ничего подозрительного
что он там ждет то теперь?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
SYSTEM RESTART REPLICAS; SYSTEM SYNC REPLICA default.test_repl
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
2021.01.24 14:07:08.723023 [ 47 ] {5fe1ce55-a6f7-4b6a-b1eb-e96d7baf0b1f} <Error> executeQuery: Code: 159, e.displayText() = DB::Exception: Watching task /clickhouse/test-cluster-for-alerts/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background (version 21.1.2.15 (official build)) (from 127.0.0.1:48432) (in query: DROP TABLE default.test_repl ON CLUSTER "all-replicated" SYNC)в логах ничего подозрительного
2021.01.24 14:04:08.032989 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Processing task query-0000000001 (DROP TABLE default.test_repl ON CLUSTER `all-replicated` NO DELAY)
2021.01.24 14:04:08.038707 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Executing query: DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.039701 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> executeQuery: (from 0.0.0.0:0, user: , using production parser) /* ddl_entry=query-0000000001 */ DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.044575 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Information> default.test_repl (cd3a90b5-71f8-46aa-bf84-2299b1ebc61d): Stopped being leader
2021.01.24 14:04:08.052720 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> DatabaseCatalog: Waiting for table cd3a90b5-71f8-46aa-bf84-2299b1ebc61d to be finally droppedчто он там ждет то теперь?
AR
Народ, кто нибудь с таким сталкивался?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
в логах ничего подозрительного
что он там ждет то теперь?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
SYSTEM RESTART REPLICAS; SYSTEM SYNC REPLICA default.test_repl
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
2021.01.24 14:07:08.723023 [ 47 ] {5fe1ce55-a6f7-4b6a-b1eb-e96d7baf0b1f} <Error> executeQuery: Code: 159, e.displayText() = DB::Exception: Watching task /clickhouse/test-cluster-for-alerts/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background (version 21.1.2.15 (official build)) (from 127.0.0.1:48432) (in query: DROP TABLE default.test_repl ON CLUSTER "all-replicated" SYNC)в логах ничего подозрительного
2021.01.24 14:04:08.032989 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Processing task query-0000000001 (DROP TABLE default.test_repl ON CLUSTER `all-replicated` NO DELAY)
2021.01.24 14:04:08.038707 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Executing query: DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.039701 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> executeQuery: (from 0.0.0.0:0, user: , using production parser) /* ddl_entry=query-0000000001 */ DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.044575 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Information> default.test_repl (cd3a90b5-71f8-46aa-bf84-2299b1ebc61d): Stopped being leader
2021.01.24 14:04:08.052720 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> DatabaseCatalog: Waiting for table cd3a90b5-71f8-46aa-bf84-2299b1ebc61d to be finally droppedчто он там ждет то теперь?
А подскажите пожалуйста где вообще описан atomic? В документации не могу ничего о нем найти
DC
А подскажите пожалуйста где вообще описан atomic? В документации не могу ничего о нем найти
смотрите митап от 1го октября
DC
Народ, кто нибудь с таким сталкивался?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
в логах ничего подозрительного
что он там ждет то теперь?
два сервера в кластере + zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT
стопаю zookeeper
таблица переходит в состояние ReadOnly
стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0
и делаю на всякий случай
SYSTEM RESTART REPLICAS; SYSTEM SYNC REPLICA default.test_repl
на обоих серверах
исполняется
без ошибок
но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится
2021.01.24 14:07:08.723023 [ 47 ] {5fe1ce55-a6f7-4b6a-b1eb-e96d7baf0b1f} <Error> executeQuery: Code: 159, e.displayText() = DB::Exception: Watching task /clickhouse/test-cluster-for-alerts/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background (version 21.1.2.15 (official build)) (from 127.0.0.1:48432) (in query: DROP TABLE default.test_repl ON CLUSTER "all-replicated" SYNC)в логах ничего подозрительного
2021.01.24 14:04:08.032989 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Processing task query-0000000001 (DROP TABLE default.test_repl ON CLUSTER `all-replicated` NO DELAY)
2021.01.24 14:04:08.038707 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Executing query: DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.039701 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> executeQuery: (from 0.0.0.0:0, user: , using production parser) /* ddl_entry=query-0000000001 */ DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.044575 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Information> default.test_repl (cd3a90b5-71f8-46aa-bf84-2299b1ebc61d): Stopped being leader
2021.01.24 14:04:08.052720 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> DatabaseCatalog: Waiting for table cd3a90b5-71f8-46aa-bf84-2299b1ebc61d to be finally droppedчто он там ждет то теперь?
а просто drop ( без on cluster ) работает?
S
а просто drop ( без on cluster ) работает?
Да, проходят, имеет смысл завести какой нибудь issue?
DC
Да, проходят, имеет смысл завести какой нибудь issue?
наверное стоит создать issue
кубернетис? имена хостов какие в drop on cluster в zk ?
кубернетис? имена хостов какие в drop on cluster в zk ?
S
наверное стоит создать issue
кубернетис? имена хостов какие в drop on cluster в zk ?
кубернетис? имена хостов какие в drop on cluster в zk ?
да кубер, но я могу наверное попробовать и под docker-compose поведение воспроизвести
да, есть ньюанс, имена хостов в кластере это имена k8s service они слегка отличаются от имен подов на которых это запускается... но имена реплик, в ReplicatedMergeTree это тоже имена сервиса
один сервис, один под
судя по всему, таблица на самом деле удаляется,но просто не приходит подтверждение когда делается
ON CLUSTER ... SYNC...
да, есть ньюанс, имена хостов в кластере это имена k8s service они слегка отличаются от имен подов на которых это запускается... но имена реплик, в ReplicatedMergeTree это тоже имена сервиса
один сервис, один под
судя по всему, таблица на самом деле удаляется,но просто не приходит подтверждение когда делается
ON CLUSTER ... SYNC...
S
в прошлый раз я SYNC добавлял чтобы оно работало ...
DC
да кубер, но я могу наверное попробовать и под docker-compose поведение воспроизвести
да, есть ньюанс, имена хостов в кластере это имена k8s service они слегка отличаются от имен подов на которых это запускается... но имена реплик, в ReplicatedMergeTree это тоже имена сервиса
один сервис, один под
судя по всему, таблица на самом деле удаляется,но просто не приходит подтверждение когда делается
ON CLUSTER ... SYNC...
да, есть ньюанс, имена хостов в кластере это имена k8s service они слегка отличаются от имен подов на которых это запускается... но имена реплик, в ReplicatedMergeTree это тоже имена сервиса
один сервис, один под
судя по всему, таблица на самом деле удаляется,но просто не приходит подтверждение когда делается
ON CLUSTER ... SYNC...
аа, я понял о чем вы
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
2021 January 25
S
аа, я понял о чем вы
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
спасибо большое, не знал про такую опцию
но
что-то вообще не помогло
эта штука через system.settings не отображается...
и не понятно есть она или нет
похоже что оно вообще при SYNC с тойже ошибкой вылетает даже если вообще несуществующую таблицу попросить удалить
сейчас воспроизведу через docker-compose и засабмичу баг
но
что-то вообще не помогло
эта штука через system.settings не отображается...
и не понятно есть она или нет
похоже что оно вообще при SYNC с тойже ошибкой вылетает даже если вообще несуществующую таблицу попросить удалить
сейчас воспроизведу через docker-compose и засабмичу баг
S
аа, я понял о чем вы
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
похоже дело в DNS именах хостов
то есть если удалять несуществующую таблицу через DROP TABLE IF EXISTS default.any_table ON CLUSTER SYNC
то вываливается ошибка
когда Pod у меня это clickhouse-0-0-0
а Service это clickhouse-0-0
и в remote_servers
прописан именно clickhouse-0-0:9000 (разрулил через alias в docker-compose)
тогда видимо при DROP TABLE ... SYNC
что-то ожидается в ddl Очереди из ZK ... и в результате не находится
интересно что? имя хоста?
поведение на docker-compose воспроизводится начиная с 20.10
когда SYNC вообще появился
то есть если удалять несуществующую таблицу через DROP TABLE IF EXISTS default.any_table ON CLUSTER SYNC
то вываливается ошибка
docker-compose exec clickhouse-0-0-0 clickhouse-client -q "DROP TABLE IF EXISTS default.any_name ON CLUSTER 'default' SYNC"
clickhouse-0-0 9000 0 1 0
Received exception from server (version 21.1.2):
Code: 159. DB::Exception: Received from localhost:9000. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background.
когда Pod у меня это clickhouse-0-0-0
а Service это clickhouse-0-0
и в remote_servers
прописан именно clickhouse-0-0:9000 (разрулил через alias в docker-compose)
тогда видимо при DROP TABLE ... SYNC
что-то ожидается в ddl Очереди из ZK ... и в результате не находится
интересно что? имя хоста?
поведение на docker-compose воспроизводится начиная с 20.10
когда SYNC вообще появился
S
аа, я понял о чем вы
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
наверное из-за
SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec>
ON CLUSTER 180s distributed_ddl_task_timeout 180
поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30
блин поставил
<database_atomic_delay_before_drop_table_sec>10</database_atomic_delay_before_drop_table_sec>
перестало воспроизводиться ...
видимо что то не так делаю
<database_atomic_delay_before_drop_table_sec>10</database_atomic_delay_before_drop_table_sec>
перестало воспроизводиться ...
видимо что то не так делаю
KP
Привет! Помогите пожалуйста! Есть таблица следующего вида:
source, partner, ..etc, totalRequest, requestSendToPartner
где source, partner, ..etc - измеререния
totalRequest, requestSendToPartner - метрики типа Int32
Необходимо составить запрос вида
source, partner, ..etc, sum(totalRequest), sum(requestSendToPartner)
Проблема состоит в том что totalRequest считается в момент когда partner = nil, при этом запрос может быть не отправлен ни на одного из партнеров
source, partner, ..etc, totalRequest, requestSendToPartner
где source, partner, ..etc - измеререния
totalRequest, requestSendToPartner - метрики типа Int32
Необходимо составить запрос вида
source, partner, ..etc, sum(totalRequest), sum(requestSendToPartner)
Проблема состоит в том что totalRequest считается в момент когда partner = nil, при этом запрос может быть не отправлен ни на одного из партнеров
S
Привет! Помогите пожалуйста! Есть таблица следующего вида:
source, partner, ..etc, totalRequest, requestSendToPartner
где source, partner, ..etc - измеререния
totalRequest, requestSendToPartner - метрики типа Int32
Необходимо составить запрос вида
source, partner, ..etc, sum(totalRequest), sum(requestSendToPartner)
Проблема состоит в том что totalRequest считается в момент когда partner = nil, при этом запрос может быть не отправлен ни на одного из партнеров
source, partner, ..etc, totalRequest, requestSendToPartner
где source, partner, ..etc - измеререния
totalRequest, requestSendToPartner - метрики типа Int32
Необходимо составить запрос вида
source, partner, ..etc, sum(totalRequest), sum(requestSendToPartner)
Проблема состоит в том что totalRequest считается в момент когда partner = nil, при этом запрос может быть не отправлен ни на одного из партнеров
то есть у вас две записи
одна source = XXX, partner= Null, totalRequest=ZZZ, requestSendToPartner=Null
вторая source=XXX, partner=YYYY, totalRequest=Null, requestSendToPartner=KKK ?
одна source = XXX, partner= Null, totalRequest=ZZZ, requestSendToPartner=Null
вторая source=XXX, partner=YYYY, totalRequest=Null, requestSendToPartner=KKK ?
KP
Да, именно так.
S
Да, именно так.
самое простое сделать два запроса
один WHERE partner IS NULL GROUP BY source, etc
второй WHERE partner IS NOT NULL GROUP BY source, partner
и как то либо через UNION ALL объеденить
и на стороне клиента уже вывести как надо
один WHERE partner IS NULL GROUP BY source, etc
второй WHERE partner IS NOT NULL GROUP BY source, partner
и как то либо через UNION ALL объеденить
и на стороне клиента уже вывести как надо