Друзья стоит задача если с одной базой что-нибудь случится , чтоб можно было переключится на другую. Информация должна быть обязательно синхронная.
Можно сделать кластер с такой схемой где одна база будет активная ,а вторая пассивная + потоковая репликация с отдельным хранилищем для репортов:


Также думал сделать потоковою синхронную реплику Master -> Slave -> Slave (резервной чтоб при сбое первого слеива мастер не тупил) ,но сказали что хранилище стоит дорого и можем на данный момент купить только два.

Посмотрел в сторону Pgpool-II с такой схемой :


прочитал что если рухнет один сервер то второй обычно продолжает работать,насколько надежна такая схема ?
И какую бы вы посоветовали для данной задачи? (не обязательно из тех которые я написал,с удовольствием услышу ваши варианты)

Нагрузка на базу будет не большая в ближайшие 5 лет пик будет 600-700 транзакций в секунду.

hydrobiontNewBie77,

Требование синхронности как правило находится в противофазе с требованием высокой доступности.

Устроит синхронность только на 3-4 таблицы (т.к платежные системы важня каждая транзакция) , приемлемо если будет 5-10 минут система отключена при переключении на другую базу. Нам важно не потерять транзакцию при переключении.

hydrobiont,

Я имел ввиду 5-10 минут если мастер рухнет, а если транзакция зависнет на 5-10 минут это очень очень плохо . Интересно если вы использовали pgPool насколько он стабилень ?

hydrobiont,

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

hydrobiontNewBie77,

Для начала просто реплика мастер-слэйв, возможно синхронная. На каждой машине с базой по pgbouncer, куда ходить определяет приложение. Скрипт прибивает на мастере транзакции аномальной длительности (длительность подбирется)

Если он найдет транзакцию аномальной длительности как поступать ? Мне нужно их как-то закомитить.

[quot hydrobiont]NewBie77пропущено...


Если у вас упал мастер, то транзакцию закомитить можно только при помощи спиритического сеанса и черной магии - чем она закончилась неизвестно и приложение может обработать ситуацию только как исключение - транзакция не прошла.

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

Понятно с репликой спасибо, а вот схему с общим хранилищем(актив/пасив) и с асинхронной репликой нельзя в постгресе сделать?

[quot hydrobiont]NewBie77пропущено...


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

Огромное спасибо за ваш совет и потраченное время.

В сторону Pgpool глядеть не советуете да ?

qwwq,

не лень прочту )

мне посоветовали на одной странице фб такую схему : Postgresql + Repmgr + Barman
кто-нибудь использовал ?

qwwqNewBie77,

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

но, как выяснилось, это тоже иногда не работает -- когда уже в полном масштабе натыкаешься на нежданчики (как напр. в 19876722 ), не покрытые тестами при макетировании

Я все еще думаю над сценариями , мне нужен failover на идентичные данные иначе например у меня есть клиент у кого на депозите лежит 10к , он заплатил что-нибудь например за 1к мастер закомитил транзакцию и рухнул, реплика не успела забрать данные при failover у меня на реплике депозит будет 10к вместо 9к это уже проблема , интересно как другие решают такие проблемы при асинхронной реплике, для меня единственный вариант чтоб такой проблемы не было это синхронная реплика.

Клиент у нас с базой работает через Jboss где настроен pooling,имеет смысл установить по pgbouncer-у бд ?

DPH3NewBie77Клиент у нас с базой работает через Jboss где настроен pooling,имеет смысл установить по pgbouncer-у бд ?
Если у вас только один сервер обработки - то не обязательно. Если к БД обращается несколько сервисов, то pgbouncer обязателен.

Но есть у меня подозрение, что если вы делаете платежную логику на jboss (и, подозреваю, через JPA) и рассчитываете на 500+ транзакций в пике, то ничего не взлетит. Впрочем, нужно на всю архитектуру смотреть.

Да через JPA, наш сениор обещяет что взлетит (сам сомневаюсь) скоро будут первые тесты ,посмотрим.