У меня как будто глупый вопрос по clickhouse-operator, но что-то

не получается настроить.

Есть 6 серверов КХ, для которых настроено несколько кластеров:
1. 1 кластер на 1 шард из 6 реплик
2. 1 кластер на 3 шарда из 2 реплик каждый
3. 3 кластера на 1 шард из 2 реплик на каждом

И вот теперь хотим добавить макрос, который будет указывать номер реплики во втором кластере. Грубо говоря, аналог запроса
select replica_num from system.clusters where is_local and cluster='second_cluster_name'
но только чтобы не запросом его каждый раз вытягивать, а через getMacro()

Быть может есть где-то дока или пример для реализации такой штуки через КХ-оператор? А то у коллег пока получается только на все ноды одно и то же значение раскатывать.

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

номер шарда итак есть {shard} он оператором автоматом генерится

Для шардирования при вычитке кафка-движком. Номер шарда-то генерится, но там номер шарда не из того кластера, что мне нужен. Один и тот же сервер в зависимости от выбранного кластера принадлежит к разным шардам и имеет внутри шарда разный номер реплики.

я правльно понял, что вы внутри chi сделали 3 clusters?

что-то все равно не сходится {shard} разный для разных кластеров и должен быть правильный ... кластера то разные statefulset поднимать будут ... просто они на одних и тех же k8s worker nodes шедулиться должны

Не понял этот вопрос. Вот те три кластера, о которых я говорил, для одного сервера: SELECT c.cluster, c.shard_num, c.replica_num, getMacro('shard') AS m1, getMacro('replica') AS m2 FROM system.clusters AS c WHERE c.is_local FORMAT Vertical Row 1: ────── cluster: all-replicated shard_num: 1 replica_num: 5 m1: 4 m2: chi-clickhouse-replicated-4-0 Row 2: ────── cluster: fdp-cluster shard_num: 2 replica_num: 2 m1: 4 m2: chi-clickhouse-replicated-4-0 Row 3: ────── cluster: fdp-cluster-shard2 shard_num: 1 replica_num: 2 m1: 4 m2: chi-clickhouse-replicated-4-0 В случае с номером шарда я хочу получать макросом значение 2, которое равно shard_num для кластера fdp-cluster. А получаю 4, которое является даже не номером шарда из другого кластера, как я изначально думал, а частью названия реплики. А в случае с номером реплики для этого сервера - тоже значение 2, которое равно replica_num для кластера fdp-cluster.

как вы кластера внутри chi задаете? kubectl get chi -n <namespace> <chi_name> -o yaml расшарьте

на тот chi_name, что я использую для запуска clickhouse-client, ругается, мол, не найден, а других я не знаю уточню у коллег и пришлю

https://pastila.nl/?0035d347/4fbfff8a9fb555d2a09eedb49a3da0b9 Тот кластер, номер шарда и реплики в котором я хочу получать макросом, заведён в custom_clusters.xml.

kubectl get chi --all-namespaces

@BloodJazMan я вот тут конфиг выгрузил, который вы просили. Можете глянуть?

понятно, вы remote_servers напрямую задаете, непонятно зачем вам там такой странный hostTemplate, ну видимо нужен был зачем то не ясно как оно с такой настройкой вообще взлетело в общем в вашем случае можно обойти через runtime если через xpath получить номер ноды из текущего hostName у вас кластер fdp-cluster имеет ДВА шарда по ДВЕ реплики... а вы думаете что у вас там три шарда по две реплики вы по моему не понимаете для чего кластера в remote_servers служат не очень понятно что именно вы хотите шардировать? Engine=Kafka сам по себе ничего не шардирует. у него только consumer_group есть если у вас там MV который в фоне читает из Engine=Kafka то он может писать в соответсвующую Engine=Distributed Таблицу которая уже будет делать шардирование в MergeTree просто по имени кластера короче если в ваш кастомный образ с приватного регистри добавить apt-get install libxml2-utils то можно сделать так spec: configuration: files: config.d/custom_clusters.xml: | <!-- важно поместить в config.d чтобы configmap не создавал ничего для conf.d и можно было в рантайме поменять --> podTemplates: - name: clickhouse spec: containers: - image: [DATA EXPUNGED]/clickhouse-server:21.11.4.1 name: clickhouse-pod command: | echo '<yandex><macros><custom_replica>' > /etc/clickhouse-server/conf.d/custom_macros.xml && \ xmllint --xpath "count(/yandex/remote_servers/fdp-cluster/shard/replica[host='$( hostname | sed 's/\-0$//g')']/preceding-sibling::replica)" >> /etc/clickhouse-server/conf.d/custom_macros.xml echo '</custom_replica></yandex>' >> /etc/clickhouse-server/conf.d/custom_macros.xml && \ clickhouse-server --config=/etc/clickhouse-server/config.xml но мне кажется это знание для вас бесполезно

Спасибо. Да, я этот конфиг сам впервые увидел и не знаю почему настроено именно так. Ваш рецепт пока не понимаю, но передам коллегам и погуглю. От варианта с записью в distributed отказались, т.к. парты сначала пишутся на локальный диск, а затем передаются по сети. С учётом использования медленных дисков это даёт дополнительную нагрузку, которая иногда бывает критичной, поэтому решили читать со всех шардов параллельно, но на разных шардах в MV отфильтровывать только нужные записи по тому же условию, что и в ключе шардирования.

а как вы тогда "шардируете"? и что под этим подразумеваете? у вас ReplicatedMegreTree с разными zookeeper path на разных серверах должны создаваться или что? тогда они между собой ничего реплицировать не будут...

На одном шарде путь ('/clickhouse/fdp/Events_local/shard1', '{replica}'), на втором - ('/clickhouse/fdp/Events_local/shard2', '{replica}'). В Distributed таблице ключ партиционирования - условный TimeKey, в MV на одном шарде фильтруются события по TimeKey % 2 = 0, на другом - TimeKey % 2 = 1.

погодите, а если вы в MV фильтруете события... откуда тогда уверенность что все данные из kafka вставлись? из того что вы описываете, если у вас одинаковая consumer_group на всех шардах вы просто теряете часть данных вычитывая их из kafka и никуда не вставляя...

Не, консьюмер группы разные