Pgpool-II работа в режиме "Master-Master" или Как должна выглядеть балансировка нагрузки PostgreSQL глазами сетевого инженера.

Одна из базовых задач для высоконагруженных проектов – это «правильно» настроенное распределение нагрузки внутри кластера базы данных (балансировка), которое бы отвечало определенным параметрам SLA. Большинство решений, с которыми я познакомился, в том числе и Pgpool-II, не в полной мере могли соответствовать требованиям бизнеса. Руками и глазами сетевого инженера мы попытаемся улучшить решение от Pgpool-II и настроим его работу в режиме «Master-Master», а так же рассмотрим случаи, в которых без аналогичных решений не обойтись.

Гетерогенная распределенная система – как способ безопасного перехода с MSSQL Server на PostgreSQL, а также снижения санкционных рисков

Данный доклад предназначен в первую очередь для компаний, а точнее для их ИТ служб, эксплуатирующих российские системы 1С 8.х и имеющих возможность работать как на СУБД MSSQL Server, так и PostgreSQL. Мы живем в уникальное время, когда наличие в своем арсенале гетерогенной ИТ-системы (системы, имеющей распределенную архитектуру, где каждый экземпляр базы данных работает под управлением разных СУБД и/или имеет разную структуру данных) является оправданным как с экономической точки зрения, так и с учетом возможных рисков. С одной стороны, мы храним данные и пользуемся СУБД с предсказуемым поведением и открытым кодом, независимо от политической обстановки. С другой стороны, мы при таком подходе пользуемся всеми преимуществами (в первую очередь производительности) мощной СУБД поддерживаемой крупнейшим вендором пускай и недружественного нам государства. Именно сейчас необходимо оценивать риски с необходимым уровнем паранойи. Возможно ведь, что данные могут быть испорчены не только на уровне логики хранения, но и методом дополнительного «скрытого» вызова конструкций типа Delete/Update на уровне движка СУБД. Поэтому сейчас актуальным становится не только мониторинг производительности ИТ-системы, но и аудит данных и их своевременная сохранность. Необходимо реализовывать процедуры верификации данных, необходимо реализовывать процедуры закрытия периодов, процедуры отказоустойчивого хранения. И соответственно, предусматривать в процедурах восстановления данных различные модели угроз. В докладе представлены варианты противодействия подобным угрозам и сценарии максимально бесшовного перехода больших баз данных на PostgeSQL, ведь именно для подобных баз проблема перевода на новую СУБД стоит особо остро.

pgCodeKeeper - инструмент для организации современного процесса разработки БД

Современные языки программирования “из коробки” предоставляют удобные средства по организации процесса разработки, тестирования и доставки изменений. Но как быть если хочется тех же возможностей при разработке структуры БД и кода хранимых процедур и функций?

В докладе я расскажу о созданном нами инструменте для работы с кодом внутри БД. И как на его основе мы организовали процессы разработки баз данных с автоматическим тестированием и автоматической доставкой изменений на боевые экземпляры баз данных.

Вакуумотерапия: лечим хронические заболевания БД

После импортозамещения и перехода с СУБД Oracle на PostgreSQL мы столкнулись как с "детскими" болезнями нашего приложения на новой СУБД, которые успешно вылечили, так и с "хроническими заболеваниями", с которыми пришлось разбираться существенно дольше. Одной из наиболее запомнившихся проблем стала проблема деградации производительности, которая, как выяснилось, была вызвана недостаточным вакуумированием нашей БД. Опыт осознания и решения этой проблемы предлагается вашему вниманию в виде практических рекомендаций по борьбе с эффектом bloat для таблиц и индексов БД, а также настройке VACUUM/autovacuum PostgreSQL.