PGConf.Russia 2022

В Postgres Professional ведется разработка механизма сбора детальных данных о работе вакуума в statistics collector. Я расскажу о некоторых проблемах, которые это поможет решать и покажу как это выглядит на примере расширения pgpro_pwr.

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

Мы ранее рассказывали про внутренне устройство Авито, где и как хранятся ваши объявления, как эти объявления попадают в поиск. За последние 3-4 года очень много изменилось в Авито, мы избавились от использования логической репликации, использования standby для читающей нагрузки, практически отказались от хранимых процедур, избавились от самописного failover решения, мигрировали все объявления в шардированную базу данных, практически "распилили" монолит и перешли на разработку в микросервисах. Расскажу о причинах такого развития, проблемах с которыми столкнулись, и текущем положении дел.

Лет 7 назад я пришёл от разработки под Windows к непреодолимому желанию дописать некоторые части PostgreSQL. В этом докладе я бы хотел рассказать о деталях вещей, которые были мне не очевидны, когда я начал работать с исходным кодом, системой сборки и тестирования PG. Я собираюсь говорить о самых простых вопросах - рутинные задачи IDE, навигация, сборка и всё такое. И совсем не претендую на какой-то истинный путь. Возможно, что-то покажется совсем проблемами чайников :) Я был бы рад, если бы другие разработчики тоже поделились секретами своего разработческого быта. Можем устроить обсуждение grep vs IDE :)