PGConf.Russia 2024

Требования к безопасности данных постоянно растут, и многие пользователи сегодня ищут способ ограничить доступ администраторов СУБД к конфиденциальным данным. Стандартным подходом в форках PostgreSQL является наложение дополнительных ограничений на postgres/superuser. Мы в Postgres Pro использовали принципиально другой подход.

Мы долгое время катили релизы на базы данных руками. Но когда их количество стало больше 50, выкладывать релизы руками стало больно, даже при наличии скриптов. Стало понятно, что нужен какой-то инструмент. Так как готовые инструменты нам не подошли, мы решили написать свою систему на основе пайплайнов ci/cd в gitlab.

В результате получилась удобная система работы с кодом: - автоматические проверки практически не дают сделать что-то не правильно (plpgsql_check, авто-тесты и т.д.) - исключается возможность расхождения кода в живой БД и в репозитории - включает в себя несколько утилит (написанных на python), которые можно использовать как в пайплайнах, так и непосредственно из консоли - поддерживаются два режима раскатки релизов: по кнопке из gitlab и полностью автоматический (по ключевому слову auto_deploy в сообщении к коммиту)

В докладе будет рассмотрена функциональность файловой системы BTRFS позволяющая реализовать Snapshot Standby в работе с PostgreSQL. В первой части доклада будет поверхностно рассказано про BTRFS, а во второй части доклада будут рассмотрено несколько кейсов использования Snapshot Standby на примерах.

Расскажем об опыте миграции с Oracle Forms / Apex на платформу x86 Расскажем об опыте последующий миграции решений на Эльбрус e2k Расскажем об производительности / масштабируемости (БД/количестве пользователей)

На примере НПФ Корпорации "Ростех" / НПФ ПАО "Ростелеком"