какой у таблицы index-granularity, и какой GRANULARITY skipping-indexa before/after

смотрите лог ноды где идет вставка в distiruted Таблицу
проверяйте коннекты между нодами (отвалилась авторизация например)
проверьте секцию remote_servers везде
не изменилась ли она

без логов ничего же не  понять, у вас Distriubuted таблица не может вставить ни в какую реплику

SELECT из distriubted таблицы тоже данные не находит?

и не должен

CREATE TABLE test_table (
  `childId` LowCardinality(String),
  `parentId` LowCardinality(String),
  `views` Int64,
  `clicks` Int64,
  `startedAt` DateTime,
  `finishedAt` DateTime,
  `isLive` UInt8,
  `isAdult` UInt8,
  `language` String,
INDEX parentId_set_index channelId TYPE set(512) GRANULARITY 512
) ENGINE = ReplacingMergeTree() PARTITION BY substring(parentId, 1, 2)
ORDER BY
  (childId, parentId) SETTINGS index_granularity = 512

ну, у вас данные отсортированы в childId, parentId - в целом полезно вешать skip index на не-первые колонки в ПК, это помогает

но это не поможет вам с другими колонками

CREATE TABLE test_table (
  `childId` LowCardinality(String),
  `parentId` LowCardinality(String),
  `views` Int64,
  `clicks` Int64,
  `startedAt` DateTime,
  `finishedAt` DateTime,
  `isLive` UInt8,
  `isAdult` UInt8,
  `language` String,
INDEX parentId_set_index channelId TYPE set(512) GRANULARITY 512
) ENGINE = ReplacingMergeTree() PARTITION BY substring(parentId, 1, 2)
ORDER BY
  (childId, parentId) SETTINGS index_granularity = 512

а КХ тут при чем? КХ это OLAP

ну вдруг =) у них не все ноды отвалились ? ;)

поэтому и спрашивал про дублирвание данных 🙂

у них distriubted таблица не может в шарды вставить, все инсерты успешные! лежат в distriubted

ну дублируйте, если других баз под рукой нет =)

да понятно, что кх вообще не для этих задач от слова совсем
но уже менять поздно

ну забивайте гвозди тапком

Сейчас, судя по логам, идет вставка в реплики, в которых была ошибка 25 числа " Retention.Events_Local (ReplicatedMergeTreeRestartingThread): Couldn't start replication: Replica /clickhouse/tables/1-2/Events_Local/replicas/1 appears to be already active. " Но данные вставляются старые, которые от 25 и 26 числа должны были вставиться (очень похоже на то, как будто данные в очереди). Каждая нода в кластере имеет сейчас 2 реплики, так вот данных за сегодня нет ни на одной из реплик.

@den_crane вот данные из replication_queue

SELECT *
FROM system.replication_queue
FORMAT Vertical

Row 1:
──────
database:               Retention
table:                  Events_Local
replica_name:           1
position:               0
node_name:              queue-0024376663
type:                   GET_PART
create_time:            2020-07-27 13:10:52
required_quorum:        0
source_replica:         2
new_part_name:          202007_13383003_13383003_0
parts_to_merge:         []
is_detach:              0
is_currently_executing: 1
num_tries:              1
last_exception:        
last_attempt_time:      2020-07-27 13:10:52
num_postponed:          0
postpone_reason:        
last_postpone_time:     0000-00-00 00:00:00

Row 2:
──────
database:               Retention
table:                  Events_Local
replica_name:           1
position:               1
node_name:              queue-0024376664
type:                   GET_PART
create_time:            2020-07-27 13:10:52
required_quorum:        0
source_replica:         2
new_part_name:          202007_13383004_13383004_0
parts_to_merge:         []
is_detach:              0
is_currently_executing: 1
num_tries:              1
last_exception:        
last_attempt_time:      2020-07-27 13:10:52
num_postponed:          0
postpone_reason:        
last_postpone_time:     0000-00-00 00:00:00

Row 3:
──────
database:               Retention
table:                  Events_Local
replica_name:           1
position:               2
node_name:              queue-0024376665
type:                   GET_PART
create_time:            2020-07-27 13:10:52
required_quorum:        0
source_replica:         2
new_part_name:          202007_13383005_13383005_0
parts_to_merge:         []
is_detach:              0
is_currently_executing: 1
num_tries:              1
last_exception:        
last_attempt_time:      2020-07-27 13:10:52
num_postponed:          0
postpone_reason:        
last_postpone_time:     0000-00-00 00:00:00

3 rows in set. Elapsed: 0.006 sec.

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

@den_crane получается надо увеличиввавть кол-во ядер, поолучается сделать 16x2 и посмотреть какая будет производительность

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