Помогите в выборе решения для кластера postgresql

pgpool

Не используй его.

Бери обычную нативную репликацию в одну руку, barman для бэкапов - в другую руку и всё у тебя будет хорошо.

А что понимается под обычной репликацией? Это она реализована в последних версиях или она всегда там была?

Если для тебя «последние версии» - это версии начиная с 9.0 (выпущено в 2010 году), то да.

Да кое-что изменилось, но пока не идеально. Что-то близкое к иделу вроде обещают в версии 9.10. На данный момент самым простым и достаточно надежным является BDR в версии 9.4 но только всеравно нужно патченую ставить от разработчика. Недавно настроил Multi master из 3х нод. Пока работает очень даже нелохо. Там правда есть одно неприянтное ограничение, последовательности с автоинкрементом не работают, поэтому нужно использовать uuid. Ну и некоторые некритичные вещи не реплицируются. А со всякими postgresql-xl и т.п. там все слишком сложно ИМХО. Разобраться конечно со всем можно, но вот времени уйдет довольно много.

Судя о текущем положении BDR на официальном сайте, выходит то, что версия 1.0.0 уже полностью объеденена с основным кодом postgresql в версии 9.4. А значит версию 9.5 можно смело использовать без всяких патчей. Но меня немного смущает слово «асинхронный». Получается ты перечислил проблемы как раз-таки в случает с асинхронным master-master?

Ситуация такая.

Есть куча форков PG под разные цели, но нет конечного решения. Свести все задумки планируют в PostgreSQL 10.0. Когда он выйдет и что там будет никому не известно, все только на стадии обсуждения.

Я в своей компании построил кластер на основе:
Patroni - https://github.com/zalando/patroni
Pgbouncer
Haproxy
etcd
confd
PostgreSQL 9.6
pgBackRest
saltstack

Будут вопросы, задавай, что не по NDA, отвечу.

Ты типы конфликтов видел - http://bdr-project.org/docs/stable/conflicts-types.html Как оно вообще может нормально работать?

Да. Но синхронный походу имеет почти теже грабли, только работает намного медленнее.

А не мог бы ты пояснить, по каким критериям ты выбирал между pgbouncer и pgpool2? Сразу другой вопрос - какой именно тип репликации используется (асинхронный, синхронный или BDR)?

По поводу confd и etcd, я понимаю, что там моменты специфичные под вашу конкретную архитектуру. А потому не буду ничего спрашивать, хотя интересно не менее.

Критерий производительности. Так как логика не нужна. И вообще pgpool монструозен.

Репликация асинхронная - деньги не пишем.

Да, специфичное, etcd потому что простое k/v хранилище. confd просто по темплейту конфигурирует сервис

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

А жизнеспособна ли реализация postgres-xl, на твой взгляд? Смотрю в его сторону, но с оглядкой на традиционную синхронную репликацию.

Не работал.
Смотрел видео (не смог найти) с Сигаевым и Бортуновым, где они рассказывали о различиях форков постгреса и что будет в 10.0 относительно их. Короче в форках не все гладко и деньги там считать точно не стоит. И из всех форков нет конечного решения, которое бы покрывало все недочеты у других форков

Вот видео с лекции, в конце там о 10.0 https://youtu.be/w-dtKpzFFis?t=1h30m19s

Нашел. Там видео чуть ниже

https://habrahabr.ru/company/oleg-bunin/blog/312494/

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

Опыта такого нет. Если ты про OLTP так и гугли. Если просто надо чтоб не потерялись зафиксированные транзакции, тогда используй ванильный постгрес и синхронную репликацию. Причем в 9.6 сделали возможность использовать более одной синхронной реплики и даже установить условие, что их должно быть определенное кол-во - это все добавляет надежности.

В 10.0 будет уже «честная» синхронная репликация, там будет функция подтверждения на синхронной реплике конкретно и только надежной записи транзакции. Без лишних условий.