Топ ошибок со стороны разработки при работе с PostgreSQL

[chemtech]

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

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

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

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

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

[maksm]

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

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

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

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

[zqqraa]

Не изобретайте самописные очереди, используйте Skytools PgQ!

А почему нельзя использовать внешние очереди? Ту же Kafka, nats.io, ActiveMQ и т.д.?

[maksm]

Можно, но в этом случае транзакция на запись в основную таблицу и изменение в стороннюю очередь будет распределённой. Использование внутренних очередей позволит обеспечить атомарность таких операций достаточно низкой ценой

[vtc]

Есть такой же вариант статьи но про MySQL?

[olegbunin]

Нет, но попрошу Percona сделать такой доклад.

[debug_everywhere]

Короче я понял, хочу к вам админом (инстансы, деплой, конфиги, cl_righthand «0»)…

[apapacy]

Есть еще одно распространённое заблуждение — что Postgres подобно MySQL создает индексы при задании ссылочной целостности. Это не так. Поэтому запросы с JOIN если дополнительно не создать индекс по внешнему ключу будет проходить не оптимизированным.