Историко-статистический взгляд на сообщество PostgreSQL

В первой части своего доклада расскажу о некоторых моментах из истории PostgreSQL-сообщества (например, про русского Слоника на логотипе).

А во второй части покажу интересную статистику про сообщество и расскажу (используя информацию о коммитах в GIT и с сайта commitfest.postgresql.org) сколько патчей предлагается на коммитфестах и сколько из них принимается; в какие дни недели и в какое время происходит фиксация патчей; кто из авторов патчей являются самыми активными; и наглядно посмотрим на некоторые из интересных тенденций развития сообщества.

Мониторинг и алертинг большой инфраструктуры

С каждым днем объемы данных, количество инсталяций, обслуживаемых систем приумножается. Зачастую можно проследить даже геометрическую прогрессию. Вопросы инпортозамещения, требования регулятора, новые проекты - все это форсирует развитие Postgres. Такие реалии ставят перед нами амбициозные цели слежения за соблюдением SLA, качественный мониторинг, дашборды по критичным элементам производительности систем. Поделимся нашим опытом и наработками в рамках Tinkoff.

Слон и Моська. Проблема фенсинга в кластерах PostgreSQL

Довольно часто в кластерных конфигурациях PostgreSQL можно встретить настройку, отвечающую за ввод отказавшего ведущего сервера обратно в кластер в качестве реплики. Утилита pg_rewind выполнит синхронизацию данных между двумя серверами. Она копирует изменения из WAL-файлов основного сервера, которые не применялись на отстающем сервере (бывшем мастере). Однако без механизма fencing существует риск потери данных, если оба сервера (старый мастер и новый мастер) активны одновременно и оба принимают изменения данных. Эта ситуация называется split-brain, возникновение ее катастрофично для целостности данных. Поговорим о том, как минимизировать риски потери данных, какие есть варианты fencing-а, какие практики стоит использовать и в каких ситуациях.

Greenplum: командный центр вместо pg_stat_statements

В greenplum используется отличный от PostgreSQL подход для сбора статистики выполнения запросов: вместо pg_stat_statements - командный центр. Командный центр - отдельное приложение. А значит нет необходимости хранить статистику в разделяемой памяти. Но нужно отправлять ее отдельному процессу. Расскажу: - как мы его реализовали; - почему использование grpc в postgreSQL - плохая идея и с какими еще проблемами мы столкнулись; - какие хуки было бы неплохо добавить в postgreSQL; - как не тормозить на отправке данных; - какие новые возможности появляются у отдельного приложения.