На чем делать кластер postgres?

Question

[rinokonli]

Здравствуйте! Есть сервис работающий на базе postgress....
Сервис общается с базой по API только через хранимые процедуры.

Т.е нет прямых запросов к базе вида SELECT и тд . Все запросы зашиты в процедурах.

Как организовать отказоустойчивый кластер? master-master или что лучше в этом случае?
есть ли смысл разделять процедуры на чтение и запись,
в хранимых процедурах есть запросы на чтение и запись

Answer 1

[Melkij]

Для начала задаёте себе и отвечаете на вопрос "зачем?"
Потому что геморроя, проблем и граблей очень много. Бонусы - сомнительны. Основной пласт проблем - как решить, что пора переключать мастер на другой хост, а не вернётся старый мастер из-за недолгого (а то и вовсе планового) лага сети? Это организационный вопрос и автоматикой он не решается. Самое счастье с автоматикой - схлопотать split brain и получить на этом долгий и увлекательный квест "как бы разъехавшиеся данные теперь подружить воедино"
мастер-мастер = головная боль перманентно. Потому что фундаментальная CAP теорема, которую никто пока внятно не решил. Или у вас проблемы с консистентностью или с медленной из-за распределённых транзакций записью.

Автоматика для failover'а, которую я не придумал как спровоцировать на split brain - patroni. Вроде работает. Но в продакшене видел пока только однажды.

Процедуры (да и вообще запросы) имеет смысл делить:
- пишущие. Любые, какие что-то пишут в базе (включая create temporary table). Это должны роутиться строго на мастер
- читающие. Идут на реплики
- долго читающие. Идут на отдельные slow реплики, которые могут заметно отставать от мастера, но которые не будут мешать деятельности проекта

Comments

[rinokonli]

Спасибо за ответ!
вопрос: если делать репликацию наподобие https://wiki.postgresql.org/wiki/Streaming_Replication
мастер-слейв1-слейв2-слейв3-слейв4

разделить процедуры которые пишут или читают и направлять их соответственно на один мастер или слейвы.

Значит каждая нода postgres базы должна хранить всегда одинаковый набор процедур.

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

Верная логика?

[Melkij]

Поясните, я не понял зачем вам изменять процедуры при failover.
Для потоковой репликации все реплики являются идентичными мастеру, даже бинарно идентичными. С потоковой репликацией вы в принципе не можете сделать разные хранимки на мастере и слейвах. Разница только в том, что на слейве пишущая хранимка вернёт ошибку что невозможно что-то писать в readonly базе. И при failover мастера вам необходимо проинструктировать приложение о том, на какой хост необходимо отправлять пишущие запросы. Впрочем, это можно сделать силами например haproxy, который будет простым скриптом опрашивать хосты на select pg_is_in_recovery() - кто ответил false тот и есть мастер.

[rinokonli]

понятно, то есть оптимальное решение с failover такое что надо приложению обращаться всегда к одному ip на haproxy но с делением на порты
1111 - запись
2222- чтение
дальше haproxy будет сам направлять куда нужно.

Т.е в приложении нужно обязательно разделить типы процедур на чтение и запись и дальше направлять на разные порты haproxy

[Melkij]

Разделять запись от чтения правильнее именно на приложении. Потому что именно приложение знает, будет ли операция что-то модифицировать и насколько критична актуальность данных. Может быть и 100% читающий запрос, который можно вызывать только на мастере. (например, потому что ставить ещё и синхронную реплику оказалось для проекта хуже)