PGConf.Russia 2022

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

Катастрофоустойчивый кластер (КУК) подразумевает небольшую потерю данных при катастрофе основного Дата-центра (ДЦ) и переключении на резервный. Это обусловлено асинхронной репликацией между основным и резервным ДЦ. Но есть решение, которое позволит исправить эту ситуацию - обеспечить нулевую потерю данных при катастрофе основного ДЦ. Об этом решении и пойдет речь в моем докладе.

Облачный провайдер оперирует большим количеством железных ресурсов и сетевых сущностей. Но одно дело, когда компания запускает десятки инстансов БД в изолированном контуре для внутренних задач. Совсем другое — когда облачный провайдер предоставляет услуги b2b-пользователям и создает сервис для 500+ крупных компаний.

Виталий расскажет, как сейчас работает Managed PostgresPRO у облачного провайдера VK Cloud Solutions, покажет архитектуру решения и расскажет о сложностях, с которыми столкнулись при создании продукта.

В архитектуре PostgreSQL есть ряд особенностей, которые стоит учитывать не только при эксплуатации БД, но и в процессе проектирования схемы данных. Опытным пользователям PostgreSQL хорошо известен такой механизм как очистка/заморозка(vacuum). На просторах интернета есть большое количество материалов на тему внутреннего устройства, настройки и мониторинга. Множество полезных докладов было сделано на конференциях. Тем не менее, все еще происходят случаи переполнения счетчика транзакций(xid), казалось бы, в достаточно небольших БД. В этом докладе я расскажу об одном интересном, на мой взгляд, случае у нашего клиента. Поделюсь тем, как череда ошибок на разных этапах жизненного цикла БД, однажды привела к ее полной остановке более чем на неделю, wraparound-у, битым блокам, проблемам с обслуживанием и бессонным ночам в поисках решения. Локальная победа была достигнута - БД удалось восстановить, но история еще не закончена. Тем она и интересна.