Всем привет. Кто-то использует вот такой бутстрап схем/таблиц в кликхаус

в кубере?
https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/02-templates-06-bootstrap-schema.yaml
Я добавляю такую конфиг мапу и это работает нестабильно. То есть нужные схемы и таблицы я вижу далеко не всегда. Экспериментным путем вижу, что вроде схемы и таблицы появляются только если разворачиваешь новый кластер без зуукипера и с одной репликой. И то не уверен, что это стабильный результат.
Видел, что советовали добавить в конфигурацию вот такой блок:
livenessProbe:
httpGet:
port: "8123"
path: "/ping"
failureThreshold: 3
initialDelaySeconds: 180
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
мне не помогает

если shell скрипт из initdb.d вернет exit code не нулевой , то entrypoint.sh прекратит исполнение и не запустит clickhouse-server логи контейнера с clickhouse-server проверьте самое начало там нет ClickHouse init process failed. ? можете для pod сделать kubectl get pod -n <namespace> <pod-name> -o yaml и выложить на pastila.nl?

о. в 23.10 добавили еще неприятный момент такая схема только один раз активируется пока в /var/lib/clickhouse/ маунте не будет папки data если есть. то уже нет но возможно он вас не аффектит...

вроде в логе ничего не видел. Посмотрю еще раз. Пробую на 23.8.4 и 23.8.5

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

в качестве скриптов инициализации схемы что используете? .sh или .sql ? всякие там CREATE DATABASE IF NOT EXISTS и т.п. Штуки делаете? вообще оператор сам провижен схемы делает для Distributed + Replicated Таблиц при добавлении новых реплик \ шардов...

не сработает только если clickhouse-server 23.10 и выше... для старых версий ок...

использую sh, как в этом примере: https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/02-templates-06-bootstrap-schema.yaml

да, CREATE DATABASES в 01_create_databases.sh и TABLES в 02_create_table.sh

понял

а как это в операторе? Та же configMap, только вместо sh sql файл?

да, почитайте как entrypoint.sh работает https://github.com/ClickHouse/ClickHouse/blame/master/docker/server/entrypoint.sh#L151-L166

спасибо большое, вроде да, та же логика. Попробую

а еще вопрос к этой теме: я могу использовать несколько configmap? каждая для своего кластера? или даже 2 мапы для одного кластера?

две ConfigMap можно но замаетесь IMHO пример тут https://www.perplexity.ai/search/kubernetes-how-to-FTumsACbSPOjS7OO8FNKnA?s=c для каждого кластера разное только если будете определять podTemplate разные для разных кластеров podTemplate можно и для реплики и для шарда переопределить только IMHO вам в эти дебри лезть не стоит. вы сначала разберитесь с текущим configmap что не так по логам

да, конечно, стоит решить текущие проблемы. Просто планируется несколько кластеров: cluster per product. И планировал использовать отдельный configmap для каждого кластера. И еще думал, что если у меня есть отличия в схеме между prod and staging, то можно было бы сделать отдельную configmap для staging. В таком случае, у меня получилось бы в configmaps for 1 cluster

ну вы все кластера внутри одного CHI хотите управлять? лучше в разных 1 cluster - 1 chi так проще манифесты обновлять чтобы изменения манифестов одного кластера по минимуму аффектили другие но тут уже сильно зависит от того как вы манифесты вообще раскатываете...

Раскатываю через argocd. То есть в репозитории у меня стандартная структура: директории base и envs(а внутри prod, staging…) И мне хотелось для нового кластера просто добавлять новый yaml в этот же репо. Делать отдельный репозиторий под каждый продукт…хотелось бы избежать этого наверное

Здравствуйте. Просто хотел поблагодарить за помощь и сказать о результатах: - замена sh -> sql ничего не дало. - помогли эксперименты с версией кликхауса. - в 23.8.4.69 и 23.8.5.16 просто не работает, и в логе пусто, никаких упоминаний "entrypoint.sh" и т.п. Как только перешел на 23.8.3.48, так сразу появилась в логе информация. И все заработало в итоге - Если пытаешься добавить создание еще одной таблицы, то оператор поду не рестартует и изменения не появляются. Но если вручную рестартонуть поду, то изменения появляются

так оператор ваш сторонний configmap не отслеживает, надо менять spec.taskID ручками после замены configmap + 1 минута ожидания пока он раскатится

оператор следи только за изменениями в ресурсах kind: ClickHouseInstallation из них делает statefulset все остальное внутренняя механика kubernetes ну еще в последних версиях оператор PVC сам создает и к statefulset подключает но это отключено по умолчанию

чего ее искать тут оно все kubectl explain chi.spec.taskID kubectl explain chi.spec

спасибо) просто не пользовался раньше)