Скорость физической репликации в PostgreSQL.
Репликация - один из важных механизмов, призванный обеспечить отказоустойчивость и масштабируемость базы данных. В нашей практике мы регулярно сталкиваемся с проблемой низкой производительности репликации. Это побудило нас исследовать факторы, влияющие на скорость физической репликации. В этом докладе я расскажу о полученных результатах исследования. Также покажу, как менялась производительность репликации на разных версиях PostgreSQL.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
Денис Суховей Аладдин Р.Д. Директор по продуктуАлексей Сабанов АО "Аладдин Р.Д." Заместитель генерального директора
Криптографическая защита информации с помощью "Крипто БД" или как достичь технологического суверенитета информационной системы
Мифы и заблуждения импортозамещения. "Окирпичивание" серверов СУБД как острая угроза. Базовый план импортозамещения и проблемы переходного периода. Защита информации в СУБД и образ идеальной системы защиты. Крипто БД - система криптографической защиты данных. Как это работает?
-
Иван Фролков Postgres Professional инженер-консультант
Темпоральные типы и их использование
Я пересмотрел за жизнь много всякого кода, и очень часто встречал некоторый разнобой в обработке дат и времени: то у сторон не сходились отчеты за месяц, то суточные отчеты получались разные в Москве и Сан-Франциско, то еще чего-нибудь в таком же роде. Это не сказать чтобы сильно страшно, но довольно утомительно. Причина такого рода проблем всегда была связана с неаккуратной обработкой дат и времени. Тому, как этого можно постараться избежать, и посвящен мой доклад.
-
ДДенис Волков Яндекс Разработчик
SPQR - легковесное шардирование
Stateless Postgres Query Router - новая система для роутинга запросов по диапазоном. Система написана на Go и стремится решить проблемы OLTP шардирования. Также система предполагает управление перемещением данных между шардами.
-
Вадим Яценко Tantor Lab Генеральный директор
Autovacuum. Вредные советы
В архитектуре PostgreSQL есть ряд особенностей, которые стоит учитывать не только при эксплуатации БД, но и в процессе проектирования схемы данных. Опытным пользователям PostgreSQL хорошо известен такой механизм как очистка/заморозка(vacuum). На просторах интернета есть большое количество материалов на тему внутреннего устройства, настройки и мониторинга. Множество полезных докладов было сделано на конференциях. Тем не менее, все еще происходят случаи переполнения счетчика транзакций(xid), казалось бы, в достаточно небольших БД. В этом докладе я расскажу об одном интересном, на мой взгляд, случае у нашего клиента. Поделюсь тем, как череда ошибок на разных этапах жизненного цикла БД, однажды привела к ее полной остановке более чем на неделю, wraparound-у, битым блокам, проблемам с обслуживанием и бессонным ночам в поисках решения. Локальная победа была достигнута - БД удалось восстановить, но история еще не закончена. Тем она и интересна.