Обсуждаем ClickHouse
нет, это просто флаг который позволяет стартовать и игнорировать кол-во broken партов
он ничего не форсит
а то что в детачед отлетело просто удалить можно , если все восстановится?
Читать полностью…это интересный вопрос, insert / update для iceberg
т.е. если КХ научится делать insert / update/ compaction для iceberg , то возникает вопрос почему это нельзя сделать для MergeTree, почему нужны костыли типа replicated* + zero replication
После того как увеличиваешь max_suspicious_broken_parts чтоб сервак стартанул. Оно само подтянет недостающие с реплики? или надо что-то вручную делать?
Читать полностью…=( Жаль... distributed_background_insert_batch +
SYSTEM DISTRIBUTED FLUSHможет как то ускорить? чтобы не куча мелких батчей? Читать полностью…
Универсальный формат данных в S3 хранить удобно, однако апдейтить в КХ нельзя пока
Читать полностью…это не репликация это вставка в distributed таблицу...
не надо ничего перемещать
увеличьте
background_distributed_schedule_pool_size
включите
distributed_background_insert_batch
если выключено
https://clickhouse.com/docs/engines/table-engines/special/distributed#distributed-writing-data
Всем привет. Подскажите, пожалуйста:
Два шарда, по две реплики. Некоторое время не работала корректно репликация между двумя серверами (из-за проблем на них) из-за чего скопилось много bin-файлов в data/database/table/shard2_replica1
(порядка 70 ГБ мелких файлов) и процесс синхронизации сильно тормозит.
Есть ли возможность переместить эти файлы из указанной директории и потом порциями подкладывать? чтобы внутренним механизмом они самостоятельно записались или только перезаливать?
парты качают ноды друг у друга напрямую
а о том, что скачать и у кого - узнают из кипера.
на пулл мне надо держать все 24\7, с пуш я могу условный эндпоинт триггерить только когда есть сообщение, за эндпоинтом может висеть лямбда, которая будет съедать мне 0 денег, пока ничего не делает
Читать полностью…имхо zero replication не поддерживается и не развивается
вангую никогда не будет не экспериментальным, скорее удалят вообще эту фичу
это не из-за АлиКлауд
это из-за zero replication + мутации. Это известная проблема.
Надо вам апгрейдится в 24.8+
И обязательно выключить zero replication. Иначе вы гарантировано будете терять данные при мутациях.
23.8.8.20 ???? в той версии КХ S3 был не продакшин рейди
У вас еще и zero replication наверное.
Удалять вам надо партиции drop partition - данные потеряны
флаг выглядит страшновато, он не зафорсит полный ресинк всех таблиц?
Читать полностью…само
проще sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
для одной таблицы поднял, на которой спотыкалось в .sql файле ее определения
Читать полностью…distributed_background_insert_batch может, но нужен рестарт КХ
Читать полностью…кстати background_distributed_schedule_pool_size влияет только если таблиц много, а так там однопоточный процесс пер таблица
Читать полностью…ну и вообще можно
clickhouse-client --receive_timeout=86400 -q "SYSTEM DISTRIBUTED FLUSH"Читать полностью…
кто-то пытается s3 one-zone - оно типа дешевле.
можно еще s3_plain_rewritable starting from 25.4. Но там несимметрично - писать можно только на одну ноду.
А вобще все побежали в сторону Iceberg. Счастье будет где-то там. Но это не точно.
ну и в довесок, с "пуллом" задержки будут больше, что не есть хорошо
Читать полностью…Все используют x3 размеры в S3 для реплицированных данных? Это затратно по деньгам
Читать полностью…ну поймал ))
что делать-то? pull не вариант для event-driven задач
с AWS не ловил проблем на мутациях. zero replication даже в 24.8+ остается экспериментальным?
Читать полностью…У вас еще и zero replication наверное.
теоритически эту проблему должен был решить coalescingmergetree
Читать полностью…