Как стать автором
Обновить

Комментарии 2

Если после исключения ноды из кластера вернуть её обратно командой docker service scale $patroni2-id=1, то наблюдается следующий эффект:
— команда patronictl -c /etc/patroni.yml list patroni показывает что она в кластере, но по факту в репликацию эта нода не встала, в логах постгреса наблюдается ошибка репликации. Это лечится путем удаление содержимого каталога кластера. После этого этот каталог восстанавливается с мастера и репликация налаживается.
— сервис haproxy, даже после восстановлении нормальной репликации, не может соединится с этой нодой и соответственно при очередном файрволе, даже если патрони переключится на новый мастер, доступа через haproxy к базе не будет. Как это лечится не понятно.

Вывод: пока не совсем надежна эта конфигурация в среде docker swarm.

Я понимаю, что вы использовали инструмент, который знаете, но Docker Swarm всё же не рабочий и мертвый для Production инструмент, не нужно использовать его для такого.

Чтобы сэкономить время и ничего не поднимать локально есть managed Kubernetes кластеры, для которых к тому же в первую очередь и пишут самые популярные Helm чарты, т.к. сейчас всё в облаках. Например https://github.com/zalando/postgres-operator/tree/master/charts/postgres-operator

Хотя там же и пример с нормальным локальным инструментом k3D тоже есть.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий