PGConf.Russia 2023

Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.

В докладе расскажем, как нам удалось решить этот кейс.

Доклад о нашем опыте внедрения PostgreSQL вместо Oralce в высоконагруженную систему с микросервисной архитектурой, обрабатывающую несколько террабайт данных. Расскажем о том, как прошли путь от пилотирования Greenplum до перехода на несколько взаимодействующих баз PosgreSQL с разными профилями нагрузки, и о проблемах, с которыми столкнулись в процессе.

Каждый администратор баз данных так или иначе сталкивался с тем, что таблицы и индексы в PostgreSQL иногда могут значительно увеличиваться в размерах. Зачастую поиск причины такого роста приводит нас к выводу, что объекты "раздулись". В докладе мы поговорим о причинах такого поведения, подготовим тестовую среду для определения того какой же метод борьбы с блоатом является самым подходящим. Сравним несколько утилит по борьбе с блоатом, а также познакомимся с ещё одним инструментом, который позволяет нам бороться с этим явлением более эффективно. Этот доклад будет полезен как начинающим, так и опытным администраторам PostgreSQL.

Расскажу о частых ошибках при настройке отказоустойчивого кластера Corosync-Pacemaker. Зачастую эти ошибки приводят к фатальным последствиям, и как следствие - к отказу от выбранного решения в пользу других. Хотите рецепт "правильного" кластера?