зачем вы вообще делаете делете с участием несуществующей таблицы то ?

Я передаю внешний файл в котором данные для WHERE GLOBAL NOT IN а эта штука не понимает и не прокидывает данные, а пытается это из таблицы сделать локальной (

Если четко задавать where column = 'a', то все ок работает. А если с подзапросами, то там "побойся бога" случается

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

КХ 18.12.13 настройка log_queries=1 еще действующая? Таблица не создается, в лог запросы при включенном трейс уровне пишуться но обрезаются, например в инсерте после value.

@proller self-signed, похоже, работает (хотя там возникает другая проблема - 'DB::Exception: Cannot insert into table in readonly mode')

зачем distributed вообще write access - я ей задал read-only юзера, так как у меня нет реплик, только шарды

Привет! Когда лучше использовать toYYYYMMDD(EventDate) вместо toYYYYMM(EventDate)? Это даст какое-то улучшение, если в запросах везде используется EventDate >= '...'?

Первичный ключ не будет работать более эффективно, если заменить партиционирование по месяцам на партиционирование по дням. То есть, просто так это делать не нужно.

Ох уж эти мутации. 2018.10.05 15:40:50.098966 [ 13 ] <Error> default.entities_results_replicated (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after mutation is not byte-identical to data on another replicas. We will download merged part from replica to force byte-identical result. Валит нонстопом и висят мутации в процессе...Я так понял их лучше запускать ТОЛЬКО на мастер репликах либо только на одной реплике

Мутации можно запускать на любой реплике. Сразу на двух не надо (это можно, но в лучшем случае не будет никакой разницы - оба запроса склеятся, а в худшем случае они могут выполниться дважды, и второй запрос будет работать вхолостую).

И такие траблы начинаются если во время мутации что-то пошло не так. Например delete where column in ANOTHER_TABLE и вот если ANOTHER_TABLE не существует, но потом появляется, то мутация проходит, но данные бьются

А вот с этим действительно проблема - если делаете мутацию с подзапросом.

Проблема в том, что подзапрос (в выражении для ALTER DELETE/UPDATE) выполняется много раз - на каждый блок. Насколько я помню, это уже исправили, но совсем недавно. И в релизе пока есть проблемы.

КХ 18.12.13 настройка log_queries=1 еще действующая? Таблица не создается, в лог запросы при включенном трейс уровне пишуться но обрезаются, например в инсерте после value.

Настройка правильная. Запросы INSERT всегда логгируются без данных.

Настройка правильная. Запросы INSERT всегда логгируются без данных.

Спасибо

он не завис, он работал с чтением/записю проблем небыло

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

Я думаю что нельзя удалять таким образом (WHERE GLOBAL NOT IN). Если вторая таблица меняется, и реплики выполняют мутацию в разное время, то результат мутации будет разный. Т.е. надо select-м найти "id" всех записей которые надо удалить, сложить в какую-то промежуточную таблицу и разложить эту таблицу на все реплики, и потом удалять where in

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

@proller в общем, какая-то мистика. с нормальным сертификатом вылазит аж две разных ошибки: 2018.10.05 14:41:17.945163 [ 25 ] <Error> ServerErrorHandler: Code: 210, e.displayText() = DB::NetException: SSL Exception: error:14037418:SSL routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert unknown ca: while r eading from socket (10.7.93.133:45618), e.what() = DB::NetException, Stack trace: и 2018.10.05 14:41:17.945222 [ 22 ] <Error> D.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: SSL Exception: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify fai led: (10.7.93.133:9440), e.what() = DB::NetException, Stack trace:

сертификат много раз перепроверил - все отлично. в бандле на ca сертификате стоит ca, на серверном сертификате все x509 атрибуты в порядке

я уже хз, куда копать. код этого проклятого поко посмотрел - тоже все должно быть в норме, ну и в client стоит <verificationMode>none</verificationMode> <invalidCertificateHandler> <name>AcceptCertificateHandler</name> </invalidCertificateHandler>

может он бандл не умеет прочитать?

https://github.com/pocoproject/poco/blob/381b868e772fe73e1d66d18f34433d2ddac1d5e6/NetSSL_OpenSSL/src/Context.cpp#L126

ssl это делать точно умеет

openssl

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_load_verify_locations.html

If CAfile is not NULL, it points to a file of CA certificates in PEM format. The file can contain several CA certificates identified by ...

сейчас еще попробую отдампить tls сессию

но вряд ли что-то, кроме алертов, там будет вид о

Первичный ключ не будет работать более эффективно, если заменить партиционирование по месяцам на партиционирование по дням. То есть, просто так это делать не нужно.

Спасибо за ответ! У нас сортировка примерно такая: (Id1, Id2, Id3, EventDate). В некоторых запросах фильтрация только по EventDate. Имеет смысл в этой ситуации использовать toYYYYMMDD? И какие минусы?

Спасибо за ответ! У нас сортировка примерно такая: (Id1, Id2, Id3, EventDate). В некоторых запросах фильтрация только по EventDate. Имеет смысл в этой ситуации использовать toYYYYMMDD? И какие минусы?

А вот в этой ситуации как раз имеет смысл сделать партиции по дате. Потому что при фильтрации только по EventDate, первичный ключ, скорее всего, будет почти не использоваться, и остаётся ключ партиционирования.

Если партиционирование по месяцам, то ключ партиционирования тоже будет использоваться, но менее эффективно.

Круто! Спасибо)

Всем привет. Я уже спрашивал похожий вопрос, но появились новые факты. Изначально вопрос звучал так, что с некоторых пор клик начал ругаться на вставках данных от 50к до 150к за раз. Данные вставлялись в формате JSONEachRow, на что клик ругался: Code: 117, e.displayText() = DB::Exception: Unknown field found while parsing JSONEachRow format: ...., e.what() = DB::Exception То что битый JSON было исключено сразу т.к. разбивая пачку, допустим по 10к - все шло на ура. Здесь мне предложили использовать настройку "max_query_size" (хотя ранее такие объемы вставлялись и без нее), в большинстве случаев данная настройка помогла. Но одна пачка все никак не хотела вставляться (которая все также по 10к вставлялась нормально). Пробовал по разному и последнее ради интереса решил просто взять перемешать массив вставляемых JSON-строк перед вставкой и все сработало. Кто с таким сталкивался, может я вообще не в ту сторону копаю? версия 18.14.1

Всем привет. Я уже спрашивал похожий вопрос, но появились новые факты. Изначально вопрос звучал так, что с некоторых пор клик начал ругаться на вставках данных от 50к до 150к за раз. Данные вставлялись в формате JSONEachRow, на что клик ругался: Code: 117, e.displayText() = DB::Exception: Unknown field found while parsing JSONEachRow format: ...., e.what() = DB::Exception То что битый JSON было исключено сразу т.к. разбивая пачку, допустим по 10к - все шло на ура. Здесь мне предложили использовать настройку "max_query_size" (хотя ранее такие объемы вставлялись и без нее), в большинстве случаев данная настройка помогла. Но одна пачка все никак не хотела вставляться (которая все также по 10к вставлялась нормально). Пробовал по разному и последнее ради интереса решил просто взять перемешать массив вставляемых JSON-строк перед вставкой и все сработало. Кто с таким сталкивался, может я вообще не в ту сторону копаю? версия 18.14.1

https://github.com/yandex/ClickHouse/issues/3297

https://github.com/yandex/ClickHouse/issues/3297

Спасибо за информацию.

@proller я не знаю, что изменилось, но оно после self signed сертификатов ВНЕЗАПНО заработало и с нормальными. Теперь только срет непрерывно вот таким: 2018.10.05 17:09:30.610370 [ 25 ] {6896c461-9a1e-47d9-b9d2-01049734fd20} <Error> executeQuery: Code: 164, e.displayText() = DB::Exception: Cannot insert into table in readonly mode, e.what() = DB::Excep tion (from 10.7.93.133:47256) (in query: INSERT INTO test.A VALUES), Stack trace: и counter part: 2018.10.05 17:09:58.965025 [ 24 ] <Error> D.Distributed.DirectoryMonitor: Code: 164, e.displayText() = DB::Exception: Received from 10.7.93.133:9440. DB::Exception: Cannot insert into table in readonly mode. Stack trace: причем, на обоих шардах (шарды содержат ровно одну реплику)

@proller есть идеи, отчего и почему данный подземный стук происходит?

ну видимо отвалился зк

@proller я не знаю, что изменилось, но оно после self signed сертификатов ВНЕЗАПНО заработало и с нормальными. Теперь только срет непрерывно вот таким: 2018.10.05 17:09:30.610370 [ 25 ] {6896c461-9a1e-47d9-b9d2-01049734fd20} <Error> executeQuery: Code: 164, e.displayText() = DB::Exception: Cannot insert into table in readonly mode, e.what() = DB::Excep tion (from 10.7.93.133:47256) (in query: INSERT INTO test.A VALUES), Stack trace: и counter part: 2018.10.05 17:09:58.965025 [ 24 ] <Error> D.Distributed.DirectoryMonitor: Code: 164, e.displayText() = DB::Exception: Received from 10.7.93.133:9440. DB::Exception: Cannot insert into table in readonly mode. Stack trace: причем, на обоих шардах (шарды содержат ровно одну реплику)

бесправный пользователь?

ну, я не очень понимаю, зачем distributed пользователю read-write доступ, но я его для иксперемента разрешил

zk нет

ну, я не очень понимаю, зачем distributed пользователю read-write доступ, но я его для иксперемента разрешил

Ну а как оно будет читать и писать то?

мне не нужно, что-то писать через distributed

по-моему, юзкейс вполне очевидный

Ну у вас в ошибке Кен нот инсерт, видимо все таки пишите

нет, не пишу

а если и писал, то это было давно и неправда

а в логи все это срется без перерыва каждые 5 секунд

а если и писал, то это было давно и неправда

distributed таблица пытается отправить данные до тех пор, пока не получится. Если это давняя неправда, удалите данные у distributed

о как, спасибо

хотя все равно непонятно, почему ей это с read-write юзером не удается

Cannot insert into table in readonly mode - значит что у юзера readonly=1

тот сервер который ругается - что у него в логе про этот запрос, от какого он юзера?

этого он не сообщил

хотя все равно непонятно, почему ей это с read-write юзером не удается

на 10.7.93.133 у пользователя есть права на запись?

конфиги на шардах идентичные

профиль пользователя distributed read-write

если в executeQuery: (from .... не написало юзера - значит юзер=default

а кто может посоветовать клиент для КХ питоновский ?

INSERT INTO test ( Field1, Field2, EventDate, Field3, Field4, Value, EntryType ) VALUES ( UUIDStringToNum('11111111-1111-1111-1111-111111111111'), ‘a’, '2018-08-01', ‘b’, ‘c’, 42, ‘c' )

вот такой запрос валится https://github.com/mymarilyn/clickhouse-driver

INSERT INTO test ( Field1, Field2, EventDate, Field3, Field4, Value, EntryType ) VALUES ( UUIDStringToNum('11111111-1111-1111-1111-111111111111'), ‘a’, '2018-08-01', ‘b’, ‘c’, 42, ‘c' )

амперсанды же разные в запросе ‘ '

это уже телеграм

простите, что не уточнил

сгенерированный руками запрос выполненный в консольном clickhouse-client все корректно вставляет

https://github.com/cloudflare/sqlalchemy-clickhouse

вот это работает

вот такой запрос валится https://github.com/mymarilyn/clickhouse-driver

Этот драйвер использует Native интерфейс, передающий на сервер готовые данные для вставки, разложенные по столбцам и сжатые. Что конечно очень круто и эффективно :) Но из-за этого получается так, что если в запросе INSERT присутствуют выражения (а не просто готовые значения), то их надо сначала выполнить, на клиенте. И если клиент не содержит в себе маленький ClickHouse, то он не может это сделать.

спасибо

понятно

UUID должно быть можно указывать просто в одинарных кавычках (если драйвер поддерживает UUID).

Привет, коллеги! Что это такое, надо ли бояться? 2018.10.06 13:03:16.878937 [ 43 ] <Warning> clicks.transactions_2018_10 (ReplicatedMergeTreePartCheckThread): Checking part 20181001_20181001_73541_73541_0 2018.10.06 13:03:16.878946 [ 43 ] <Warning> clicks.transactions_2018_10 (ReplicatedMergeTreePartCheckThread): We have part 20181001_20181001_73472_73665_3 covering part 20181001_2018100 1_73541_73541_0

И это счастье сопровождается... ZooKeeperImpl::Exception: Transaction failed at op #0 (No node)

У меня такое было, чаще всего само проходит. Долго наблюдаете?

И это счастье сопровождается... ZooKeeperImpl::Exception: Transaction failed at op #0 (No node)

Судя по всему у вас какие то проблемы в ЗК посмотрите его лиги

Логи

У меня такое было, чаще всего само проходит. Долго наблюдаете?

Не стали терпеть, остановили вставку, перезагрузили сервис на Шарде. Длилось пару часов. Да, был сбой зукипера 1 октября.

мне помогало еще детачить проблемный партишен

странное решение) хотя если были реплики, то наверное нормальное. у нас пока нет.