11016
Обсуждаем ClickHouse
господа, а кто-то сталкивался с такой штукой когда при
backup database default to S3('https://.....ams3.digitaloceanspaces.com/backups/', 'KEY','SECRET') ;
2025.06.03 09:22:10.250818 [ 18525 ] {} <Error> TCPHandler: Code: 499. DB::Exception. (S3_ERROR), Stack trace (when copying this message, always include the lines below):
0. DB::Exception::Exception(DB::Exception::MessageMasked&&, int, bool) @ 0x000000000dd109bb
1. DB::S3Exception::S3Exception(String const&, Aws::S3::S3Errors) @ 0x000000001129a94d
2. DB::(anonymous namespace)::listObjects(DB::S3::Client&, DB::S3::URI const&, String const&) @ 0x0000000011803d95
3. DB::BackupWriterS3::fileExists(String const&) @ 0x0000000011808084
4. DB::BackupImpl::open() @ 0x0000000011752ca7
5. DB::BackupImpl::BackupImpl(DB::BackupFactory::CreateParams, DB::BackupImpl::ArchiveParams const&, std::shared_ptr<DB::IBackupWriter>) @ 0x0000000011753e12
Привет! У меня коллега попытался вопрос задать с многабукаф, но его автоматом забанило. Попробую сам:
пытаемся подкрутить аппку на pyspark 3.5.0, которая работала со старыми CH драйверами по JDBC (com.github.housepower:clickhouse-native-jdbc-shaded:2.7.1) , встраиваю ей по гайду новые + каталог (clickhouse.spark:clickhouse-spark-runtime-3.5_2.12:0.8.0).
да вот проблема - при записи "плюётся" ошибкой:
Читать полностью…
py4j.protocol.Py4JJavaError: An error occurred while calling o1242.append.
: org.apache.spark.SparkException: Job aborted due to stage failure: Task 4 in stage 25.0 failed 4 times, most recent failure: Lost task 4.3 in stage 25.0 (TID 86) (10.216.46.212 executor 8): com.clickhouse.spark.exception.CHServerException: [HTTP]user@host:8123}/db [210] Broken pipe
at com.clickhouse.spark.client.NodeClient.syncInsert(NodeClient.scala:150)
Ну вот я тоже думаю об этом,
Тогда буду генерить наборы данных, чтобы проверить именно не совпадение
добрый день
обхожу where в TTL
через multiif
TTL toStartOfDay(t1UTC) + multiIf(
column_a='111' and column_b = '11', INTERVAL 3 MONTH,
column_a = '222' and column_b = '22', INTERVAL 1 YEAR,
column_a in ('333', '444', '555', '666') and column_b = '33' and column_c not in ('x', 'y'), INTERVAL 10 YEAR)
ПО моему опыту - нормальное. Сначала реплика разгребает старый лаг, и в это время копится новый. Потом разгребет и его
Читать полностью…
{uuid} это не автогенерация, это ид таблицы, ясно почему оно одинаковое
Читать полностью…
{uuid} резолвится по другому... и нигде не определен
{shard} вообще в <macros> потому что определен... и там опять нет никаких шардов
потому что тупо на каждом сервере читается и резолвится в рантайме...
uuid макрос помогает при восстановлении из бекапа
но опять же вопрос не в этом, меня просто интересует как найти в документации почему макросы работают по-разному, один выполняется на инициаторе, второй на шарде
т.е макрос, как конструкция, работает по-разному, хотя по сути это должен быть string.replace для любой строки
вот я ищу в документации почему это не так
потому что иначе у вас таблицы с одним именем будут смотреть в разные пути в ZK
и никакой репликации не будет
тут должна быть эмоция палец вверх, мне недоступна
Читать полностью…
я бы перефразировал, ReplicatedMergeTree НИЧЕГО не знает про шарды, единственное место где используются шарды это когда {shard} макрос задан внутри replication_path в параметрах таблицы и тогда получается что реплики из разных шардов смотрят в разные пути ZK поэтому данные из разных шадров не реплицируются между собой
Читать полностью…
Может человек на медленном коннекте. Всякое бывает.
Читать полностью…
с таймаутами что только не делали пока - все равно ошибка возникает. В чем может быть проблема?
Читать полностью…
так вы попробуйте просто на стенде каком нибудь поиграться...
Читать полностью…
либо молча не будет применять, либо будет срать в логи о том что Nullable нельзя возвращать в TTL потому что там надо для сравнения какой то тип относящийся ко времени вернуть...
Читать полностью…
если реплика была долго оффлайн то она помечается как is_lost
и тогда тупо с остальных реплик данные тащит...
если не долго, то тащит только новое (там длинна очереди репликации 1000 по умолчанию)...
не очень понятно что вы имеется ввиду под "нельзя посмотреть на реплике"
там при старте просто идет загрузка primary.idx в память для текущих данных...
таблица будет в readonly пока не синкнется...
Всем привет, вопрос вот такой. Когда реплика находится в режиме восстановления( выключали на тех работы ) то в этот момент посмотреть что либо на реплике не удается, так же в момент "проигрывания" утерянных записей за время, начинает копиться новый лаг - текущий. То есть реплика восстанавливает данные за время выключения, и так же лаг появляется на текущие данные - это нормальное поведение репликации или диск не вывозит ?
Читать полностью…
Я правильно понимаю, что в момент запуска команды BACKUP DATABASE ClickHouse фиксирует состав данных которые будет бэкапировать и любые изменения этих данных в процессе выполнения не войдут в бэкап?
Читать полностью…
жесть какая... зачем вам это нужно?
зачем вам "реплиуируемые таблицы" которые не реплицируются?
я бы вообще uuid макрос отменил
его придмали и вставили в репликацию в полной уверенности что так можно всякие Rename и Excahgne быстро делать атомарно в Replicated таблицах для Atomic
так мне это и нужно, вопрос не в этом
вот я задаю путь /clickhouse/tables/{uuid}/{shard} on cluster '{cluster}'
я ожидаю что uuid при выполнении запроса будет разным на каждом шарде, а фиг, одинаковый, а вот шард разный
Ну так это, по факту, вопрос настройки шарда)
Обычно таки таблицы создаются соответственно макросу shard
Но при желании да, можно или кластер создать с одним шардом , или ручками шард проставить в пути зк. Но это скорее исключение же
вопрос, может кто знает
почему макрос {shard} при создании таблицы разолвится на каждом шарде, а uuid резолвится на инициаторе?
не могу найти это в документации
ReplicatedMergeTree вполне себе способен реплицировать данные между шардами и делает это, очень удобно когда нужно делать global join. таким образом можно маленькие таблицы копировать на каждый сервер и делать локальный джоин вместо глобального
Читать полностью…
/ме смеется на мобильном интернете (4G на два деления)
Читать полностью…
35 терабайтов ещё понятно, но 35 гигов это же вообще ни о чем
Читать полностью…
Вообще , кстати в бэкапе лежат не голые парты?
Я попытался выкачать из бэкапа папки с партами, закинуть в detached и приаттачить к таблице .
Там во многих папках не хватает файлов, кликхаус ругается
Это формат кликхаус бэкапа немного другой или таки битый бэкап у меня?
ЗЫ, не похоже, что битый, ведь RESTORE без ON CLUSTER нормально отрабатывает