как грамотно сделать высокодоступный кластер постгреса? для репликации решил использовать встроенную в постгрес streaming replication, но что делать с автоматическим failover'oм? гугл показывает, что его делают с помощью pgpool, но есть и много критики такого подхода и советов использовать тулзы из linux ha (pacemaker + corosync). что и почему выбрать?

выбрать linux ha потому что все остальное- это прямой путь к «мультимастеру»

@dmnord мастер будет ждать ответов от серверов, указанных в synchronous_standby_names, соответственно на слейвах поднимать эту переменную я бы не стал. Хоть вроде по докам каскадная синхронная репликация не поддерживается.

@dmnord мастер будет ждать ответов от серверов, указанных в synchronous_standby_names, соответственно на слейвах поднимать эту переменную я бы не стал. Хоть вроде по докам каскадная синхронная репликация не поддерживается.

По докам также написано, что когда сервер работает в режиме ведомого сервера, то этот параметр игнорируется

выбрать linux ha потому что все остальное- это прямой путь к «мультимастеру»

почему? встречаются же статьи, где через тот же pgpool делают мастер-слейв

Отвечаю на вопрос "что делать с failover-ом?": после выбора технологии долго и упорно развлекаться на кошках. Технологии: лучше linux-ha под линух найти весьма проблематично.

@neemore не надо читать статьи. Особенно про pgpool.

надо читать документацию по продуктам.

а repmgr же поддерживает им нельзя autofailover ?

Особенно внимательно раздел ограничений

а repmgr же поддерживает им нельзя autofailover ?

Можно

Я выше по чату описывал одну из реализаций автофайловера

По докам также написано, что когда сервер работает в режиме ведомого сервера, то этот параметр игнорируется

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

haproxy-pgbouncer-repmgr , тут вроде есть все что нужно для стендбая, и для автофейловера,

https://wiki.postgresql.org/images/a/a3/PGConf_US_2016-QuanHa.pdf

А серебряной пули как не было, так и нет. И не предвидится. А каждая задача решается далеко не одним способом. Добро пожаловать в мир опен сурса. :P

Ну я делал костыль как раз с haproxy... он стоит на сервере приложений, принимает соединения от приложух и проксирует соединения на мастер сервер.... мастера определяет по bgw-replstatus... логика свитчовера - автофайловера реализована repmgr (с witness нодой)... Но я бы очень не рекомендовал автофайловер делать... чтобы не попасть в "split brain"

Когда сделаете автофайловер - проведите простой тест - отключите сеть на мастере и дождитесь переключения.... а потом верните сеть (будет как раз split-brain). Это можно обойти... но очередным костылем

Собственно vrrp (и все реализации типа keepalived, heartbeat и прочего) при правильной настройке и постоянном мониторинге предпочтительнее... но все же не панацея

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

Если я правильно понимаю, постгрес начинает считать себя ведомым (резервным), как только в директории PGDATA появляется файл recovery.conf! верно?

Нет. корректный recovery.conf должен быть на момент запуска ПГ.

а witness нода от splitbrain не спасает?

а witness нода от splitbrain не спасает?

А что происходит с кластером когда она падает?

Не происходит переключение

То есть если сначала падает witness а потом мастер - просто ничего не происходит

Т.е. если мастер заизолировался и witness остался со slave'ом то slave promote'ится до мастера и получается изолированный сегмент со старым мастером и широкий сегмент с новым мастером?

не промоутится наверно, написали ж ничего не происходит

а нет, перепутал, это ж если витнес падает

Т.е. если мастер заизолировался и witness остался со slave'ом то slave promote'ится до мастера и получается изолированный сегмент со старым мастером и широкий сегмент с новым мастером?

Да

И это проблема. Я писал костыль - в виде скрипта который гасит старый мастер когда он становится доступен

изолировать надо хост целиком иначе при одностороннем сетевом взаимодействии возможны нюансы в видел «мультимастера»

И это проблема. Я писал костыль - в виде скрипта который гасит старый мастер когда он становится доступен

Он же не "становится" доступен. Он "остаётся" доступен

Он же не "становится" доступен. Он "остаётся" доступен

Ну как остается - если учесть что приложение смотрит на него через haproxy

народ а в ПГ есть возможность притянуть табличку из другой удаленной базы по аналогии с никнеймами в db2?

есть, postgres_fdw называется

спасибо

как грамотно сделать высокодоступный кластер постгреса? для репликации решил использовать встроенную в постгрес streaming replication, но что делать с автоматическим failover'oм? гугл показывает, что его делают с помощью pgpool, но есть и много критики такого подхода и советов использовать тулзы из linux ha (pacemaker + corosync). что и почему выбрать?

Посмотрите архитектуру Patroni. Обходит все вопросы по изолированности мастера, и даже ДЦ (если есть кворум из ДЦ)

Посмотрите архитектуру Patroni. Обходит все вопросы по изолированности мастера, и даже ДЦ (если есть кворум из ДЦ)

что происходит когда дц с мастером станет изолированным а два других будут видеть друг друга? fencing хоста с мастером имеется?

Изолированный мастер перейдет в read-only. Остальные выберут мастера, другой к ней присоединится

Изолированный мастер перейдет в read-only. Остальные выберут мастера, другой к ней присоединится

не бывает тут ситуации когда старый мастер не переключился в readonly и мы получаем два мастера?

Нет, не должно

Нет, не должно

Отказоустойчивость обвязки над patroni - haproxy, pgbouncer и etc... как реализована?

как две другие ноды понимают что ресурс на третьей будет точно недоступный при изменении состояния на слейве?

promote slave to master не должен осуществлятся до тех пор пока старый мастер точно не будет выключен из игры

изменяя свое состояние две оставшиеся ноды с большой долей вероятности приведут к «мультимастеру»

Отказоустойчивость обвязки над patroni - haproxy, pgbouncer и etc... как реализована?

У Pgbouncer прописано db_master = host=127.0.0.1 port=5000 У HAproxy прописано HTTP CHECK Patroni port /master Если чек не проходит (patroni отдает 503), то URI db_master недоступна

promote slave to master не должен осуществлятся до тех пор пока старый мастер точно не будет выключен из игры

Да, именно, как только нет мастера, остальные начинают голосование

Координацию обеспечивает кворум из кластера etcd

не изолируя третью ноду

непонял

изменение состояния происходит без fencing третьей ноды?

С, но так как до нее не достучаться и нет замка мастера, то происходит выбор нового

А, fencing это ограничение (сори за мой инглишь)

ее необходимо изолировать и после изменять состояние двух других

изоляция больше подходит

от слова изгородь

если fencing тоже не проходит то делать promote до мастера это путь к мультимастеру

при невозможности fencing состояние системы должно оставаться тем же

Смотри. Есть кластер etcd - он обеспечивает согласованное состояние. Он находится во всех 3 ДЦ Если один ДЦ вылетает, то нода etcd теряет кворум. К ней (так как другие уже недоступны) обращается Patroni, ничего с ней сделать не может и производит demote. Его замок мастера истекает по TTL и остальные живые ноды бд начинают голосование

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

У Pgbouncer прописано db_master = host=127.0.0.1 port=5000 У HAproxy прописано HTTP CHECK Patroni port /master Если чек не проходит (patroni отдает 503), то URI db_master недоступна

pgbouncer расположен на хосте с БД?

картинки - https://github.com/zalando/patroni/blob/master/docs/ha_loop_diagram.png

pgbouncer расположен на хосте с БД?

Нет, на отдельных хостах с exaBGP. Но может точка входа быть и на хостах бд, архитектуры это не меняет

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

дц может быть мертвым для других дц но это не значит что он мертвый совсем. и на других дц ,принимая решение об изменении состояния мы получаем неопределенность

у решения патрони есть fencing? если нет что вмнем есть в качестве замены?

Нет, на отдельных хостах с exaBGP. Но может точка входа быть и на хостах бд, архитектуры это не меняет

Где расположен haproxy? Как он защищен от падения?

дц может быть мертвым для других дц но это не значит что он мертвый совсем. и на других дц ,принимая решение об изменении состояния мы получаем неопределенность

1) Если связь между ДЦ работает (etcd, pg), но снаружи - нет, тогда 30% трафика будет проливаться и запись в мастер работать не будет 2) Если связь между ДЦ не работает (etcd кворум пропадет), но снаружи - да, тогда произойдет смена мастера

Где расположен haproxy? Как он защищен от падения?

рядом с pgbouncer. haproxy не резервирован, практически он не падает. На крайняк systemd поднимет

рядом с pgbouncer. haproxy не резервирован, практически он не падает. На крайняк systemd поднимет

У app серверов в конект стринге прописаны три ip от трех ДЦ?

Нет, единая точка входа, управляемая exaBGP. То есть это всего один IP адрес, который маршрутизируется в зависимости от сетевого нахождения клиента. Если один из хостов в любом ДЦ отваливается, маршрут перестраивается

как быть уверенным что маршрут перестроился?

есть возможность понять что маршрут изменился и можно. енять состояние?

если есть то это есть одна из форм феесинга

если нет это надежда на лучшее

как грамотно сделать высокодоступный кластер постгреса? для репликации решил использовать встроенную в постгрес streaming replication, но что делать с автоматическим failover'oм? гугл показывает, что его делают с помощью pgpool, но есть и много критики такого подхода и советов использовать тулзы из linux ha (pacemaker + corosync). что и почему выбрать?

для начала посмотреть на готовые решения типа stolon и patroni

для начала посмотреть на готовые решения типа stolon и patroni

чем они более лучшие чем ha от cluster labs?

ну как минимум тем что не работают с коросинком и пейсмейкером

это вообще пушка

Corosync, Pacemaker, DRBD

инструкция по острелу себе всех конечностей

инструкция по острелу себе всех конечностей

пруф?

а мне надо?

а мне надо?

понятно

когда развалится твой кластер игрушечный на всём этом отвечать будешь ты, я то причём? зачем мне тебе что то доказывать?

как быть уверенным что маршрут перестроился?

Также как и быть уверенным что в России станет жить хорошо. И загневающая европка наконецто загнеет. И что КНДР запустит ракету а не попросит у США вагон пшеницы

как быть уверенным что маршрут перестроился?

А, еще вспомнил. Так же как быть уверенным что TCP пакет придет к нужному IP а не левому

когда развалится твой кластер игрушечный на всём этом отвечать будешь ты, я то причём? зачем мне тебе что то доказывать?

понятно, по существу сказать нечего.

еще раз спрашиваю?

Также как и быть уверенным что в России станет жить хорошо. И загневающая европка наконецто загнеет. И что КНДР запустит ракету а не попросит у США вагон пшеницы

аналогично

Это как раз по существу. Это технологии прошлого десятилетия

спасибо за разъяснения

ну я тогда убираю свой длинный аргумент

бездоказательность -это прекрасно, всегда можно соскочить от прямого обоснованного ответа

ты сейчас просто защищаешь решение которое, вероятно, взял в продакшен ты точно так же без доказательств и почему то предложил доказывать тебе

как быть уверенным что маршрут перестроился?

cнимай таблицу маршрутиризации с роутера

я его не защищаю, где это было написано? я задавал конкретные вопросы как организовани фенсинг