11016
Обсуждаем ClickHouse
места с запасом пара ТБ, 4096 попробую 🙏🏻
Читать полностью…
там не через curl на 9234 а через nc какой нибудь проверить доступность по tcp
Читать полностью…
Да дело не в этом. Там возвращаются числа, у которых нет соответствующих кодеков, т.е. это либо мусор либо не тот байт читается
Читать полностью…
ок. это имплементация native протокола...
попробуйте на сервере зафиксировать
/etc/clickhouse-server/config.d/network_compression_method.xml
<clickhouse><network_compression_method>LZ4</network_compression_method></clickhouse>Читать полностью…
Надо смотреть что в replication queue в колонках про ошибки
Читать полностью…
Всем привет,
Наблюдаю проблему зависания очередей MERGE_PARTS в 24.8 Делаю копию кластера 10Т в новом хостинге Переношу данные через встроенный BACKUP DATABASE, RESTORE DATABASE ON CLUSTER ON S3. Размеры порядока 10Т тысяча табли и 200К партов. Во время BACKUP запись в кластер есть, но небольшая. Рестор проходит успешно за разумное время, сеть и диск утилизируются отлично через backup_threads/restore_threads, В итоге count по выборочным таблицам сходится на всех репликах
Но в replication_queue очередь MERGE PARTS, которая никак не разгружается. Тюнил пулы и аггресивнойсть мержа - не помогает разгружать быстрее (ресурсы сеть / диск не утилизированы). При рестарте в логах проскакивает WARNING что для таблиц отсутствует метадата, некоторые таблицы в READONLY.
На одном кейсе увидел что мержи валидные - последние парты из четырех мержатся в 6, на базе источнике на момент проверки 7 ; На момент BACKUP в источнике очереди нет. Конфигурация system.merge_tree, сходится.
Правильно я понимаю что это мержи партов прилетевших с S3 ? на что именно может влиять накопление MERGE_PARTS в этом кейсе, как можно их сократить или ускорить?
To obtain correct answers, users will need to complement background merges with query time deduplication and deletion removal. This can be achieved using the FINAL operator.
Подскажите, пожалуйста, FINAL для ReplacingMergeTree выполняет слияние внутри партиций, как это заложено в движке, или схлопывает строки внутри выборки?
Читать полностью…
У меня aws-инстансы t4g.large
Кластер поднялся уже, я всё правильно настроил, просто смотрел в пустой результат из таблицы system.replicas и думал, что ноды не видят друг друга (конфиг с 3 шардами + 1 репликой).
В каком смысле?
Влили его в 24.8.9
Каким образом 24.8.6 может подойти? И почему нельзя взять 28.4.14, в нее исправили ещё сотню багов по сравнению с 24.8.9
Это из-за того что вы делаете select* и выбираете колонку. Т.е. оптимизация не работает если колонку читать. Оптимизация именно в том что колонку можно не читать, потому что длина массива хранится отдельно.
Читать полностью…
Мне просто интересно, может ли это связано быть с запросом.
Но спасибо за помощь.
Хм..
А при такой баге она разве может быть плавающей?
То есть иногда оно срабатывает так, как должно и чаще неправильно.
Или это так "удачно" байтики прочитались получается?)
Странно, что данная проблема вылетает периодически только у меня на одном и том же запросе..
Но очень вряд ли запрос как-то аффектит сжатие, тем более я его менял на более простой и это не помогло…
Сложно связано.
На самом деле проблема не идентификаторе сжатия. А в том что читается совершенно не тот байт и тритится как идентификатор
Эээ я же ссылку приложил
Понятно что это баг и понятно в каком месте и почему он возник именно после апрейда
Вам чтобы временно вылечить надо выключить сеттинг. Можете взять фиддл из иши и включить сеттинг в старой 24.3 и убедиться что там такая же проблема, просто она не проявляется потому что сеттинг выключен там
А место на диске есть свободное?
schedule_pool_size поставьте 4096 если у вас тыщи таблиц.
тоже самое
select distinct last_exception, postpone_reason from system.replication_queue where is_currently_executing
SELECT DISTINCT
last_exception,
postpone_reason
FROM system.replication_queue
WHERE is_currently_executing
┌─last_exception─┬─postpone_reason─┐
1. │ │ │
└────────────────┴─────────────────┘
background_pool_size: 64Читать полностью…
background_schedule_pool_size: 192
background_common_pool_size: 64
background_merges_mutations_concurrency_ratio: 3
background_pool_size: 64
background_schedule_pool_size: 192
background_common_pool_size: 64
background_merges_mutations_concurrency_ratio: 3
А что в строках у которых is_currently_executing
Читать полностью…
В ошибках пусто
Читать полностью…
select distinct last_exception, postpone_reason from system.replication_queue where (last_exception is not null or postpone_reason is not null)
SELECT DISTINCT
last_exception,
postpone_reason
FROM system.replication_queue
WHERE (last_exception IS NOT NULL) OR (postpone_reason IS NOT NULL)
┌─last_exception─┬─postpone_reason─┐
1. │ │ │
└────────────────┴─────────────────┘
https://fiddle.clickhouse.com/486a03a4-a92c-4793-818f-fdbfd77599b2
Читать полностью…
Клик вплоть до 25.3 не реагирует на смену root CA в системе.
Вот конфиг:
<clickhouse>
<openSSL replace="1">
<server>
<certificateFile>/etc/clickhouse-server/certs/host.crt</certificateFile>
<privateKeyFile>/etc/clickhouse-server/certs/host.key</privateKeyFile>
<!-- <caConfig>/etc/clickhouse-server/certs/root-ca.crt</caConfig> -->
<verificationMode>relaxed</verificationMode>
<loadDefaultCAFile>true</loadDefaultCAFile>
<cacheSessions>false</cacheSessions>
<disableProtocols>sslv2,sslv3</disableProtocols>
<preferServerCiphers>true</preferServerCiphers>
sudo openssl verify -verbose "/etc/clickhouse-server/certs/host.crt"
Рандномно может быть из-за блоков. Результат из-за многопоточности и алгоритмов спиллинга рандомно собирается в блоки. Это видно в старых кликхауз клиентах ( в последних клиентах типа 25.6+ короткие результаты показываются одной табличкой). Т.е. вам можно попробовать поставить settings max_treads=1 и возможно баг будет стабильно проявляться или наоборот.
Читать полностью…
Версия 24.8.6.70 не подойдет?
Бэкпорт влили в 24.8.
Отдельные видосы или статьи обычно представляют из себя набор детских советов и сомнительных утверждений вроде избегания JOIN-ов или чуть продвинутее, про использование словарей.
можно порекомендовать статьи в KB Altinity
И начать желательно с вопросов реализации хранения, и особенно про ORDER BY
Далее про группировки и агрегации, как их выполнять оптимальнее и как под них подстраивать структуру хранения.
Далее про проекции с отсылками на предыдущие две темы.
После уже про соединения и веселые конструкции с ограничением присоединяемой таблицы подзапросом к основной. И о том, что соединение через UNION может быть лучше.
Затем про словари и dictGet
После этого можно добавить знаний по скип индесам.
И отсюда снова на первый пункт )))
а про соединение с представлениями… это прошлый век, когда еще были проблемы у анализатора старого.
А ну ок тогда. Давайте ничего не делать.
Читать полностью…
Да, спасибо. С выключенным оптимизатором для сабколонок все работает. Просто Вы написали про версию 24.8 а я удивился так как на 24.12 у меня все еще работало.
Читать полностью…
Пока не очень понимаю как это связано с идентификаторами сжатия, если честно)
Читать полностью…
да, клик не единственное хранилище будет. аи учитывая не самых добрых юзеров в виде метабейса\суперсета\даталенса и аналитиков, репликация не спасёт особо
Читать полностью…