00:06 CPU 12%, а платежи не проходят
Ошибок в логах нет, база выглядит здоровой, но API отвечает таймаутами. Тесты пройдены, а на проде начинается «магия».
04:50 ALTER TABLE как перестройка дороги
Пока таблица перестраивается, запросы встают в очередь, и API начинает отвечать всё медленнее — как пробка при ремонте дороги.
06:25 lock_timeout спасает миграцию
Задайте лимит, например 300 мс: не успела миграция — она откатывается, и её можно повторить, когда нагрузка спадёт.
09:00 Зачем нужен PgBouncer
Каждое соединение с Postgres — отдельный процесс, который ест ресурсы. PgBouncer работает как каршеринг: соединения берут в аренду и возвращают.
Session держит соединение весь сеанс и почти не даёт выигрыша. Transaction отдаёт его после каждой транзакции. Есть ещё statement.
11:16 Машина со сбитыми настройками
В режиме transaction настройки соединения, например statement_timeout, достаются следующему клиенту. Их нужно сбрасывать в PgBouncer или держать внутри одной транзакции.
13:32 Как pgAdmin сломал запись
pgAdmin выставил на соединении режим «только чтение», и следующие запросы через пул начали падать с 500-ми ошибками.
14:21 WAL — git для базы данных
Журнал всех изменений: на нём строятся репликация, CDC, бэкапы и point-in-time recovery — откат базы на нужный момент.
17:18 DELETE не удаляет данные
Строки только помечаются. VACUUM их вычищает, но место системе не возвращает, а VACUUM FULL для этого блокирует все запросы.
18:56 Безобидный DELETE FROM outbox
Удаление событий с огромными JSON за месяц заняло память, нагрузило CPU и положило реплики, которые не успевали применять WAL.
22:22 Удалять маленькими порциями
Большие объёмы удаляйте чанками: между ними проходит VACUUM, и память освобождается для следующей итерации.
Два робота на конвейере ждут детали друг от друга. Так же зависают две транзакции, которые обновляют одни и те же балансы в разном порядке.
24:05 Единый порядок ресурсов
Если все транзакции сначала обновляют первый баланс, а потом второй, взаимной блокировки не возникает.
25:12 Почему ИИ этого не подскажет
ИИ не видит контекста прода: данные растут, настройки PgBouncer меняются, и вчерашние 300 мс сегодня уже не работают.
26:24 Четыре вопроса перед выкаткой
Прежде чем катить ИИ-код в базу, спросите: как это повлияет на время запроса, какой объём ожидается, будут ли конкурентные запросы и какое состояние нужно в итоге. Упавшее приложение перезапустится, а упавшая база положит всё.
Мастер и две реплики на чтение под управлением Patroni, алерты на WAL и CDC для событийной архитектуры.
Postgres — OLTP-база, и частые апдейты создают очереди. Для платежей лучше подходит ledger: записи только добавляются, без изменения.