Ну так вы же уже очистили ЗК или нет?

Да, но КХ при этом не перестал срать логами о проблемах с данными. Рестарт серверов не помог.

Я говорит вижу косяк, попробую с реплики стянуть. Потом орет, что нет данных в ЗК и вообще на репликах ниче найти типа не могу

Ну так вы переместите данные и потом аттач сделайте

Ну так вы переместите данные и потом аттач сделайте

Уже поздняк метаться )

Но за идею спасибо!

В новосозданные таблицы

Ну как Поздняк других вариантов вроде и нет

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

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

Я пробовал timestamp limit 100 делать из большой таблицы, несколько значений одного дня захватывал

То есть агрегаты дневные нельзя отрисовать?

можно, если date-range будет не с 13 до 19 часов, а с какого-то числа по какое-то

можно, если date-range будет не с 13 до 19 часов, а с какого-то числа по какое-то

У меня как раз дейтрендж

С 15 сентября и далее

смотрел по этой картинке

преобразуйте start в dateTime и используйте это значение для сортировки и группировки

смотрел по этой картинке

Там дневной агрегат, и в респонсе данных достаточно для отрисовки, но выводит только первое значение

преобразуйте start в dateTime и используйте это значение для сортировки и группировки

Хорошо, попробую. Спасибо

Старт изначально в дейтайме

Я его агрегирую, чтобы графики по дням посмотреть

тогда не нужно его преобразовывать в date

тогда можете использовать toStartOfDay - https://clickhouse.yandex/docs/en/query_language/functions/date_time_functions/

Судя по таблице system.replicas одна из машин является лидером для реплицируемой таблицы. Почему она мерджит данные в блок с именем, отличающимся от всех остальных? На трех серверах это: 20180901_20180930_0_1091338_306 а на лидере: 20180901_20180930_1091350_1091370_2 Вижу, что набор исходных блоков отличается. От чего он может отличаться в реплицируемых таблицах, причем значительно(34 куска за сентябрь на лидере, против 50 - на остальных)?

Судя по таблице system.replicas одна из машин является лидером для реплицируемой таблицы. Почему она мерджит данные в блок с именем, отличающимся от всех остальных? На трех серверах это: 20180901_20180930_0_1091338_306 а на лидере: 20180901_20180930_1091350_1091370_2 Вижу, что набор исходных блоков отличается. От чего он может отличаться в реплицируемых таблицах, причем значительно(34 куска за сентябрь на лидере, против 50 - на остальных)?

Ну лидер принимает решения о мержах судя по тому что вы сделали что то странное с зукипером вышло так

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

Такой странный вопрос: восстановление из r/o после потери связи через какое время происходит, если происходит?

*потери связи с zookeeper

Если я забэкапил все партиции методом Alter table ... FREEEZE Partition... Из Shadow они не должны пропасть сами. так ?

Такой странный вопрос: восстановление из r/o после потери связи через какое время происходит, если происходит?

Как узнать? Вот вчера в логе: 2018.10.01 16:03:36.967522 [ 760 ] <Error> void DB::AsynchronousMetrics::update(): Cannot get replica del ay for table: default.graphite_tree: Code: 242, e.displayText() = DB::Exception: Table is in readonly mod e, e.what() = DB::Exception, Stack trace: и сразу: 2018.10.01 16:03:37.747095 [ 22 ] <Error> default.graphite_tree (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception, Stack trace:

и почти сразу: 2018.10.01 16:04:20.076853 [ 363 ] <Error> executeQuery: Code: 24, e.displayText() = DB::Exception: Cannot write to ostream at offset 2097152

Что значит "как узнать"? Я и так знаю, что таблицы в r/o. Меня интересует - они сами восстановятся в r/w или надо пинать после восстановления связи?

как правильно пинать, перезагрузкой clickhouse-server ?

рестартом сервиса

штатным

нашел начало РО режима: <Information> default.graphite (StorageReplicatedMergeTree): Cancelled merging parts

Привет! KX на Red Hat, норм? Или лучше не пробовать?

2018.10.01 16:04:29.597326 [ 1152 ] <Debug> executeQuery: (from 127.0.0.1:44396, query_id: 38b07b58-3a1d-4797-86ce-7ced2a9a0c8d) INSERT INTO graphite (Path, Value, Time, Date, Timestamp) FORMAT RowBinary

Что значит "как узнать"? Я и так знаю, что таблицы в r/o. Меня интересует - они сами восстановятся в r/w или надо пинать после восстановления связи?

Сами меньше чем за минуту очухались, о чем это говорит?

О том, что таймаут - в пределах 60 секунд...

И что мне быстрее перезапустить...

ок, спасибо.

Другой вопрос: после ругани зукиперов обнаруживаю, что на одной ноде меньше данных чем на других, она же их должна с реплик слить или это не происходит, если данные были(записи в зукипере также исчезли) , как правильно засинкать неполноценный сервер с доноров ?

если скопирую на него данные в detached и выполню ATTACH , он же по реплике передаст свои новые блоки и будут дубли, так ?

или они исчезнут при оптимизации ?

А что показывают RejectedInserts, количество отвергнутых строк, или количество отвергнутых батчей в инсертах?

омг, кто может сказать какие порты надо открыть на системе, что бы этот tabix запущенный из под nginx подключался к clickhouse сервер локально?

ибо я пол дня вчера провозился и хоть убейся об стену графана с интернета подключаеться по https://host:9440 юзер+ пароль но эта сволочь tabix - нивкакую что локально, что запущенный с другого хоста в интернете...

табикс подключается из браузера

хочет либо 8123 (http), либо 8443 (https)

Можно пробросить тем же nginx

Можно пробросить тем же nginx

прямо на впс, где кликхаус, стоит Nginx - табикс запущенн по манулу, но не может, говорит проверьте юзера пароль хост порт

то же и с докера у меня на ноуте локально

А что показывают RejectedInserts, количество отвергнутых строк, или количество отвергнутых батчей в инсертах?

Как смотреть?

хочет либо 8123 (http), либо 8443 (https)

и даже 8123 открыт фаерволом для 127,0,0,1 и не хочет

прямо на впс, где кликхаус, стоит Nginx - табикс запущенн по манулу, но не может, говорит проверьте юзера пароль хост порт

Ну так пробрось в nginx 8123 или оберни его в https на 8443

И почитай что-нибудь про сеть.

127.0.0.1 везде свой

127.0.0.1 везде свой

прямо на впс, где кликхаус, стоит Nginx

ну так настрой его

ок

не убегай

сейчас покажу конфиг Nginx

и даже 8123 открыт фаерволом для 127,0,0,1 и не хочет

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

127.0.0.1 не сканает

окей, момент

ну только если тунель сделаешь

Кстати, вариант. ssh -L 8123:localhost:8123 никто не отменял

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

графана подключается сама, а не через твой броузер

графана подключается сама, а не через твой броузер

ей в коннекте указано https://104.248.44.235:9440 username password

ну и файрволлы никто не отменял, кстати...

там у неё 2 режима есть, через проксик и напрямую, у тебя как?

По умолчанию она как-раз через свой проксик подключается, поэтому всё работает.

Коллеги, доброе утро, а проблему с "Block structure mismatch" кто как решает? Откатывать версии кх?

началось вчера с обновления на 18.12.17

У нас такое на селекте в одной таблице есть, есди из селекта убрать limit или order by, помогает

Сделать лимит или ордер сверху: select from (проблемный запрос без лимита) limit 1000

там у неё 2 режима есть, через проксик и напрямую, у тебя как?

Code: 210. DB::NetException: Connection refused: (104.248.44.235:9000)

мой айпи в файерволе открыт 100%

открой режим разработчика в браузере и посмотри куда таббикс запросы отправляет. Сразу всё понятно стенет

открой режим разработчика в браузере и посмотри куда таббикс запросы отправляет. Сразу всё понятно стенет

ну ок табикс, я запускаю комманду clickhouse-client --host=104.248.44.235 --port=9000 --user=USERNAME --password=PASS ClickHouse client version 18.12.17. Connecting to 104.248.44.235:9000 as user conductor. Code: 210. DB::NetException: Connection refused: (104.248.44.235:9000)

с айпи который разрешен к коннекту в фаерволе, в конфиге сервера открыты порты и ссл и нет, но фаерволом разрешения сверху на айпи повешены

1) порт таки 8123 (ну или 8443), а не 9000 2) на вдс он слушается? Туда можно зайти бразуером?

ну ок табикс, я запускаю комманду clickhouse-client --host=104.248.44.235 --port=9000 --user=USERNAME --password=PASS ClickHouse client version 18.12.17. Connecting to 104.248.44.235:9000 as user conductor. Code: 210. DB::NetException: Connection refused: (104.248.44.235:9000)

кажется ты выше писал что у тебя кликхаус 127,0,0,1 слушает, так что ты хочешь?

кажется ты выше писал что у тебя кликхаус 127,0,0,1 слушает, так что ты хочешь?

типа жесткий бинд на апйпи:порт и хоть застрелись?

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

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

Code: 32. DB::Exception: Attempt to read after eof

слушать реальный айпи сделал

ошибки в доке опсианы ? ;)

не факт