Я бы не сказал что это монстр по сравнению с тем, что описано в этой статье :)
Он не привязан к etcd. Можно выбрать еще consul или zookeeper. А версия etcd 3.0 вышла пару месяцев назад, так что etcd 2.3 не древняя.
Для работы на amazon они сделали Spilo построенный на patroni. Но у нас Azure, и мы спокойно запустили в Azure.
Для решения проблем запуска в какой ОС, мы использовали Docker. Делали Dockerfile на базе postgres, в котором устанавливался patroni. Возможно можно запустить patroni (в Docker) вообще отдельно от postgres (на Host), не пробовал. К контейнеру монтируем папку с бд на машине и нормальная работа.
Наверняка если есть какая то специфика (БД больше 10 Гб к примеру) это решение может не подойдет. Но мне кажется это хороший способ запуска кластера HA AF PostgreSQL.
Я не уверен в том что проблема Split Braint решена :)
Отвечает за выбор мастера — Witness. Честно не искал информацию по поводу него (игры в Steam на первой странице Google :) ) и не могу ничего сказать, но вы выделяете целую ноду для него. А если эта нода упадет и паралелльно упадет мастер? Что тогда делать?
Для этого требуется хранить данные о мастере распределенно — для этого используются etcd, zookeeper, consul. Вы ставите каждый элемент данной систем на каждую ноду и у вас кластер хранения конфигурации. Благодаря этой системе существует кворум требуемый для выбора мастера.
А в вашей конфигурации может случится, что мастер просто потеряет связть с другими (частью) слейвами и Witness и начнется переконфигурирование кластера.
Я думаю вам понравится Patroni, потому что это как надстройка над Postgres, управляющая всеми этими скриптами копирования.
Они решают проблему хранения информации и выбора мастера за счет etcd.
Они только не сделали поддержку слейв сервера, на которого нельзя переключать мастер, но вроде уже начинают делать.
Тестировали у себя 1 месяц, а потом перешли в продакшн на эту систему. Полет хороший :)
Спасибо за статью!
Не смотрели в сторону Patroni от Zalando?
Они как раз таки решают на базе etcd проблему split brain и автоматического failover.
В презентации указывали что у них сотни серверов работают через эту систему.
Скажите пожалуйста, а что с данными PostgreSQL при ребилдинге? Стоит ли вообще запускать PostgreSQL в контейнере, так как непонятно где и как хранятся данные? А как дела с бекапом, репликами и HA?
А были ли какие нибудь проблемы? Что происходит в случае падения слейва? Маратон поднимает их на других слейвах?
Смотрели в сторону kubernetes?
Имел неприятный опыт от попытки использования Маратона. В azure есть шаблон Mesos+Marathon, которые поднимает машинки и устаналивает. Попытался поднимать контейнеры в Маратоне, ничего не происходило к сожалению.
Моя история:
В 2014 году случился крах турфирм. Я думал что мой турагент нормальный (Атлас Трэвел с 1990 года работает) и меня это не коснется. За 1 день (август 2014) до вылета позвонили и сказали что турагент разорился и не перечислил 50% стоимость турфирме (Библио Глобус). Предложили или платите 50% и летите, или не платите и не летите. Отпуск срывать не хотелось, оплатил и полетел. По прилету начал гуглить по всей этим судебным делам.
Подал иск в начале октября 2014 я подал в суд на Атлас и Библио в мировой суд. Решение было вынесено только в июне 2015, так как судья очень часто требовались разные документы и бумажки для обоснования моей позиции, хотя достаточно было статьи из ФЗ о турфирмах и чеки об оплате.
Она вынесла решение не в мою пользу, посчитав что Библио не должен возвращать деньги.
Для подачи апелляции требуется знать почему судья отказал. Узнать это можно в мотивированном решении суда. Суд обязан по закону при письменном заявлении сделать его за… вроде 3 или 5 дней.
В июле я позвонил узнать сделали мне его или нет. В конце концов с прекрасными представителями судебного участка я общался до октября 2015 года, чтобы узнать когда мне выдадут его. Для ускорения выдачи писал в прокуратору, ВККС РФ, председателю суда. В итоге помог звонок какому то судье из районного суда.
В октябре 2015 года я подал апелляцию и в конце ноября 2015 года районный суд вынес решение в мою пользу. В декабре получил исполнительный лист и отправил по почте в Москву. В январе 2016 года началось исполнительное производство и закончилось только в апреле 2016 года.
Хроника:
сентябрь 2014 — подача заявления
июнь 2015 — решение в мировом суде
октябрь 2015 — получение мотивированной части
ноябрь 2015 — решение районного суда
декабрь 2015 — получение исполнительного листа
январь 2016 — возбуждение исполнительного производства
апреля 2016 — выплата денег
Итого 20 месяцев.
Судебная система РФ тупа и беспощадна. Слишком много бюрократии и безнаказанности судей.
Также юристы советуют обращаться не ФССП а напрямую в банк, в котором открыт счет юрлица. Они переведут деньги в течении 3 дней. ФССП делает это как минимум 3-4 месяца и это только если юрлицо не банкрот.
Мой совет:
Все фоткайте и фиксируйте. Делайте и храните копии всех документов возникающих в судебном процессе (особенно протоколов судебных заседаний). Требуйте соблюдения ваших прав. Нарушение любого процессуального действия в судебном процессе — повод отмены и пересмотра решения. На каждое нарушение — письмо в прокуратору, председателю суда и ВККС РФ.
Скажите пожалуйста, а как будет работать репликация и переключения master в slave при Azure Maintaince.
Azure Maintaince — это разовое отключение машин (до 30 минут) в произвольное время в произвольном порядке в течении 72 часов.
Ситуация такая:
Есть сервер A (Master) и сервер B (Slave):
1. Произошел Azure Maintaince
2. Отключился сервер A
3. B стал Master
4. A поднялся и он считает, что он Master
5. B отключился
6. B поднялся заново, но он все еще Master.
4 шаг — как сделать так чтобы A стал работать как Slave?
5 шаг — как сделать так чтобы A стал работать как Master?
6 шаг — как сделать так чтобы B стал обратно Slave?
Система балансировки и переключения — PgPool, однако в условиях Azure Maintaince он некорректно отрабатывает, так как запущен в 2 экземплярах. В документации написано, что не следует его запускать в более чем 1 экземпляре. Он может некорректно переключать систему из Master в Slave.
Единственный вариант как я рассматривал это Pacemaker, однако руки до него не дошли.
Как раз таки такого я и добился, но это критично при Azure Maintance. Машины выключаются/включаются с перерывом в 30 минут и это происходит в течении 3 суток. То есть неизвестно в какой именно момент времени это произойдет. Вы можете спать, а машины в этот момент могут перезагрузиться и вы просто не успеете ничего сделать.
А кто может поделиться опытом построения High Avaibility (99,9% — 99,99%) PostgreSQL в условиях Azure Maintance, когда машины сами включаются и выключаются попеременно?
Рассматривал вариант с PgPool, но в нем была проблема в том, что при выключении мастера и его восстановлении, он не знал о том, что другая машина стала мастером. PgPool некорректно работал одновременно на 2 машинах. Да и честно как то это костыльно выглядело.
Можете скинуть, но я к сожалению уже больше не поддерживаю данный репозиторий :)
https://github.com/lastbackend/devops-patroni
Но patroni уже ускакал вперед на сотню коммитов, поэтому может быть что нибудь изменилось.
Он не привязан к etcd. Можно выбрать еще consul или zookeeper. А версия etcd 3.0 вышла пару месяцев назад, так что etcd 2.3 не древняя.
Для работы на amazon они сделали Spilo построенный на patroni. Но у нас Azure, и мы спокойно запустили в Azure.
Для решения проблем запуска в какой ОС, мы использовали Docker. Делали Dockerfile на базе postgres, в котором устанавливался patroni. Возможно можно запустить patroni (в Docker) вообще отдельно от postgres (на Host), не пробовал. К контейнеру монтируем папку с бд на машине и нормальная работа.
Наверняка если есть какая то специфика (БД больше 10 Гб к примеру) это решение может не подойдет. Но мне кажется это хороший способ запуска кластера HA AF PostgreSQL.
Отвечает за выбор мастера — Witness. Честно не искал информацию по поводу него (игры в Steam на первой странице Google :) ) и не могу ничего сказать, но вы выделяете целую ноду для него. А если эта нода упадет и паралелльно упадет мастер? Что тогда делать?
Для этого требуется хранить данные о мастере распределенно — для этого используются etcd, zookeeper, consul. Вы ставите каждый элемент данной систем на каждую ноду и у вас кластер хранения конфигурации. Благодаря этой системе существует кворум требуемый для выбора мастера.
А в вашей конфигурации может случится, что мастер просто потеряет связть с другими (частью) слейвами и Witness и начнется переконфигурирование кластера.
Я думаю вам понравится Patroni, потому что это как надстройка над Postgres, управляющая всеми этими скриптами копирования.
Они решают проблему хранения информации и выбора мастера за счет etcd.
Они только не сделали поддержку слейв сервера, на которого нельзя переключать мастер, но вроде уже начинают делать.
Тестировали у себя 1 месяц, а потом перешли в продакшн на эту систему. Полет хороший :)
Не смотрели в сторону Patroni от Zalando?
Они как раз таки решают на базе etcd проблему split brain и автоматического failover.
В презентации указывали что у них сотни серверов работают через эту систему.
Спасибо за статью.
Скажите пожалуйста, а что с данными PostgreSQL при ребилдинге? Стоит ли вообще запускать PostgreSQL в контейнере, так как непонятно где и как хранятся данные? А как дела с бекапом, репликами и HA?
Смотрели в сторону kubernetes?
Имел неприятный опыт от попытки использования Маратона. В azure есть шаблон Mesos+Marathon, которые поднимает машинки и устаналивает. Попытался поднимать контейнеры в Маратоне, ничего не происходило к сожалению.
Скажите пожалуйста, используете ли Mesos+Marathon в продакшене?
Моя история:
В 2014 году случился крах турфирм. Я думал что мой турагент нормальный (Атлас Трэвел с 1990 года работает) и меня это не коснется. За 1 день (август 2014) до вылета позвонили и сказали что турагент разорился и не перечислил 50% стоимость турфирме (Библио Глобус). Предложили или платите 50% и летите, или не платите и не летите. Отпуск срывать не хотелось, оплатил и полетел. По прилету начал гуглить по всей этим судебным делам.
Подал иск в начале октября 2014 я подал в суд на Атлас и Библио в мировой суд. Решение было вынесено только в июне 2015, так как судья очень часто требовались разные документы и бумажки для обоснования моей позиции, хотя достаточно было статьи из ФЗ о турфирмах и чеки об оплате.
Она вынесла решение не в мою пользу, посчитав что Библио не должен возвращать деньги.
Для подачи апелляции требуется знать почему судья отказал. Узнать это можно в мотивированном решении суда. Суд обязан по закону при письменном заявлении сделать его за… вроде 3 или 5 дней.
В июле я позвонил узнать сделали мне его или нет. В конце концов с прекрасными представителями судебного участка я общался до октября 2015 года, чтобы узнать когда мне выдадут его. Для ускорения выдачи писал в прокуратору, ВККС РФ, председателю суда. В итоге помог звонок какому то судье из районного суда.
В октябре 2015 года я подал апелляцию и в конце ноября 2015 года районный суд вынес решение в мою пользу. В декабре получил исполнительный лист и отправил по почте в Москву. В январе 2016 года началось исполнительное производство и закончилось только в апреле 2016 года.
Хроника:
сентябрь 2014 — подача заявления
июнь 2015 — решение в мировом суде
октябрь 2015 — получение мотивированной части
ноябрь 2015 — решение районного суда
декабрь 2015 — получение исполнительного листа
январь 2016 — возбуждение исполнительного производства
апреля 2016 — выплата денег
Итого 20 месяцев.
Судебная система РФ тупа и беспощадна. Слишком много бюрократии и безнаказанности судей.
Также юристы советуют обращаться не ФССП а напрямую в банк, в котором открыт счет юрлица. Они переведут деньги в течении 3 дней. ФССП делает это как минимум 3-4 месяца и это только если юрлицо не банкрот.
Мой совет:
Все фоткайте и фиксируйте. Делайте и храните копии всех документов возникающих в судебном процессе (особенно протоколов судебных заседаний). Требуйте соблюдения ваших прав. Нарушение любого процессуального действия в судебном процессе — повод отмены и пересмотра решения. На каждое нарушение — письмо в прокуратору, председателю суда и ВККС РФ.
Будем ждать туториал!
Скажите пожалуйста, а как будет работать репликация и переключения master в slave при Azure Maintaince.
Azure Maintaince — это разовое отключение машин (до 30 минут) в произвольное время в произвольном порядке в течении 72 часов.
Ситуация такая:
Есть сервер A (Master) и сервер B (Slave):
1. Произошел Azure Maintaince
2. Отключился сервер A
3. B стал Master
4. A поднялся и он считает, что он Master
5. B отключился
6. B поднялся заново, но он все еще Master.
4 шаг — как сделать так чтобы A стал работать как Slave?
5 шаг — как сделать так чтобы A стал работать как Master?
6 шаг — как сделать так чтобы B стал обратно Slave?
Система балансировки и переключения — PgPool, однако в условиях Azure Maintaince он некорректно отрабатывает, так как запущен в 2 экземплярах. В документации написано, что не следует его запускать в более чем 1 экземпляре. Он может некорректно переключать систему из Master в Slave.
Единственный вариант как я рассматривал это Pacemaker, однако руки до него не дошли.
Хотелось бы поподробнее узнать про это.
Рассматривал вариант с PgPool, но в нем была проблема в том, что при выключении мастера и его восстановлении, он не знал о том, что другая машина стала мастером. PgPool некорректно работал одновременно на 2 машинах. Да и честно как то это костыльно выглядело.