Comments 8
Спасибо за доклад, пост.

Дело в том, что дефолтный конфиг PostgreSQL предназначен для того, чтобы запускаться на самом слабом чайнике.
Минус для PostgreSQL, но другой стороны это обеспечивает работу для DBA.

Следующий шаг — балансировка. У нас по-прежнему остается та самая строчка в конфиге, которой оперирует разработчик. Ему нужно место, куда он будет писать и читать. Здесь есть несколько вариантов. DNS Round Robin, Keepalived, HAProxy, Patroni, DCS

Разве эти инструменты позволяют из коробки читать с Slave даже? Даже если и использовать, то в них нужно писать отдельную логику чтобы публиковать IP Slave. Это может потянуть на отдельный пост.
Минус для PostgreSQL, но другой стороны это обеспечивает работу для DBA.

Можно воспользоваться калькулятором первичных настроек

Разве эти инструменты позволяют из коробки читать с Slave даже? Даже если и использовать, то в них нужно писать отдельную логику чтобы публиковать IP Slave

Для только чтения будет отдельный эндпоинт. Это надо учитывать в приложении. Никакого разбора запроса на предмет read-only в промежуточных слоях не будет.
Не изобретайте самописные очереди, используйте Skytools PgQ!

А почему нельзя использовать внешние очереди? Ту же Kafka, nats.io, ActiveMQ и т.д.?
Можно, но в этом случае транзакция на запись в основную таблицу и изменение в стороннюю очередь будет распределённой. Использование внутренних очередей позволит обеспечить атомарность таких операций достаточно низкой ценой
Есть еще одно распространённое заблуждение — что Postgres подобно MySQL создает индексы при задании ссылочной целостности. Это не так. Поэтому запросы с JOIN если дополнительно не создать индекс по внешнему ключу будет проходить не оптимизированным.
Only those users with full accounts are able to leave comments. Log in, please.