Хотя бы не ломая селекты
апгрейдится либо напрямую как делают все либо прыгать по lts, как делают те кому реально надо, не ломать клиентов не факт кстати что ваше приложение заработает с новой версией
Т.е. постапгрейдных работ никаких в ch не делается, судя по сказанному?
Спасибо за информацию. На dev погоняем
обновил образ ch до 23.3.8.21-alpine. Он всё равно при старте в 1 реплику байндит 127.0.0.1 и валит readiness-пробу. Когда запускаю вторую реплику, она уже биндит 0.0.0.0. Первая перезапускается и тоже биндит 0.0.0.0. Проблема видимо где-то в шаблонах не могу понять
шаблоне чего? там pod из statefulset создается по шаблону... они одинаковые должны быть... и listen_host 0.0.0.0 вообще в docker_related_config.xml прописан
Так в том и дело, вроде ни sts, ни конфигмапы не меняются, но если реплика стартует одна, то сначала сыпет DNS_ERROR на недоступную вторую реплику, затем стартует на 127.0.0.1
ну зайдите через shell во время старта посмотрите на /var/lib/clickhouse/preprocessed_configs.xml и grep 0.0.0.0 -r /etc/clickhouse-server/ сделайте
cat: can't open '/var/lib/clickhouse/preprocessed_configs.xml': No such file or directory значит ли это что у меня слишком старая версия оператора?
/var/lib/clickhouse/preprocessed_configs/config.xml
в нем listen_host верный
а дата модификации позже сообщения о listen_host 127.0.0.1 в логах?
в лс
volumeMounts: - mountPath: /docker-entrypoint-initdb.d name: bootstrap-configmap-volume при старте обработки docker-entrypoint-initdb.d стартует с listen_host 127.0.0.1 принудительно если у вас долго схема накатывается тогда сделайте livenessProbe initialPeriodSeconds: 180 spec: containers: - name: clickhouse livenessProbe: httpGet: port: "8123" path: "/ping" failureThreshold: 3 initialDelaySeconds: 180 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10 вообще оператор сам не плохо реплицирует схему ... при scaleout scaleup я бы сделал накатывание схемы отдельным kind: Job в котором бы сначала состояние кластера поллил...
https://github.com/ClickHouse/ClickHouse/blob/master/docker/server/entrypoint.sh#L119
это может быть долго и фейлиться ... потому что не все реплики еще стартанули...
там 180 секунд дается на то чтобы остальные реплики из ZK сполили ваш запрос и запустили... а они еще не стартанули...
точно, ON CLUSTER же
лучше убрать ON CLUSTER тут тогда
куда б тогда убрать создание базы
Обсуждают сегодня