А MV1, который клал в Т, из-за этого падает

MV1 рождает инсерт в T, этот инсерт передает вставляемый блок в MV2

Мне это ещё предстоит осознать)

Просто стокнулся вот лоб в лоб сейчас

Да, спасибо, теперь буду знать

Инфу подобную по клику конечно тяжело искать, может мне так кажется конечно

ну если в топике попадется корявая запись, то инсерты тоже остановятся и опять придется копаться в логах разбираясь что не так.

Короче на логи одна надежда

In logs we trust, такскть

хм. допустим у нас есть таблица с кучей данных, добавляем MATERIALIZED колонку. она заполнится для старых данных в момент альтера?
мне показалось или я гдето видел что это поле заполняется если его нет - только в момент обращения

нет. Заполнится при мержах этих старых партов, при записи в новые.
ДЛЯ DEFAULT ПОЛЕЙ ТОЖЕ САМОЕ

При select MATERIALIZED колонка будет вычисляться на лету, rand() , now() будут каждый select новые
ДЛЯ DEFAULT ПОЛЕЙ ТОЖЕ САМОЕ

а зачем тогда MATERIALIZED колонка занимает гигабайты на диске?

разве DEFAULT выражения заполняются при merge ?
я думал различие в том что DEFAULT при background merge в колонку не сохрняются, а только заполняются при INSERT новых данных

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

Привет. Помогите пожалуйста разобраться в проблеме:

- Есть 2 шарда по 2 реплики
- Вресия серверов 21.1.2.15
- Шарды с internal_replication=true
- read_backoff_min_latency_ms = 0 на всех серверах
- Данные в данный момент не записывается, Background таски не выполняются
- В логах ошибок нет

Делаю запрос:
SELECT uniqExact(id) FROM v1_comments.comments PREWHERE date = toDate('2021-01-26');

Получаю разные ответы
┌─uniqExact(id)─┐
│        903265 │
└───────────────┘

┌─uniqExact(id)─┐
│        661869 │
└───────────────┘

SELECT uniqExact(id) FROM v1_comments.local_comments PREWHERE date = toDate('2021-01-26');
на первом шарде
┌─uniqExact(id)─┐
│        661869 │
└───────────────┘

На другом шарде этот же запрос
┌─uniqExact(id)─┐
│        241396 │
└───────────────┘

Структура таблиц

CREATE TABLE IF NOT EXISTS v1_comments.local_comments
   ON CLUSTER test_cluster
(
   date   Date,
   id     UInt64,
   comment String,
   volume UInt32
)
   ENGINE = ReplicatedMergeTree(
            '/clickhouse/clusters/{cluster}/tables/{shard}/v1_comments/local_comments',
            '{replica}')
       PARTITION BY toYYYYMMDD(date)
       ORDER BY id
       SETTINGS index_granularity = 8192;


CREATE TABLE IF NOT EXISTS v1_comments.comments
   ON CLUSTER test_cluster
(
   date   Date,
   id     UInt64,
   comment String,
   volume UInt32
)
   ENGINE Distributed(test_cluster, v1_comments, local_comments,
          intHash64(id));

смотрите, есть такая штука DEFAULT
она ИНОГДА не удобна что ломает существующие insert-ы (insert into без перечисления полей)
добавили MATERIALIZED чтобы не ломать insert-ы, но все поведение как у DEFAULT
все. конец сказки.

Посмотрите еще ALIAS

для MATERIALIZED в SELECT для тех данных которые материализовались (при вставке или при Merge) данные будут выбираться без рассчета, а там где данные отсутсвуют расчет пойдет на лету

select * from system.macros с обоих хостов?

а есть где нить в документации подробное описание как это работает? ничего толком не могу найти

Всем привет. В документации по буферным таблицам говорят, что During the read operation, data is read from the buffer and the other table simultaneously. но на самом деле это не так, основная таблица отстает от буфера на размер максимального тайм-аута для сброса. Это я что-то неправильно готовлю, или документация непроапдейчена? Версия самая последняя из апт-гета, 21.1.2.15, то же самое было на 20.9....