PGConf.Russia 2021

Без резервного копирования эксплуатация PostgreSQL недопустима. Постоянный рост количества кластеров PostgreSQL в эксплуатации создает всё новые и новые проблемы и вскрывает узкие места в выбранной схеме резервного копирования. Мы обсудим наш опыт эксплуатации pg_probackup в этих условиях.

Когда PostgreSQL только появлялся, значения идентификатора транзакции были выбраны 32х-битными. В то время это казалось запредельным числом - кто в здравом уме будет проводить 4 миллиарда транзакций? Но развитие техники привело к тому, что появились инстансы, где транзакции подбирались к этому пределу. Сообщество разработчиков ответило на это возможностью "оборота" счетчика транзакций (известный как wraparound). Но технический прогресс и рост количества данных поставили PostgreSQL перед новыми вызовами. В докладе я попытаюсь рассказать об этих вызовах, о том, как их можно преодолеть с помощью повышения разрядности счетчика, к каким следствиям это приведет и почему это надо делать сейчас, и почему это не было сделано раньше.

PostgreSQL можно смело назвать повелителем индексов, по количеству разных типов индексов ему нет равных. Но как эти индекс использовать наиболее эффективно разработчику? Когда нам требуется создавать тот или иной индекс? А когда созданный нами индекс будет ухудшать производительность? Попробуем разобраться в этом на понятных жизненных примерах.

Поговорим о наших подходах к выбору технических решений при проектировании архитектуры систем. Их преимущества и ограничения. Как менялась наша инженерная культура с учетом требований импортозамещения. История миграции системы с классической трехзвенной архитектурой с БД Oracle на PostgresPro. Большое внимание уделено инструментам переноса данных, а так же нюансам доработки Java/Kotlin приложений и совместимости SQL между двумя СУБД.