Готовим PostgreSQL в эпоху DevOps. Опыт 2ГИС
После перехода к микросервисной архитектуре для PostgreSQL наступили «темные времена». Каждая из десяти команд действовала самостоятельно — ставила свою базу данных, выбирала версию, писала деплои. Пришло время создать общий инструмент.
Мы собрали кластер на основе PostgreSQL, repmgr, PgBouncer, Barman. Несмотря на то, что система получилась достаточно сложной для неподготовленного специалиста, нам удалось создать повторяемый деплой, который позволяет быстро разворачивать рабочую систему. А также мы смогли консолидировать все базы в нескольких кластерах и снять с команд обязанности по администрированию.
Failover работает, мы проверяли :-)
Слайды
Видео
Другие доклады
-
Мирослав Шедиви solute GmbH Senior Software Developer
Битемпоральность: отслеживание воспроизводимых изменений в PostgreSQL с помощью типа данных RANGE
Итак, вы наконец создали модель базы данных для вашего приложения и наполнили ее текущими данными. Каким образом обеспечить их актуальность? Хотя команда INSERT может быть все еще прозрачной, команды UPDATE и DELETE перезапишут ваши предыдущие данные, так что вы не сможете их воспроизвести. Клонирование целиком огромного контента при каждом небольшом обновлении - не вариант. Для богатых и сложных данных о сотнях тысяч электрогенераторов в Германии и по всему миру я построил базу данных, используя тип данных range, недавно появившийся в PostgreSQL. Это позволило мне добавлять, обновлять и удалять данные, при том обладая полным доступом к состоянию базы данных в любой исторический момент. Во время выступления я представлю очень упрощенную версию базы данных, чтобы аудитория смогла тут же применить знания на практике. Также я покожу несколько хитрых приемов в работе с Python и Psycopg2, которые позволят всей команде подготавливать, просматривать и развертывать все изменения в базе данных без конфликтов слияния. И подкину несколько идей о том, как можно эти данные эффективно извлекать.
-
Юрий Жуковец ЗАО Дилжитал-Дизайн Архитектор ПО
Технические особенности портирования T-SQL кода на plpgsql и данных из MS SQL в PG на примере перевода СЭДО «Приоритет» на Postgres
Доклад посвящен продолжению проекта по переводу нашей системы электронного документооборота «Приоритет» с MS SQL на Postgres. Будут затронуты технические решения и моменты переписывания с T-SQL на plpgsql, оптимизации результативного кода и переноса данных. Дополнительно рассмотрим аспекты тестирования производительности с точки зрения поиска «плохого кода» pgplsql как кандидата на оптимизацию. Основная задача презентации - ответить на вопрос: "У нас так на T-SQL - как это перенести на PG?". Доклад предназначается для начинающих разработчиков на Postgres и является продолжением предыдущего доклада сделанного на конференции в 2017 (https://youtu.be/v6_4Szr8t14).
-
Константин Евтеев X5 FoodTech Главный архитектор
Стендбай в бою
В докладе рассмотрю различные варианты использования и конфигурацию standby сервера. Расскажу о том, как сделать standby, согласованный с вашим архивом, чтобы после аварии primary и промотирования standby сервера новый стендбай можно было пересоздать из архива. Слушатели познакомятся с опытом Avito: как использовать standby для read-only запросов, какие возникали проблемы и как мы их решили. Поговорю про мониторинг standby - на какие метрики стоит обратить внимание.
-
Иван Фролков Postgres Professional инженер-консультант
Типичные ошибки приложений при работе с Postgres
По роду своей деятельности мне все время приходится иметь дело с приложениями, работающими с Postgres. Некоторые работают хорошо; некоторые не совсем - и доклад будет как раз об ошибках последних.
Фотогалерея