Продвинутые техники pg_upgrade

На сегодняшний день утилита командной строки pg_upgrade является наиболее популярным инструментом для обновления между мажорными версиями Postgres. Однако помимо достоинств, у неё есть и известные проблемы. Одна из наиболее критичных: что делать, если произошёл сбой? Цель данного доклада - раскрыть те маленькие секреты, благодаря которым любой из слушателей сможет существенно улучшить процесс выполнения обновлений.

Мы начнём с обсуждения базового режима фунционирования pg_upgrade. Потом мы изучим то, что позволяет обновить многотерабайтный кластер за считанные минуты. В конце мы обсудим те самые ситуации сбоя, которых все боятся, а также разберёмся, что делать в случае их возникновения, чтобы обрести уверенность и определённость.

Список подтем доклада приведён ниже:

• Как работает pg_upgrade? Общая картина
• О pg_upgrade (вызов из командной строки)
  • аргументы и опции

• Пошаговое выполнение обновления
• О репликации на основе РОЛИ
  • с атрибутом REPLICATION
  • с атрибутом LOGIN

• Опции для обновления: копирование или жёсткие ссылки?
• Что делать после обновления?
  • о производительности
  • об анализе
  • о команде REPACK
  • о переиндексации

• Когда что-то идёт не так, и точка невозврата уже пройдена (пройдена ли?)
• Обновляем РЕПЛИКУ
  • Метод по умолчанию: pg_basebackup
  • Продвинутый метод:
    • - используем rsync
    предупреждение: закольцовка vacuum

Анализатор исторической нагрузки pg_profile/pgpro_pwr и его новые возможности

Речь пойдет о простом инструменте стратегического анализа исторической нагрузки. Расширение предназначено для поиска проблем производительности в базах данных Postgres. Расскажу о принципах работы расширения, его применимости, возможностях и развитии. У pg_profile появилась расширенная ветка pgpro_pwr, предназначенная для работы в дистрибутивах PostgresPro с расширенным набором статистик производительности. Покажу на простых примерах преимущества, доступные в базах PostgresPro Enterprise Edition и PostgresPro Standard Edition.

Как будет развиваться логическая репликация?

Логическая репликация в PostgreSQL доступна начиная с версии 10.0, и с каждым новым релизом она улучшается. Мы начнём доклад с обсуждения базовой архитектуры логической репликации в PostgreSQL, а затем перейдём к различным способам её использования.

Одним из недостатков логической репликации по сравнению с физической является невозможность репликации транзакции до момента коммита. Для транзакций, которые выполняются продолжительное время, это может привести к серьёзной задержке на стороне реплики. Мы обсудим, какое решение этой проблемы реализовано в PostgreSQL.

Мы также остановимся на других крупных разработках в области логической репликации, которые позволят осуществлять потоковую передачу транзакций в заранее заданное время. Это позволит реализовать логическую репликацию без конфликтов. Это также можно будет использовать для масштабирования чтения. Благодаря протоколу 2PC мы сможем убедиться, что реплики получили все данные, закоммиченные на мастере. Теперь мы можем спроектировать систему, где определённые узлы являются владельцами некоторого набора таблиц. Так мы всегда сможем получить данные этих таблиц с этих узлов, а также установить некий внешний процесс для учитывающей это маршрутизации для операций чтения.

В конце доклада мы перечислим новые улучшения, связанные с логической репликацией и вошедшие в недавние релизы PostgreSQL.

Constraints или о том, как попытаться спокойно жить

Часто можно услышать, что ограничения целостности снижают производительность, все время мешают в работе и вообще в целом бесполезны, база - это всего лишь хранилище и вообще там не должно быть никакой логики. Я расскажу, почему это не так и чем может обернуться такой бездумный подход.