Как я распилил 1,1 ТБ default-партиции и не уронил прод

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition . Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с . Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит. 44 секунды блокировки: план операции

https://habr.com/ru/articles/977528/

#партиционирование_PostgreSQL #ATTACH_PARTITION #plpgsql #автоматизация_обслуживания_БД #explain_analyze #downtime #advisory_lock #CHECK_constraint #partitioning #database_migrations

Распределённая батчевая обработка данных: как мы решали проблему гонок в продакшене

Всем привет! Меня зовут Дмитрий, я руковожу командой государственных интеграций в Ozon Банке. Сегодня я расскажу о том, как мы столкнулись с проблемой гонок при батчевой обработке данных в распределённой системе — и какие решения мы рассматривали, чтобы эту проблему решить. Материал основан на реальном кейсе и будет интересен всем, кто работает с PostgreSQL, батчами, распределёнными системами и борьбой за консистентность в высоконагруженных системах.

https://habr.com/ru/companies/ozonbank/articles/944882/

#архитектура #sql #аномалии #kafka #postgresql #advisory_lock