PGConf.Russia 2024

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

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

В докладе представлен обобщённый опыт компании ЕДИНЫЙ ЦУПИС в вопросах оптимизации OLTP-запросов: • Как идентифицировать причины перегрузки сервера. • Какие настройки помогают улучшать планы и ускорять запросы, которые и так работают быстро. • Как лучше подготовить индексы и сами запросы. Также будут рассмотрены различные примеры деградации производительности из практики.

Инструмент Ora2PgCopy представленный на PgConf.Russia-2023 (https://pgconf.ru/talk/1589503) получил новое развитие и дополнен новым средством для инкрементальной миграции данных Ora2PgSync. В докладе рассматриваются следующие стадии процесса переноса данных большой БД: - многопоточная миграция данных (в том числе со сжатием при передаче по медленной сети) - создание индексов и ограничений целостности - инкрементальная миграция изменений данных после переноса основного объёма. Особое внимание уделяется обработке нештатных ситуаций с целью предотвращения полного повторения сценария миграции данных. Представлено несколько способов обеспечения равномерного и полного использования вычислительных ресурсов в течение всего времени отведённого на перенос БД. Обсуждаются проблемы инкрементальной синхронизации БД Oracle и PostgreSQL: - Почему надо анализировать все транзакции в Oracle, а не только зафиксированные - Что происходит, когда в Oracle один оператор delete удаляет 1млн. строк.

Сейчас у нас есть задачи разных классов, которые решают разные продукты, но, если "копнуть" глубже, эти продукты одного класса и решают много однотипных задач. После того, как мы представили на рынок встроенную отказоустойчивость (BiHA),мы решили продолжить модернизацию наших кластреных возможностей, которые работают "из коробки".

В данном докладе сделаем краткий обзор базовых технических требований к новой функциональности PostgresPro Enterprise, которая появится в 17 версии.