title

text

Павел Конотопов
Павел Конотопов Postgres Professional руководитель кластерной группы
: декабря
40 мин

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

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

Слайды

Слайды доступны участникам мероприятия, выполнившим вход в личный кабинет.

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Василий Пучков
    Василий Пучков ООО Главный эксперт
    40 мин

    JSONB и будущее реляционных СУБД - взгляд разработчика

    История сложных отношения реляционной и объектной моделей: - крепкие опоры и неразрешимые противоречия; - разные хорошие попытки - составные типы, классы, XML, JSON. JSONB - новый ответ и вопросы к нему. Ловушки и тупики, в которые может завести увлечение JSONB. Очевидные и неочевидные способы использования JSONB в разработке.

  • Алена Рыбакина
    Алена Рыбакина Postgres Professional Разработчик
    А
    Андрей Лепихов
    40 мин

    Перепланирование безнадежных запросов в реальном времени

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

  • Дмитрий Фатов
    Дмитрий Фатов
    40 мин

    Разгоняем вставку больших объемов данных Spring + PostgreSQL

    Разработчикам часто приходится встречаться с оптимизацией различных бизнес-процессов. В этом докладе спикер покажет процесс оптимизации вставки в PostgreSQL с использованием фреймворка Spring со стороны прикладного разработчика. Также расскажет о проблемах медленной вставки данных в БД и о том, как можно ускорить этот процесс от простых настроек до использования кастомных методов PostgreSQL.

  • Леонид Борчук
    Леонид Борчук Яндекс Разработчик
    40 мин

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

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