https://github.com/zalando/patroni
Если посмотреть в каком окружении содержится patroni, то видно, что это сообщество веб программистов. :) Кому еще придет в голову устанавливать софт через pip, устанавливать PostgreSQL внутрь Кубернетись и т.д? :) Что касается КиберДемон, то он и не скрывает, что он пришел из веб разработки, на 9й секунде ролика. :) Хотя сейчас предпочитает себя называть DBA, но прошлого не скроешь. :)
Два года назад разработчики рассказывали на митапе про patroni (в том числе и про split-brain)
На 16:46 рассказывают теорию, причем терминологию (STONITH) используют из Pacemaker. :) На 18:19 собственно правильная картинка. Есть облако из patroni (кстати их не обязательно должно быть три) и есть отдельное облако из ETCD (а вот их должно быть нечетное число) и собственно на ETCD (а не патрони) и реализуется кворум. Т.е. для этого шесть серверов поднимать? :) Некоторые так и делают. И тогда непонятно, как это все будет работать в случае изоляции ETCD облака от patroni облака? :) На мой взгляд правильнее было размещать ETCD на тех же серверах, где и патрони. В pacemaker, например, каждый узел в себе хранит копию кластерных данных, а не во внешнем облаке. И дальше рассказывается про простенький механизм, когда один патрони пишет временные метки, а остальные читают. Знал я всё это. Именно это я и называл:
Я не припомню, чтобы там была хорошая, продуманная защита от split-brain.
В самом patroni её и нету, по сути, там вся надежда на ETCD. А могут быть и другие сервисы для хранения: косул и еще какой-то. И все их надо анализировать на защиту от split-brain и возможные подводные камни.
Раньше, до Ковид-19, не было. :) Файл там датирован 6 августа 2020 года, наверное ребята из PostgreSQL недавно добавили. В самом же patroni, в документации ни слова об rpm, рекомендуют pip или git (очевидно, что веб-программисты). Ни своих rpm. RPM советуют их брать из сторонних источников. https://github.com/zalando/patroni/issues/877
Вот пример: Patroni и stolon: инсталляция и отработка падений
Да, это интересная ссылка. Видно, что человек по настоящему заморачивался и подробно всё разбирает, правильно делая акценты на нюансах, сложностях и потенциальных ошибках при дизайне. Сам ролик и докладчик мне понравились. Но вы меня неправильно поняли. Я жду тестовый стенд нет от Максима Милютина из Озона, и то, как это всё он придумал, а от наших сисадминов, так, как они всё придумали и это уже проверять. Потому что на patroni все можно сделать очень по разному. И именно поэтому я не вижу смысла делать самому такой тестовый стенд, потому что я могу придумать как-то по другому.
То что старый мастер отставал от нового мастера по времени, это понятно. В этом случае он повесится на репликацию только при условии:
Либо есть какой-то архив журнала транзакций и он сможет используя его догнать новый мастер.
Если архива нет, то в настройках postgresql.conf wal_keep_segments должен быть достаточно большим, чтобы хранить там все сегменты журнала транзакций необходимые для того чтобы старый мастер догнал новый. У меня при тестировании нагрузка небольшая, хватает wal_keep_segments = 1, при реальной нагрузке может потребоваться больше. А при реальной поломке даунт тайм будет такой большой, что там все равно восстанавливать придется либо через pg_basebackup или pg_rewind.
Но весь этот разговор пока ни о чём и гадание на кофейной гуще, потому что вы не пишите какую он выдавал ошибку. :) Что писал pacemaker (paf), что было в логах postgresql.conf.
Я проверил то, про что вы написали (PostgreSQL 11 и соответственно старый pacemaker и paf из Centos 7). При старте OS у меня, разумеется, узел в кластер автоматический не добавляется, по описанной выше причине, чтобы не был циклического рестарта при какой-нибудь неисправности. При корректном выключении:
pcs cluster stop --wait
shudown now
включение и ожидание загрузки OS
pcs cluster start
Репликация поднимается автоматический, да еще и мастер потом возвращается на место, если в настройках это указано (так у меня настроена tuchanka1).
В случае если просто набрать shutdown now, то после pcs cluster start у меня всё тоже поднялось без проблем, даже не надо было запускать cleanup так как ошибок не было. Поэтому надо разбираться в том, какие у вас были ошибки при подключении репликации и с чем они были вызваны. Может быть вы shutdown now набрали слишком поспешно, до того как репликация была установлена и тем самым у вас произошло раздвоение временных линий? Или быть может проблемы связаны с новым PostgreSQL 12 и новым модулем PAF. Когда до этого дойдет дело, протестирую.
Да, в последнее время появляются много сисадминов, которые при выборе технологий отдают предпочтение тем, в которых как киллер фича заявлено уменьшение труда сисадминов. И плохо, что это единственный довод, который вы привели в пользу MongoDB, создает впечатление, что вы не вникали ни как она работает, ни то как она осуществляет HA и решает связанные с этим проблемы типа split-brain.
Кроме того кажущуюся сложность в настройке Pacemaker напрямую связана с его широкими возможностями, гибкостью и универсальностью. Если задаться целью создать узкоспециализированное приложение, то там, очевидно, многое можно скрыть от потребителя и оставить только небольшое количество параметров для настройки.
Все это начиналось в 2018 году, рассматривались следующие технологии:
Pacemaker (с модулями pgsql или pgsqlms(PAF)). Это стандартное решение от RedHat для отказоустойчивых кластеров на базе RedHat.
RepMgr — решение от 2nd Quadrant, это один из соавторов PostgreSQL
Patroni — нечто написанное веб-программистами для веб-программистов и активно рекламируемое на форумах веб-программистов. :)
В чем Pacemaker показался мне предпочтительнее, чем Patroni:
Два года назад у Patroni был заметно беднее функционал. Я не припомню, чтобы там была хорошая, продуманная защита от split-brain. Хотя за два года многое могло изменится.
Поддержки Patroni у RedHat нет. Patroni нет ни в официальном репозитории, ни в EPEL, ни PostgresQL репозитории пакетов. На официальном сайте Patroni тоже нет rpm пакетов. Предполагается что Patroni будет либо скачиваться через git и потом раскладываться и настраиваться по системе вручную. Либо устанавливаться через pip, но потом все равно недостающие в pip инсталяции файлы, например patroni.service для systemd, нужно будет скачивать вручную через git, устанавливать и настраивать.
В Pacemaker все идет в одном флаконе. Да, это несколько пакетов, но все они вместе разрабатываются одной командой разработчиков и вместе тестируются. Это единое решение с единой документацией (лучшая документация по Pacemaker на сайте RedHat, кстати, а не на сайте самого Pacemaker), единой утилитой мониторинга и управления всеми компонентами pcs и т.д. А Patroni подразумевает солянку из разный приложений разрабатываемых отдельно. Отдельное распределенное хранилище данных ETCD (причем кворум реализован на нём), отдельно надо что-то придумывать для указания на действующие сервисы (consul?), все это как-то согласовывать и следить при обновлениях, чтобы это согласование между ними не расстроилось.
В Pacemaker есть команды для администрирования ресурсов (перемещения их по узлам). Например с помощью команды pcs resource ban можно заставить сервисы покинуть нужный узел для обслуживания, например чтобы там осуществить обновление софта yum update, перезагрузить OS и вернуть узел в кластер (разбанить) с помощью pcs resource clear. Ничего подобного Patroni не предусмотрено.
Pacemaker решение универсальное. На его базе можно не только PostgreSQL делать HA, но и другие ресурсы. Например веб сервера и другие компоненты. Я понимаю, что сейчас модно всё, кроме собственно баз данных, размещать в Kubernetes. Но на мой взгляд это именно что мода вызванная назойливым маркетингом. Из разговоров с сисадминами создается впечатление, что отказов в оказании услуг населению вызванных проблемами с Kubernetes было больше, чем проблемами с сервисами, high availability которых Kubernetes должен был бы обеспечивать.
Но при этом Patroni нравится сисадминам и они сейчас разрабатывают альтернативное решение на нём. Я пока еще не видел ни само решение, ни тестовый стенд, на котором можно было бы проверить какие отказы данное решение выдерживает, ни, тем более, систему автоматического тестирования решения на Patroni. А автоматическое тестирование оказалось очень важно. Ведь изначально была полная уверенность в Pacemaker и система автоматического тестирования разрабатывалась исключительно как демонстрация для начальства. Но потом оказалось, что она в состоянии обнаруживать проблемы pacemaker и postgresql, которые возникают либо маловероятно, либо в экзотических случаях и поэтому не были отловлены при обычном тестировании. А после обнаружения их можно уже исправлять.
Так что я надеюсь что спустя какое-то время в этом самом блоге от Домклик появится статья уже от сисадминов про то, какую систему на Patroni они разработали, какие отказы она выдерживает, а какие и нет. Ну и самое интересное, а как же они её тестировали? :)
Не совсем так. Это в английском master это хозяин, причем, как я понимаю, ремесленной мастерской в феодальные времена. А в американском… Может читали Марка Твена «Приключе́ния Ге́кльберри Фи́нна»? Книжка про то как белый пацан-беспризорник путешествовал по реке на плоту вместе с беглым негром. Так вот, негр постоянно обращается к пацану "мастэ". Так вот это оно и есть, Гек никаким хозяином негру не был.
Про 12 postgres. Тестовый стенд, про который статья, работает пока только с CentOS 7 и PostgreSQL 11. Дело в том что разработка была начата еще в те времена. А потом было важно добиться стабильного результата до перехода на новые версии. Но проект был не в приоритете, отвлекали на другие, поэтому разработка была затянута. Сейчас потихоньку начну апгрейдить на новые версии. Знаю только, что поддержка 12 PostgreSQL у PAF появилась довольно поздно: 10 марта 2020 года в версии 2.3.0.
Про мониторинг постгресса. Pacemaker мониторит его с помощью PAF. А тестовый стенд с помощью psql и sql запросов, одним он пишет текущее время в таблицу на мастере, вторым считывает из этой таблице у раба. Тем самым при тестировании на отказоустойчивость тестовый стенд удостоверяется, что все действительно работает.
Что касается репликации и медного таза, не понял вашу ситуацию. Вопрос был о том, что, допустим, есть три узла, один мастер и два раба и при отказе мастера, один из рабов становится новым мастером и второй должен начать реплицироваться с него? Или о том, чтобы при отказе мастера вернуть его в кластер и начать на него репликацию с нового мастера автоматический?
Если первый вариант. Три узла, например, мастер и два раба. При отказе мастера один из рабов становится новым мастером и на него переходит float IP мастера. Все это делается автоматический силами Pacemaker. У второго раба репликация настроена на float IP и переподключение репликации на новый мастер осуществляется автоматический силами PostgreSQL. И обычно так и происходит. Но бывают ситуации когда нет, они описаны в разделе «выявленные при тестировании недостатки», автор PAF уже заинтересовался ими, чтобы исправить. Дело там встало в том, чтобы перевести README на английский и предоставить ему этот стенд. Займусь этим завтра. :)
Если речь о том, чтобы автоматический вернуть отказавший узел в кластер, то не pacemaker'а ума это дело. :) Прежде чем возвращать отказавший узел надо сначала проанализировать отказ в работе и поставить диагноз, понять причину и устранить, например заменить глючное железо. Все это в компетенции исключительно сисадмина. И только после этого уже возвращать узел в кластер. Поэтому pacemaker никогда не делает этого автоматический. Но в случае этого тестового стенда, тестирующие скрипты, которые имитируют неисправности, знают как после этого узел возвращать в работоспособное состояние. Поэтому в тестовом стенде возвращение узлов, которые были «неисправными» и поднятие на них репликаций (а в случае tuchanka1 и переезд мастера обратно) происходит автоматический.
Да я тоже за развернутый синтаксис. :) Но создать переменные для всех 255 цветов… (причем и для обозначений цвета для букв и для курсора, т.е. 510). Там даже уникальные имена цветам замучаешься придумывать, а когда придумаешь — забудешь какой конкретный цвет они обозначают. :)
Не баш, а терминал. Должна быть или специальная поддержка со стороны терминала, чтобы он вставлял туда картинки. Либо их должен поддерживать системный фонт. Оказалось что в dejavu есть много смайликов и даже смайлики-котята. Можно использовать в терминале. :)
Вот это интересно, если оно так. У вас значится что Gnome Terminal тоже поддерживает. Напишите пример с echo который бы позволил задать цвет текста в 24хбитном RGB. Ваш пример по ссылке пробовал — не работает.
Даже такой минимум как хостнейм и текущий каталог (а это по умолчанию) порой занимают порядочную ширину и для набора команд остается недостаточно места. Да и неудобно это. Гораздо приятнее набирать команды с абсолютно пустой строки. :) Это и было основной причиной двухстрочного приглашения. Плюс оно удобно отделяет вывод предыдущей команды. А вывод времени в основном используется не для того чтобы знать текущее время, а для того чтобы понимать насколько какая программа «подвисла», сколько выполняется длительная компиляция и т.д. Я понимаю что time удобнее. Но подобный интерес зачастую возникает не заранее, а после того как программа неожиданно долго работает. :) Так что у меня почти тоже что и у вас, разве что вывода свободного места нет, т.к. набрать df всегда просто.
Разумеется конфиги (.bashrc или что там у вас) должны быть на каждом сервере, каждый в свой цвет. Сами по себе цвета не появятся. :) Аналог PS1 у fish устроен по другому, там это функция fish_prompt. Но суть та же самая, если будите там выдывать ESC последовательности управляющие цветом — они будут интерпретироваться терминалом. Шелл только принимает символы и выдает их, в том числе ESC последовательности и прочие управляющие символы, а цвета воспроизводит всегда терминал.
Bash тоже в линукс консоле работает. Но цвета линукс консоле цвета по беднее и их по другому надо будет задавать, цвет курсора там задать не получилось и набор цветов там будет упрощенный.
Ну так если работаешь непрерывно, то по разнице времени на «момент приглашения» (т.е. на момент завершения задачи) с предыдущим промптом можно приблизительно оценить время выполнения. А для более точной оценки есть команда time:
14:09:35 j0 olleg@petrel:~
$ time sleep 10
real 0m10.009s
user 0m0.000s
sys 0m0.000s
14:09:51 j0 olleg@petrel:~
$
Ну да, у меня практический тоже самое, только без load, одинаково мыслим. :) Но все это, в принципе, в одну строчку помещается, так что двухстрочного для меня достаточно. Да и удобно еще тем что наглядно отделяет вывод одной команды от другой.
Дело не в bash. Эти ESC последовательности команд зашитые в PS1 читаются терминалом и терминал, а не bash их расцвечивает. Так что будут работать с любым шелом. И чем еще удобен так то что при этом на сам терминал не завязано. Будешь в одном терминале переходить по ssh с сервера на сервер и цвета у приглашения будут меняться соответственно. Ну и цвет курсора, когда открыты конфиги в редакторе, например, беглово взгляда на курсор достаточно чтобы не забывать — на каком сервере.
Ну вы что, поспорит хотите? :)
https://github.com/zalando/patroni
Если посмотреть в каком окружении содержится patroni, то видно, что это сообщество веб программистов. :) Кому еще придет в голову устанавливать софт через pip, устанавливать PostgreSQL внутрь Кубернетись и т.д? :) Что касается КиберДемон, то он и не скрывает, что он пришел из веб разработки, на 9й секунде ролика. :) Хотя сейчас предпочитает себя называть DBA, но прошлого не скроешь. :)
На 16:46 рассказывают теорию, причем терминологию (STONITH) используют из Pacemaker. :) На 18:19 собственно правильная картинка. Есть облако из patroni (кстати их не обязательно должно быть три) и есть отдельное облако из ETCD (а вот их должно быть нечетное число) и собственно на ETCD (а не патрони) и реализуется кворум. Т.е. для этого шесть серверов поднимать? :) Некоторые так и делают. И тогда непонятно, как это все будет работать в случае изоляции ETCD облака от patroni облака? :) На мой взгляд правильнее было размещать ETCD на тех же серверах, где и патрони. В pacemaker, например, каждый узел в себе хранит копию кластерных данных, а не во внешнем облаке. И дальше рассказывается про простенький механизм, когда один патрони пишет временные метки, а остальные читают. Знал я всё это. Именно это я и называл:
В самом patroni её и нету, по сути, там вся надежда на ETCD. А могут быть и другие сервисы для хранения: косул и еще какой-то. И все их надо анализировать на защиту от split-brain и возможные подводные камни.
Раньше, до Ковид-19, не было. :) Файл там датирован 6 августа 2020 года, наверное ребята из PostgreSQL недавно добавили. В самом же patroni, в документации ни слова об rpm, рекомендуют pip или git (очевидно, что веб-программисты). Ни своих rpm. RPM советуют их брать из сторонних источников.
https://github.com/zalando/patroni/issues/877
Да, это интересная ссылка. Видно, что человек по настоящему заморачивался и подробно всё разбирает, правильно делая акценты на нюансах, сложностях и потенциальных ошибках при дизайне. Сам ролик и докладчик мне понравились. Но вы меня неправильно поняли. Я жду тестовый стенд нет от Максима Милютина из Озона, и то, как это всё он придумал, а от наших сисадминов, так, как они всё придумали и это уже проверять. Потому что на patroni все можно сделать очень по разному. И именно поэтому я не вижу смысла делать самому такой тестовый стенд, потому что я могу придумать как-то по другому.
То что старый мастер отставал от нового мастера по времени, это понятно. В этом случае он повесится на репликацию только при условии:
wal_keep_segments = 1, при реальной нагрузке может потребоваться больше. А при реальной поломке даунт тайм будет такой большой, что там все равно восстанавливать придется либо через pg_basebackup или pg_rewind.Но весь этот разговор пока ни о чём и гадание на кофейной гуще, потому что вы не пишите какую он выдавал ошибку. :) Что писал pacemaker (paf), что было в логах postgresql.conf.
Я проверил то, про что вы написали (PostgreSQL 11 и соответственно старый pacemaker и paf из Centos 7). При старте OS у меня, разумеется, узел в кластер автоматический не добавляется, по описанной выше причине, чтобы не был циклического рестарта при какой-нибудь неисправности. При корректном выключении:
Репликация поднимается автоматический, да еще и мастер потом возвращается на место, если в настройках это указано (так у меня настроена tuchanka1).
В случае если просто набрать
shutdown now, то послеpcs cluster startу меня всё тоже поднялось без проблем, даже не надо было запускатьcleanupтак как ошибок не было. Поэтому надо разбираться в том, какие у вас были ошибки при подключении репликации и с чем они были вызваны. Может быть выshutdown nowнабрали слишком поспешно, до того как репликация была установлена и тем самым у вас произошло раздвоение временных линий? Или быть может проблемы связаны с новым PostgreSQL 12 и новым модулем PAF. Когда до этого дойдет дело, протестирую.Да, в последнее время появляются много сисадминов, которые при выборе технологий отдают предпочтение тем, в которых как киллер фича заявлено уменьшение труда сисадминов. И плохо, что это единственный довод, который вы привели в пользу MongoDB, создает впечатление, что вы не вникали ни как она работает, ни то как она осуществляет HA и решает связанные с этим проблемы типа split-brain.
Кроме того кажущуюся сложность в настройке Pacemaker напрямую связана с его широкими возможностями, гибкостью и универсальностью. Если задаться целью создать узкоспециализированное приложение, то там, очевидно, многое можно скрыть от потребителя и оставить только небольшое количество параметров для настройки.
Все это начиналось в 2018 году, рассматривались следующие технологии:
В чем Pacemaker показался мне предпочтительнее, чем Patroni:
pcsи т.д. А Patroni подразумевает солянку из разный приложений разрабатываемых отдельно. Отдельное распределенное хранилище данных ETCD (причем кворум реализован на нём), отдельно надо что-то придумывать для указания на действующие сервисы (consul?), все это как-то согласовывать и следить при обновлениях, чтобы это согласование между ними не расстроилось.pcs resource banможно заставить сервисы покинуть нужный узел для обслуживания, например чтобы там осуществить обновление софтаyum update, перезагрузить OS и вернуть узел в кластер (разбанить) с помощьюpcs resource clear. Ничего подобного Patroni не предусмотрено.Но при этом Patroni нравится сисадминам и они сейчас разрабатывают альтернативное решение на нём. Я пока еще не видел ни само решение, ни тестовый стенд, на котором можно было бы проверить какие отказы данное решение выдерживает, ни, тем более, систему автоматического тестирования решения на Patroni. А автоматическое тестирование оказалось очень важно. Ведь изначально была полная уверенность в Pacemaker и система автоматического тестирования разрабатывалась исключительно как демонстрация для начальства. Но потом оказалось, что она в состоянии обнаруживать проблемы pacemaker и postgresql, которые возникают либо маловероятно, либо в экзотических случаях и поэтому не были отловлены при обычном тестировании. А после обнаружения их можно уже исправлять.
Так что я надеюсь что спустя какое-то время в этом самом блоге от Домклик появится статья уже от сисадминов про то, какую систему на Patroni они разработали, какие отказы она выдерживает, а какие и нет. Ну и самое интересное, а как же они её тестировали? :)
Не совсем так. Это в английском master это хозяин, причем, как я понимаю, ремесленной мастерской в феодальные времена. А в американском… Может читали Марка Твена «Приключе́ния Ге́кльберри Фи́нна»? Книжка про то как белый пацан-беспризорник путешествовал по реке на плоту вместе с беглым негром. Так вот, негр постоянно обращается к пацану "мастэ". Так вот это оно и есть, Гек никаким хозяином негру не был.
Про мониторинг постгресса. Pacemaker мониторит его с помощью PAF. А тестовый стенд с помощью psql и sql запросов, одним он пишет текущее время в таблицу на мастере, вторым считывает из этой таблице у раба. Тем самым при тестировании на отказоустойчивость тестовый стенд удостоверяется, что все действительно работает.
Что касается репликации и медного таза, не понял вашу ситуацию. Вопрос был о том, что, допустим, есть три узла, один мастер и два раба и при отказе мастера, один из рабов становится новым мастером и второй должен начать реплицироваться с него? Или о том, чтобы при отказе мастера вернуть его в кластер и начать на него репликацию с нового мастера автоматический?
Если первый вариант. Три узла, например, мастер и два раба. При отказе мастера один из рабов становится новым мастером и на него переходит float IP мастера. Все это делается автоматический силами Pacemaker. У второго раба репликация настроена на float IP и переподключение репликации на новый мастер осуществляется автоматический силами PostgreSQL. И обычно так и происходит. Но бывают ситуации когда нет, они описаны в разделе «выявленные при тестировании недостатки», автор PAF уже заинтересовался ими, чтобы исправить. Дело там встало в том, чтобы перевести README на английский и предоставить ему этот стенд. Займусь этим завтра. :)
Если речь о том, чтобы автоматический вернуть отказавший узел в кластер, то не pacemaker'а ума это дело. :) Прежде чем возвращать отказавший узел надо сначала проанализировать отказ в работе и поставить диагноз, понять причину и устранить, например заменить глючное железо. Все это в компетенции исключительно сисадмина. И только после этого уже возвращать узел в кластер. Поэтому pacemaker никогда не делает этого автоматический. Но в случае этого тестового стенда, тестирующие скрипты, которые имитируют неисправности, знают как после этого узел возвращать в работоспособное состояние. Поэтому в тестовом стенде возвращение узлов, которые были «неисправными» и поднятие на них репликаций (а в случае tuchanka1 и переезд мастера обратно) происходит автоматический.
youtu.be/jqR-CGLGc_g
Bash тоже в линукс консоле работает. Но цвета линукс консоле цвета по беднее и их по другому надо будет задавать, цвет курсора там задать не получилось и набор цветов там будет упрощенный.