Pull to refresh

Comments 41

Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать.

Ага, только переезд постгрес-мастера по скрипту pacemaker тоже провалился, и весь кластер рассыпался вдребезги. Такое тоже бывает ;)


Вообще, имхо corosync/pacemaker — самый рульный кластерный стек на линуксах, во всяком случае, я с ним почти без проблем сумел разобраться и даже что-то на нем поднять, что стоит и не падает.

Просто интересно, а как часто у вас просходит (по любым причинам) переезд мастера?

У меня — вплоть до никогда, но я с тех пор особо и не админил/настраивал постгрес с каким-либо менеджером мастера поверх. В окрестностях меня — было пару раз, но строго в тестовом режиме, в основном по питанию, если в неправильном порядке останавливать ВМ в ожидании отключения силовой, там может что и поломаться. Оттого и коммент был.

Опцию no-quorum-policy=ignore лучшего вообще не показывать, а если показывать, то писать про split-brain сразу после, а не через еще полстатьи. Найдутся же люди, мол, «пфф, что за глупость, конечно же, выключу» :D
UFO just landed and posted this here
… Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время.

В нормальной компании на такой случай должен быть дежурный администратор, иначе никакой кластер не спасет.
UFO just landed and posted this here
В виртуализированной среде механизм фенсинга (fencing) усложняется и становится многоуровневым: на первом уровне нужно реализовать выключение виртуальной машины через гипервизор, а на втором — выключение всего гипервизора (второй уровень срабатывает, когда на первом уровне фенсинга корректно не отработал). К сожалению, у некоторых гипервизоров нет возможности фенсинга. Рекомендуем не использовать виртуальные машины при построении ОУК

Вот этого абзаца я вообще не понял.


Во-первых, что это за таинственные "некоторые" гипервизоры, у которых нет функции выключения VM?
Во-вторых, из-за сбоя в одной VM гасить весь хост, серьезно?!
В-третьих, финальное "рекомендуем не использовать VM" — а вы на календарь смотрели? Сейчас не 2008 год, а 2018.


Понятно, что многие вещи при виртуализации усложняются (начиная от понимания того, что, собственно случилось, заканчивая механизмами реакции). Но это попросту заслуживает отдельного рассмотрения, а не рекомендаций вида "не используйте виртуалки, там надо".

Во-первых, что это за таинственные «некоторые» гипервизоры, у которых нет функции выключения VM?

Имхо, тут вопрос не в «нет функции выключения», а то, что корректный фенсинг — это жесткое отключение из розетки (если проводить аналогию с железками), а не милая просьба «выключись, пожалуйста». И вот если хост не смог выключить быстро VM (ну зависли там процессы напрочь и система не хочет выключиться), то в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.
что корректный фенсинг — это жесткое отключение из розетки

Тогда это надо делать через управляемый PDU, а не IPMI, с которым тоже фокусы могут быть. ;) А выключение через IPMI концептуально мало чем отличается от выключения через гипервизор.


в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.

Может быть. Только управляться это должно не на уровне кластера PostgreSQL, а на уровне кластера виртуализации. Я про то и пишу, что в виртуализованной среде нужно дополнительное планирование, а советы "выключите хост" или "не используйте виртуализацию" не слишком полезны в общем случае. Хотя, конечно, вполне могут быть кейсы, где виртуализация просто не нужна.

Или можно просто начать использовать CockroachDB, который с самого начала multimaster. Понятно, что по функционалу не сравнить, но ребята энергично работают.
Добавьте пожалуйста опрос: какую систему кластеризации postgresql вы используете? 1) corosync/pacemaker 2) patroni 3) repmgr 4) stolon
А такой кластер можно растянуть на пару датацентров или лучше не надо?
[ответ автора статьи, Игоря Косенкова]
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.

Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.

Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.

Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.
Т.е. крутящееся «сверху» приложение должно быть готово к пропажи части данных из-за асинхронной репликации? И если приложение не готово (возьмем обычный 1С), то можно получить глобальную проблему вместо ее решения?

Ну это достаточно очевидный момент при работе с любой БД в принципе — либо у вас синхронная репликация с соответствующими требованиями к каналу, либо асинхронная с возможностью потери данных.


Что касается приложений и 1С в частности — если при репликации поддерживается целостность данных на уровне транзакций, то потери из-за асинхронности ничем не более опасны, чем, например, восстановление копии из бэкапа SQL.

Вопрос, как и ко всем этим хреновым инструментариям, которые не решают проблему. Пришёл на master долгоиграющий ALTER TABLE, который успешно просочился в бинарных логах на слейвы, в этот момент у нас факап на мастере и неважно что руки/patroni/Pacemaker и т.д. один из слейвов переключает в режим master'а, который из бинлога разгребает долгоиграющий ALTER TABLE. Как Pacemaker узнает о долгоиграющем ALTER TABLE и поймёт когда SLAVE его разгребёт, чтобы сделать его мастером?
лаконичный ответ автора статьи, Игоря Косенкова: Никак.
multimaster в Postgres Pro Enterprise справится.
А можно поподробнее, хочется глазами увидеть и пощупать руками
+ не раскрыта тема конфигурации в части PostgreSQL для pcs

Чуть позже добавлю это в раздел "Особенности использования PostgreSQL для ОУК"

Если например две ноды, есть общее хранилище то с помощью Pacemaker можно сделать failover кластер где постгрес живёт на одной ноде а на второй поднимается при сбое на первой?

[Игорь Косенков]: Двухнодовый кластер обладает существенным недостатком — в нем отсутствует кворум. В связи с этим, такой кластер не заведется, если не указать Pacemaker'у, чтобы он не учитывал кворум. Но даже, если скажете Pacemaker'у no-quorum-policy=ignore, то вас подстерегает опасность — кластер без учета кворума не может противостоять сбою "Потеря сетевой связности (линка) между нодами". При таком сбое обе ноды будут считать соседнюю ноду сбойнувшей (потерянной) и в кластере появятся одновременно 2 Мастера с двумя Virtual-IP. Получите типичный split-brain, из которого ничего хорошего не получится.
В нашей компании специально для двух-нодововых кластеров (без кворума) разработано решение тоже на базе pacemaker/corosync, которое защищает от split-brain в таких ситуациях. Описание данного решения — тема отдельной статьи.
Также в двухнодовой конфигурации будет работать наше решение multimaster, входящее в Enterprise.

А вот и про то и про другое подробнее и с примерами статьи будут?
[Игорь Косенков:] В планах на будущее — написание отдельной статьи на тему «Защита от split-brain в 2-х нодовом отказоустойчивом кластере на базе Pacemaker/Corosync»
Про multimaster почитал. Интересно, но это явно для богатых контор. С тем же 1С его кстати тестировали?
multimaster с 1С пока не поддерживается, работы в этом направлении идут.
Вот здесь я не совсем согласен по поводу двухнодовых кластеров, у многих простая потребность: в одном data-центре и в одном сетевом сегменте организовать autofailover из двух железок. Зависит всё от условий и системы, если этой какой-то коммерческий проект, то конечно можно размазать кворумный кластер по 3м разным облачным сервисам/data-центрам. У нас много правительственных организаций которые обладают нехилыми data-центрами в рамках которых требуется обеспечить примитивную отказоустойчивость БД для какой-нибудь системы, почему сразу ручной режим, если низкие SLA
[Игорь Косенков:] «Примитивная отказоустойчивость» — звучит как пародия на отказоустойчивость. Ведь в случае с 2-х нодовым кластером, некоторые сбои будут фатальными для СУБД…
Как в таком случае объяснять руководству, что ваш отказоустойчивый кластер не всегда отказоустойчивый?
Решение не очень, всякие GlusterFS, OCFS, HDFS это overhead на запись
Т.к. сейчас строю кластер для конторы, очень волнует вопрос, на который мне никто не может ответить: есть два узла (вопросы кворума и фенсинга отбросим) с синхронной репликацией. Версия pg — 10. Ресурс агент — PAF. Синхронная реплика падает и мастер встает колом, т.к. ждет подтверждения получения транзакции. Можно ли как-то заставить ресурс агент менять тип репликации на асинхронный в таких ситуациях?
Как минимум не средствами pacemaker. Тип репликации выставляется в конфигах и ЕМНИП просит рестарта мастера для применения. Я, когда пилил кластер на постгресе, делал две реплики, из них для завершения транзакции достаточно было записать в одну, при этом мастер у меня не переезжал, так как был по факту кластерной ВМ. Хостов, кстати, было два тоже, конечный конфиг был мастер постгреса на кластере (на общем хранилище и поднимался средствами MS Failover Clustering) и две реплики, каждая на своем хосте на локальном хранилище. Может, у вас можно будет так же сделать, если есть ресурсы?
видимо, через две синхронные реплики и буду делать.
Мне видится что-то типа того: три машины в кластере. На всех трех postgres — один мастер, две синх. реплики. При этом я создам виртуальный ip для мастера и там же, где мастер будет pgbouncer для распределения читающих запросов на реплики.
Кластер будет назначать мастеров и слейвов, а также перевозить ip и pgbouncer в случае переезда мастера.
Из моей практики — даже если кластеризация сама справится с восстановлением все равно бежать придется и восстанавливать сбойный узел. И еще отчет готовить, почему отказоустойчивость деградировала на время сбоя того самого узла ;)

В любом случае спасибо за такое вводное описание.
Sign up to leave a comment.