Как забытый ON CLUSTER поставил меня в тупик
Я создала таблицу ReplicatedReplacingMergeTree, потом переделала на обычный ReplicatedMergeTree. Дропнула таблицы, но тупо забыла ON CLUSTER, и вот что из этого вышло
🫤 Запускаю загрузку, она падает, я чищу табличку и гружу заново. Казалось бы, проблемы больше нет? Сверяюсь по каунтам - сильно отличается. Снова перезагружаю - вообще другие каунты стали. Что происходит? Смотрю инфу по репликам:
SELECT hostName(), pid, count()
FROM clusterAllReplicas('default', schema.table)
GROUP BY hostName(), pid
ORDER BY pid, hostName();
На двух хостах сходится, на третьем сильно меньше данных и вообще нет большого куска, при этом все цифры разъезжаются с источником…
Я делаю truncate - а с третьего хоста данные вообще не удаляются. Делаю truncate sync - снова ничего не происходит. SYSTEM SYNC REPLICA schema.table - то же самое
🤔 Иишка советует заглянуть в system.distributed_ddl_queue - но там все Finished. Потом смотрю zookeeper_path:
SELECT
hostName(),
zookeeper_path,
total_replicas,
active_replicas,
last_queue_update_exception
FROM clusterAllReplicas('default', system.replicas)
WHERE database = 'schema'
AND table = 'table';
Первые 2 хоста в одной репликационной группе:
/clickhouse/tables/9e0fe594-04f6-41ad-8137-385f08c2fbe5/shard1
total_replicas = 2
А третья живет отдельно:
/clickhouse/tables/faee8477-d2a6-47c9-8cc9-8a3f44972612/shard1
total_replicas = 1
Дальше смотрю DDL на разных хостах:
SELECT hostName(), create_table_query
FROM clusterAllReplicas('default', system.tables)
WHERE database = 'schema'
AND name = 'table';
Первые две - ReplicatedReplacingMergeTree
Третья - ReplicatedMergeTree
Поверх этих таблиц еще была Distributed, а она читает табличку на основе параметра load_balancing:
SELECT value
FROM system.settings
WHERE name = 'load_balancing';
В моем случае там был random, и он постоянно возвращал данные с третьей реплики (кроме random, есть еще несколько)
А почему данных на третьей реплике было меньше? Все еще помните про самый первый процесс, который упал? Так вот он записал кусок данных, но почистить их кх уже не смог. А при следующем запуске запись пошла в другую реплику
В общем, два забытых слова привели к тотальной смеси двух миров
@data_engineerette
Я создала таблицу ReplicatedReplacingMergeTree, потом переделала на обычный ReplicatedMergeTree. Дропнула таблицы, но тупо забыла ON CLUSTER, и вот что из этого вышло
🫤 Запускаю загрузку, она падает, я чищу табличку и гружу заново. Казалось бы, проблемы больше нет? Сверяюсь по каунтам - сильно отличается. Снова перезагружаю - вообще другие каунты стали. Что происходит? Смотрю инфу по репликам:
SELECT hostName(), pid, count()
FROM clusterAllReplicas('default', schema.table)
GROUP BY hostName(), pid
ORDER BY pid, hostName();
На двух хостах сходится, на третьем сильно меньше данных и вообще нет большого куска, при этом все цифры разъезжаются с источником…
Я делаю truncate - а с третьего хоста данные вообще не удаляются. Делаю truncate sync - снова ничего не происходит. SYSTEM SYNC REPLICA schema.table - то же самое
🤔 Иишка советует заглянуть в system.distributed_ddl_queue - но там все Finished. Потом смотрю zookeeper_path:
SELECT
hostName(),
zookeeper_path,
total_replicas,
active_replicas,
last_queue_update_exception
FROM clusterAllReplicas('default', system.replicas)
WHERE database = 'schema'
AND table = 'table';
Первые 2 хоста в одной репликационной группе:
/clickhouse/tables/9e0fe594-04f6-41ad-8137-385f08c2fbe5/shard1
total_replicas = 2
А третья живет отдельно:
/clickhouse/tables/faee8477-d2a6-47c9-8cc9-8a3f44972612/shard1
total_replicas = 1
Дальше смотрю DDL на разных хостах:
SELECT hostName(), create_table_query
FROM clusterAllReplicas('default', system.tables)
WHERE database = 'schema'
AND name = 'table';
Первые две - ReplicatedReplacingMergeTree
Третья - ReplicatedMergeTree
Поверх этих таблиц еще была Distributed, а она читает табличку на основе параметра load_balancing:
SELECT value
FROM system.settings
WHERE name = 'load_balancing';
В моем случае там был random, и он постоянно возвращал данные с третьей реплики (кроме random, есть еще несколько)
А почему данных на третьей реплике было меньше? Все еще помните про самый первый процесс, который упал? Так вот он записал кусок данных, но почистить их кх уже не смог. А при следующем запуске запись пошла в другую реплику
В общем, два забытых слова привели к тотальной смеси двух миров
@data_engineerette