Комментарии 16
Теперь давайте рассмотрим сценарий падения мастера
Это не сценарий падения. Это сценарий ручного файловера у вас получился. Запустите продакшен лайк нагрузку и кильните с помощью kill -9 процесс postgres. Что выйдет? Или оборовите сетку между активной нодой и repmgr. Не получится ли split mind?
Запустите продакшен лайк нагрузку и кильните с помощью kill -9 процесс postgres. Что выйдет?
Тут всё нормально, выйдет как и в статье, проверяли. Но вы совершенно правы, проверять такой сценарий перед релизом в прод надо обязательно.
Или оборовите сетку между активной нодой и repmgr. Не получится ли split mind?
Так это проблема нескольких слейвов, статья то не об этом. А проблема эта решается witness сервером.
Вот не знаю, как реагировать.
Т.е., Pgpool или классический скрипт свитчовера — это неверный путь, Pgpool — это, значит, комбайн, все в одном, а Докер — нет?
Думаю, от докера оверхеда больше. Да еще и ssh в контейнерах. Тем более, балансировку вы сделали на стороне приложения.
Зачем все это?
Разложить конфиги по серверам можно Ансиблом, либо его аналогом, бэкапы тоже обычным скриптом из крона можно делать
Т.е., Pgpool или классический скрипт свитчовера — это неверный путь, Pgpool — это, значит, комбайн, все в одном, а Докер — нет?
Думаю, от докера оверхеда больше. Да еще и ssh в контейнерах. Тем более, балансировку вы сделали на стороне приложения.
Зачем все это?
Разложить конфиги по серверам можно Ансиблом, либо его аналогом, бэкапы тоже обычным скриптом из крона можно делать
Спасибо, хороший комментарий.
Докер тут используется как упаковщик софта, он не имеет отношения к самой репликации кластера, поэтому головной боли меньше.
Можно, а можно еще как то, не суть, преследовалась цель быстро развернуть постгрес кластер, будь то локалка, стейдж или прод. Сделать готовый темплейт в котором можно просто что то поменять, локально протестировать и сразу в бой. Во вторых нормальных готовых к употреблению готовых конфигураций просто нет, поэтому пришлось сделать своё.
Получился весьма рабочий вариант, чем и делюсь с сообществом. Решение имеет право на жизнь как и решения Ансиблом например.
Pgpool — это, значит, комбайн, все в одном, а Докер — нет?
Докер тут используется как упаковщик софта, он не имеет отношения к самой репликации кластера, поэтому головной боли меньше.
Зачем все это?
Разложить конфиги по серверам можно Ансиблом, либо его аналогом, бэкапы тоже обычным скриптом из крона можно делать
Можно, а можно еще как то, не суть, преследовалась цель быстро развернуть постгрес кластер, будь то локалка, стейдж или прод. Сделать готовый темплейт в котором можно просто что то поменять, локально протестировать и сразу в бой. Во вторых нормальных готовых к употреблению готовых конфигураций просто нет, поэтому пришлось сделать своё.
Получился весьма рабочий вариант, чем и делюсь с сообществом. Решение имеет право на жизнь как и решения Ансиблом например.
А если смоделировать такую ситуацию — потерялась связь между мастером и слейвом и слейв стал мастером. Таким образом мы получили два рабочих мастера, которые не знают друг о друге. Мы делаем ряд разных записей в одну таблицу в оба мастера. Далее связь восстановилась — как восстановить кластер?
Мы делаем ряд разных записей в одну таблицу в оба мастера.
В Вашей ситуации, при разрыве связи между мастером и слейвом, слейв станет мастером и поменяет failover IP на свой. Таким образом запись будет идти только в новый мастер.
Далее связь восстановилась — как восстановить кластер?
Так как написано в статье, сделать из упавшено мастера новый слейв и жить дальше.
stolon гораздо лучше своего велосипеда.
stolon — это ПО со своими багами и замарочками — то есть дополнительная точка отказа, а тут просто конструктор из минимального количества компонент, с которыми достаточно запустить высокодоступный кластер.
Странно, что с таким подходом вы к докеру пришли (как уже выше писали). Ну а stolon — тогда не одна точка отказа, там ещё и etcd/consul (проверенные временем и продакшеном).
Докер в этом контексте это просто упаковщик утилит и удобный их запуск, сеть используется хоста а не overlay, данные тоже хранятся на хосте, тот же столон запускают из под k8s или docker, просто потому что это удобно.
Я не до конца понял, где у вас хранятся данные. Прямо в файловой системе докера?
Странно видеть когда в докер пихают ssh (init.d и прочее), а потом спрашивают — какого ляда оно не работает? Докер — это контейнер для приложения (причем одного), а не виртуальная машина. Его задача упаковать приложение с зависимостями — а как этим управлять — задача хоста. А вообще как по мне держать бд в проде в докере — моветон. В деве или стейджах — ради бога.
Вы серьезно? :)
Запускать несколько процессов в одном контейнере это НЕ антипатерн, как хотите так и делаете, 1 процесс, 2, 3, 100, не важно. Всё нормально.
Это как? Управление контейнерами идет через докер.
Окей, но есть много тех кто успешно держит бд в продакшене, поищите хотя бы по хабру. Главное знать как его готовить, использовать сеть хоста и.т.д
Докер — это контейнер для приложения (причем одного), а не виртуальная машина.
Запускать несколько процессов в одном контейнере это НЕ антипатерн, как хотите так и делаете, 1 процесс, 2, 3, 100, не важно. Всё нормально.
а как этим управлять — задача хоста
Это как? Управление контейнерами идет через докер.
А вообще как по мне держать бд в проде в докере — моветон.
Окей, но есть много тех кто успешно держит бд в продакшене, поищите хотя бы по хабру. Главное знать как его готовить, использовать сеть хоста и.т.д
Не могу не поддержать. У меня тут под боком продовый master-slave mysql и mongo в докере (поднимал не я, я знаю что такое docker stateless). При нормальной боевой нагрузке эти штуки ведут себя крайне интересно, хочется взять и разломать всё к чертям =).
А вообще как по мне держать бд в проде в докере — моветон.
Кто вам сказал? Depends on, как и всегда. При использовании bind mount ничего страшного не происходит, а netns и прочие позволяют более-менее унифицировать конфигурации, безболезненно тестировать миграцию на новые версии БД и т. п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Докеризация высокодоступного Postgres кластера