RO
таймаут клиента это странная штука, например в jdbc это не имеет отношения к КХ, и задается http client внутри java
я про стандартного клиента кх под никсками
Size: a a a
2020 July 08
DC
Required Optional
я про стандартного клиента кх под никсками
set receive_timeout = 6000
AR
Здравствуйте
Нужно ли при обновлении версии КХ в кластере выводить предварительно сервер из кластера?
Нужно ли при обновлении версии КХ в кластере выводить предварительно сервер из кластера?
YV
Здравствуйте
Нужно ли при обновлении версии КХ в кластере выводить предварительно сервер из кластера?
Нужно ли при обновлении версии КХ в кластере выводить предварительно сервер из кластера?
Нет, не нужно.
AR
Нет, не нужно.
Спасибо!
RO
set receive_timeout = 6000
🤟thank a lot
AE
Подскажите плиз, а есть возможность как-то узнать какие конкретно партиции прочитались при селекте? По записям в логе я впринципе вижу, что читается так как мне надо, но хотелось бы убедиться на 100%
RO
set receive_timeout = 6000
ему надо что-то исчо:
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
DC
Подскажите плиз, а есть возможность как-то узнать какие конкретно партиции прочитались при селекте? По записям в логе я впринципе вижу, что читается так как мне надо, но хотелось бы убедиться на 100%
вопрос непонятен, если в логе видно, то где еще хочется увидеть?
RO
вопрос непонятен, если в логе видно, то где еще хочется увидеть?
а вдруг они там совсем не чай пьют (с) Стругацкие
AE
вопрос непонятен, если в логе видно, то где еще хочется увидеть?
Ну в логе пишет типо "Selected 2 parts by date, 2 parts by key, 2 marks to read from 2 ranges" и всё. Но названий какие конкретно партиции прочитались не пишет.
Судя по данным в таблице и запросу - эти цифры похожи на правду и то что мне надо, но хотелось бы узнать прям названия партиций какие при селекте прочитались
Судя по данным в таблице и запросу - эти цифры похожи на правду и то что мне надо, но хотелось бы узнать прям названия партиций какие при селекте прочитались
AE
Required Optional
а вдруг они там совсем не чай пьют (с) Стругацкие
вот вот)
DC
Required Optional
ему надо что-то исчо:
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
хм, а какой КХ? какой запрос? select ?
RO
хм, а какой КХ? какой запрос? select ?
не не... Запрос OPTIMIZE TABLE ... FINAL
DC
Required Optional
не не... Запрос OPTIMIZE TABLE ... FINAL
он неотменямый, т.е. клиент будет ждать пока незакончится
странно мне казалось что receive_timeout можно через set поставить (чинили это).
clickhouse-client --receive_timeout=9000
странно мне казалось что receive_timeout можно через set поставить (чинили это).
clickhouse-client --receive_timeout=9000
RO
он неотменямый, т.е. клиент будет ждать пока незакончится
странно мне казалось что receive_timeout можно через set поставить (чинили это).
clickhouse-client --receive_timeout=9000
странно мне казалось что receive_timeout можно через set поставить (чинили это).
clickhouse-client --receive_timeout=9000
:) OPTIMIZE table sharded.Sensitivity FINAL
OPTIMIZE TABLE sharded.Sensitivity FINAL
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
Ok.
Query was cancelled.
0 rows in set. Elapsed: 869.563 sec.
:) show processlist
SHOW PROCESSLIST
Ok.
OPTIMIZE TABLE sharded.Sensitivity FINAL
Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
Ok.
Query was cancelled.
0 rows in set. Elapsed: 869.563 sec.
:) show processlist
SHOW PROCESSLIST
Ok.
DC
вот это все значит что Optimize успешно выполнилось за Elapsed: 869.563 sec.
DC
он не может отменить OPTIMIZE и ждет пока тот вернет управление
RO
вот это все значит что Optimize успешно выполнилось за Elapsed: 869.563 sec.
Вот в чем то дело. Если не знать и читать логи то получается что он постарался убить корректно запрос и убил через 869.563 sec.
RO
только вот блоков из 36 стало 46... проверяю на дупликаты