Данные в плане содержимое инсерта

ну нету инверсных индексов

да, спасибо, сейчас дату захаркодил и действительно - дубликата нету. всё детально ясно. Спасибо.

остался один вопрос - зачем в доке про circular replication упомянуто, что он internal_replication очень нужен для circular вообще

1. on cluster смотрит на этот ключ, чтобы правильно рассылать add columns
2. на самом деле из-за дедупликации инсертов дубликаты из-за двойной записи в обе реплики схватить тяжело

я активно работаю circular-replication-cluster-topology-in-clickhouse над выпиливаем этой статьи, пришлось даже в Альтинити усроится

ничего скоро будет праздник, уничтожим вражину.

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

если таблицы replicated то надо ставить internal_replication>true
чтобы правильно работал on cluster

и чтобы не плодить дубликаты при записи через distributed

можно ли вывод сделать:
1) что в конкретно той схеме упоминание internal_replication имеет такое же значение как на любой другой схеме?

да

2) которые, как я вот понял по верхнему обсуждению, всё равно поймать не просто, но теоретически возможно

=)) там же ещё одна была, которая
её тоже надо бы...
https://medium.com/@merticariug/distributed-clickhouse-configuration-d412c211687c

реплика2 выключена или потеряла сеть.
distributed посылает в реплику1, реплику2 и реплику3 одно и тоже
реплика1 вставляет и пишет в зукипер контрольную сумму блока.
реплика3 проверяет что блок уже есть в зукипере (в ста последних) и не вставляет и скачивает новый парт с реплика1
через минуту сеть восстановилась
реплика2 проверяет что блока нет в зукипере (в ста последних)  вставляет и скачивает новый парт с реплика1
рассылает вставленное на реплику1 и реплику3 через репликацию -- insert умножился на два

просто там вот прямо коммент и текст от альтинити, который звучит как "да, для circular обязателен internal_replication", что меня смутило куда больше чем вся остальная статья. как бы вообще необходимость internal_replication я не оспариваю, но просто я  именно такая подача смутила

эти статью писали давно, еще не было четкого понимания, и документации толком не было

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

Кстати, пока тут читаю вашу дискуссию, созрел вопрос, который хочется уточнить: ведь по логике вещей при включенном internal_replication вощможна ли chained replication?

проблема сейчас что если гуглить how to configurate cl cluster , найдешь эту статью и сконфигуришь, хотя и не хотел

мы все еще про кликхауз? а то там нет такого понятия

В кх нет, да, это я помню. Я имею в виду (возможно я неправильно употребляю термин chained replication) возможность когда из реплики1 данные (которые распределились из Distributed) реплицируются на реплику2, а из реплики2 в реплику3.
Возможно в теории так можно, но поправьте меня пжл если это не так D: