Комментарии 6
Очень неожиданно получить в статье от PGPro заявление о том, что PGBackRest это самое лучшее и устойчивое решение в плане бэкапов.
В докладе шла речь исключительно про ванильный постгрес. Конечно, наши продукты - самые лучшие :), и наш опенсорсный пробекап тоже хорош, но, увы, в нем присутствует далеко не вся функциональность, которая есть в wal-g или pgBackRest, например, нет поддержки S3. Поэтому, в разрезе эксплуатации ваниллы, пробекап покрывает не все потребности.
А что вы скажет про Pacemaker?
Конфигурация с peers решает эту проблему: ядро распределяет входящие соединения между слушающими сокетами, при получении cancel проверяет идентификатор сессии и отправляет «отмену» правильному бэкенду.
Такая конфигурация может решить проблему notify через pgbouncer в режиме транзакций?
Краткий ответ - нет.
Смотрите, peers решает узкую проблему, а именно корректную доставку "отмена" в тот баунсер-процесс, через который была установлена исходная серверная сессия. Как я в статье и написал, это нужно, когда у вас несколько баунсеров за одним адресом или с SO_REUSEPORT, и запрос на отмену может попасть не в тот процесс. Документация баунсера прямо говорит, что этот механизм нужен именно для пересылки запросов отмены между peer-ами.
Проблема же LISTEN/NOTIFY в транзакционном режиме другого класса. Соединение привязывается к клиенту только на время транзакции, а потом возвращается в пул. Из-за этого состояние сессии в случае listen/notify ломается.
В матрице совместимости баунсера (https://www.pgbouncer.org/features.html) для транзакционного режима указано: LISTEN "Never", а NOTIFY "Yes". NOTIFY можно слать и через transaction pool, но принимать взад события – нет.
Есть компромиссный вариант. Можно оставить основной трафик в транзакционном режиме, а для listener/notification выделить отдельный сессионный пул, ну или прямое соединение.
Но тут такое себе, на мой взгляд, надо специально закладываться на это на стороне приложения, для чего должны быть веское основание, зачем это нужно.
А ну и про CS/PM, отличное решение, проверенное временем, работает там, где Python не может быть использован. Например, по соображениям безопасности, уязвимости в коде Patroni имеют место быть, и ваша ИБ может запросто Patroni завернуть.
У CS/PM больше порог входа, он сложнее в администрировании и понимании, но решение более чем рабочее.
Как построить отказоустойчивый PostgreSQL-кластер и не промахнуться