Лето 2006 или 2007 года. Сын был ещё совсем мелкий, в возрасте когда активно исследуют мир всё пробуя на зуб. На компе Windows XP вдруг выдаёт: "обнаружено неизвестное устройство". Неизвестным устройством оказался дата-кабель от Fujitsu-Siemens Pocket LOOX 720, одним концом воткнутый в USB порт, а другой конец торчал изо рта ребенка :)
Если посмотреть в каком окружении содержится patroni, то видно, что это сообщество веб программистов. :)
IBM, RedHat(ещё до того как был куплен IBM), Morgan Stanley, Bloomberg, Adobe, Турецкие электрические сети. Это только маленькая часть компаний (которые я могу назвать публично) и использующие Patroni. Сообщество веб программистов говоришь? Ок.
он и не скрывает, что он пришел из веб разработки, на 9й секунде ролика :) Хотя сейчас предпочитает себя называть DBA, но прошлого не скроешь. :)
Если что, по образованию я вообще Физик.
причем терминологию (STONITH) используют из Pacemaker. :)
Можно конечно изобрести новую терминологию, вот только зачем?
и есть отдельное облако из ETCD (а вот их должно быть нечетное число) и собственно на ETCD (а не патрони) и реализуется кворум.
Предлагаете имплеменитровать Raft, Paxos или ZAB с нуля и облажаться? ОК.
Т.е. для этого шесть серверов поднимать? :)
Каждый решает сам. Никто не запрещает запускать Etcd на тех же нодах что Patroni.
Есть второй вариант, держать один кластер Etcd и с ним будут работаеть десятки и сотни кластеров Patroni.
В самом patroni её и нету, по сути, там вся надежда на ETCD. А могут быть и другие сервисы для хранения: косул и еще какой-то. И все их надо анализировать на защиту от split-brain и возможные подводные камни.
Все это начиналось в 2018 году, рассматривались следующие технологии:
Pacemaker (с модулями pgsql или pgsqlms(PAF)). Это стандартное решение от RedHat для отказоустойчивых кластеров на базе RedHat.
RepMgr — решение от 2nd Quadrant, это один из соавторов PostgreSQL
Patroni — нечто написанное веб-программистами для веб-программистов и активно рекламируемое на форумах веб-программистов. :)
Вы может быть очень сильно удивитесь, но у PostgreSQL очень много контрибьюторов, и я кстати один из них :)
Более того, как правило большинство разработчиков постгреса лично знакомы друг с другом. PAF изначально разрабатывался Dalibo, и они кстати не гнушаются использовать Patroni ввиду более продвинутого функционала. И немного про Repmgr, в данный момент одна крупная американская финансовая организация переезжает в Repmgr на Patroni (речь идёт о тысячах кластеров).
Два года назад у Patroni был заметно беднее функционал. Я не припомню, чтобы там была хорошая, продуманная защита от split-brain. Хотя за два года многое могло изменится.
Месье знатный теоретик. Ещё 5 лет назад Patroni обходил все остальные решения по функционалу.
Защита от split-brain 100%:
Self-fencing если не можем писать в Etcd.
Watchdog рестартанёт ноду если на ней упал Patroni.
Всё остальное от лукавого. STONITH в большинсте случаев трудно реализуем. А для правильной имплементации требует второго сетевого канала между серверами.
Поддержки Patroni у RedHat нет. Patroni нет ни в официальном репозитории, ни в EPEL, ни PostgresQL репозитории пакетов. На официальном сайте Patroni тоже нет rpm пакетов.
Каждый должен заниматься своим делом. У меня нет ни времени ни желания билдить пакеты для 100500 дистрибутивов. Кстати, на одном RedHat свет клином не сошёлся. Пакет Patroni входит в Debian и Ubuntu ещё с 2018 года.
Предполагается что Patroni будет либо скачиваться через git и потом раскладываться и настраиваться по системе вручную. Либо устанавливаться через pip, но потом все равно недостающие в pip инсталяции файлы, например patroni.service для systemd, нужно будет скачивать вручную через git, устанавливать и настраивать.
Ещё раз повторюсь. Существует 100500 дистрибутивов. Systemd очень странное поделие с извращенной идеологией. У меня нет времени на поддержание этого зоопарка. Пакетами могут (и занимаются) заинтересованые люди. Я их знаю не только по именам но и лично и они проделывают титаническую работу.
В защиту Pip и Git могу сказать что этот 100% работает на всех платформах, включая Windows :) И да, есть места где Patroni используют на Windows в production (сотни инсталляций)!
В Pacemaker все идет в одном флаконе. Да, это несколько пакетов, но все они вместе разрабатываются одной командой разработчиков и вместе тестируются.
Так себе аргумент. Количество разработчиков и пользователей у Etcd на порядок превышает какой-то там Pacemaker. Соответственно вероятность багов в имплементации quorum тоже меншье на порядок.
Patroni подразумевает солянку из разный приложений разрабатываемых отдельно.
Это кстати преимущество, а не недостаток. Каждый должен делать то что умеет делать хорошо.
Отдельное распределенное хранилище данных ETCD (причем кворум реализован на нём),
У Pacemaker это тоже наверняка отдельный компонент. Может быть я повторюсь, но количество инсталляций Etcd первышает Pacemaker на порядки, и соответственно вероятность попасть на очень критический баг на порядок меньше.
отдельно надо что-то придумывать для указания на действующие сервисы (consul?)
Можно просто использовать Consul вместо Etcd :) Другие варианты — HAProxy, vip-manager от Cybertec либо абсолютно любой железный или софтовый балансировщик нагрузки.
Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.
В Pacemaker есть команды для администрирования ресурсов (перемещения их по узлам). Например с помощью команды pcs resource ban можно заставить сервисы покинуть нужный узел для обслуживания, например чтобы там осуществить обновление софта yum update, перезагрузить OS и вернуть узел в кластер (разбанить) с помощью pcs resource clear. Ничего подобного Patroni не предусмотрено.
Плохо искали. Контроллируемое переключение (switchover) было имплементировано еще в 2015 году. У "конкуретнов" такая фича появилась только несколько лет спустя. Кроме того, Patroni умеет делать отложеный (запланированный) switchover в определенно заданное время. Например можно задать переключение в 4 часа ночи, когда мы знаем что трафик и нагрузка минимальны.
Во первых надо запустить Consul кластер на 3 хостах (иначе не будет HA)
Consul agent должен работать на всех машинах где планируется запускать Patroni + Postgres. При этом этот агент не обязательно должен участвовать в кворуме.
Patroni использует Consul исключительно как KV Store.
Проблема не в Patroni, а в Consul, он конечно запущен (процесс живой) и даже порт слушает, но при этом неконсистентен и Patroni не может в него ничего записать ни прочитать из него.
К сожалению с кластеризацией Consul я вряд-ли смогу помочь.
Начиная с 9.6 такое возможно, но Patroni пока-что так не умеет.
Если будет свободное время — сделаю, но с другое стороны мы всегда рады пулл-реквестам :)
Всё верно, но скоро ещё добавим synchronous_mode_strict.
В этом случае мастер не будет выполнять транзакции если нет synchronous standby
Но не забывайте, это поведение по умолчанию, и клиент всегда может решить что ему не нужна синхронная репликация и отключить её: SET local synchronous_commit = 'local';
«rm -rf /var/lib/pgsql/9.6/data», и перезапустить Patroni. Она сольет базу с мастера целиком.
Хотите повторить опыт Gitlab? :) Пожалуйста, НИКОГДА так не делайте. Специально для таких случаев мы придумали patronictl reinit <cluster> <node>
Эта команда абсолютна безопасна, текущий мастер просто откажется её выполнять.
Реплика-же сделает всё как нужно: Patroni вначале остановит postgres, удалит data директорию, заберёт новый pg_basebackup с мастера и снова запустит postgres.
Статью написал учитель английского, для него программирование это хобби. С другой стороны про сумму арифметической прогрессии проходят в средней школе и судя по опубликованным решениям он далеко не один такой…
Предложенную систему можно кстати усовершенствовать:
1) создаём снапшот
2) на снапшоте создаём triggerfile
3) запускаем postgres в docker и указываем ему наш снапшот как volume
4) реплика остаётся репликой (нетронутой), плюс у нас есть база для тестов
5) после тестов просто удаляем снапшот
P.S.> В принципе можно обойтись и без докера, нужно только при старте postgres указать другой port.
У меня была идея сделать что-то подобное пару лет назад, но к сожалению при большом количестве disk writes btrfs вела себя непредсказуемо, вся система периодически замирала, иногда на доли секунды, а иногда до нескольких секунд :(
Лето 2006 или 2007 года. Сын был ещё совсем мелкий, в возрасте когда активно исследуют мир всё пробуя на зуб. На компе Windows XP вдруг выдаёт: "обнаружено неизвестное устройство". Неизвестным устройством оказался дата-кабель от Fujitsu-Siemens Pocket LOOX 720, одним концом воткнутый в USB порт, а другой конец торчал изо рта ребенка :)
IBM, RedHat(ещё до того как был куплен IBM), Morgan Stanley, Bloomberg, Adobe, Турецкие электрические сети. Это только маленькая часть компаний (которые я могу назвать публично) и использующие Patroni. Сообщество веб программистов говоришь? Ок.
Если что, по образованию я вообще Физик.
Можно конечно изобрести новую терминологию, вот только зачем?
Предлагаете имплеменитровать Raft, Paxos или ZAB с нуля и облажаться? ОК.
Каждый решает сам. Никто не запрещает запускать Etcd на тех же нодах что Patroni.
Есть второй вариант, держать один кластер Etcd и с ним будут работаеть десятки и сотни кластеров Patroni.
Успокойтесь, всё уже проанализировали до вас.
Вы может быть очень сильно удивитесь, но у PostgreSQL очень много контрибьюторов, и я кстати один из них :)
Более того, как правило большинство разработчиков постгреса лично знакомы друг с другом. PAF изначально разрабатывался Dalibo, и они кстати не гнушаются использовать Patroni ввиду более продвинутого функционала. И немного про Repmgr, в данный момент одна крупная американская финансовая организация переезжает в Repmgr на Patroni (речь идёт о тысячах кластеров).
Месье знатный теоретик. Ещё 5 лет назад Patroni обходил все остальные решения по функционалу.
Защита от split-brain 100%:
Всё остальное от лукавого. STONITH в большинсте случаев трудно реализуем. А для правильной имплементации требует второго сетевого канала между серверами.
Каждый должен заниматься своим делом. У меня нет ни времени ни желания билдить пакеты для 100500 дистрибутивов. Кстати, на одном RedHat свет клином не сошёлся. Пакет Patroni входит в Debian и Ubuntu ещё с 2018 года.
Ещё раз повторюсь. Существует 100500 дистрибутивов. Systemd очень странное поделие с извращенной идеологией. У меня нет времени на поддержание этого зоопарка. Пакетами могут (и занимаются) заинтересованые люди. Я их знаю не только по именам но и лично и они проделывают титаническую работу.
В защиту Pip и Git могу сказать что этот 100% работает на всех платформах, включая Windows :) И да, есть места где Patroni используют на Windows в production (сотни инсталляций)!
Так себе аргумент. Количество разработчиков и пользователей у Etcd на порядок превышает какой-то там Pacemaker. Соответственно вероятность багов в имплементации quorum тоже меншье на порядок.
Это кстати преимущество, а не недостаток. Каждый должен делать то что умеет делать хорошо.
У Pacemaker это тоже наверняка отдельный компонент. Может быть я повторюсь, но количество инсталляций Etcd первышает Pacemaker на порядки, и соответственно вероятность попасть на очень критический баг на порядок меньше.
Можно просто использовать Consul вместо Etcd :) Другие варианты — HAProxy, vip-manager от Cybertec либо абсолютно любой железный или софтовый балансировщик нагрузки.
Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.
Плохо искали. Контроллируемое переключение (switchover) было имплементировано еще в 2015 году. У "конкуретнов" такая фича появилась только несколько лет спустя. Кроме того, Patroni умеет делать отложеный (запланированный) switchover в определенно заданное время. Например можно задать переключение в 4 часа ночи, когда мы знаем что трафик и нагрузка минимальны.
Думаю что да, но есть несколько тонкостей:
Может лучше попробовать etcd? Там кластеризация в 100 раз проще: https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md#static
Если планируется запускать больше двух нод с Patroni+Postgres, то можно попробовать https://github.com/zalando/patroni/pull/375, он не требует внешнего DCS
Рекомендую на счёт Consul почитать: https://www.consul.io/docs/guides/bootstrapping.html и https://www.consul.io/intro/getting-started/join.html
P.S. обычно выбирают тот DCS кластер которого уже настроен и работает.
Проблема не в Patroni, а в Consul, он конечно запущен (процесс живой) и даже порт слушает, но при этом неконсистентен и Patroni не может в него ничего записать ни прочитать из него.
К сожалению с кластеризацией Consul я вряд-ли смогу помочь.
trider
Судя по логам очевидно что Patroni не может подключиться к Consul.
Покажи конфиг Patroni.
.
Начиная с 9.6 такое возможно, но Patroni пока-что так не умеет.
Если будет свободное время — сделаю, но с другое стороны мы всегда рады пулл-реквестам :)
Всё верно, но скоро ещё добавим
synchronous_mode_strict.В этом случае мастер не будет выполнять транзакции если нет
synchronous standbyНо не забывайте, это поведение по умолчанию, и клиент всегда может решить что ему не нужна синхронная репликация и отключить её:
SET local synchronous_commit = 'local';Хотите повторить опыт Gitlab? :) Пожалуйста, НИКОГДА так не делайте. Специально для таких случаев мы придумали
patronictl reinit <cluster> <node>Эта команда абсолютна безопасна, текущий мастер просто откажется её выполнять.
Реплика-же сделает всё как нужно: Patroni вначале остановит postgres, удалит data директорию, заберёт новый pg_basebackup с мастера и снова запустит postgres.
Огромное Вам спасибо за статью от Zalando!
1) создаём снапшот
2) на снапшоте создаём triggerfile
3) запускаем postgres в docker и указываем ему наш снапшот как volume
4) реплика остаётся репликой (нетронутой), плюс у нас есть база для тестов
5) после тестов просто удаляем снапшот
P.S.> В принципе можно обойтись и без докера, нужно только при старте postgres указать другой port.
У меня была идея сделать что-то подобное пару лет назад, но к сожалению при большом количестве disk writes btrfs вела себя непредсказуемо, вся система периодически замирала, иногда на доли секунды, а иногда до нескольких секунд :(