Отказоустойчивый кластер PostgreSQL с помощью crmsh

В некоторых дистрибутивах ОС отсутствует утилита настройки pcs для создания отказоустойчивого кластера PostgreSQL. В этом случае нам поможет утилита crm из пакета crmsh. Она сложнее в использовании, но такая же мощная и эффективная.

В своем мастер-классе я покажу, как этой утилитой пользоваться, а также настрою отказоустойчивый кластер в разных конфигурациях.

Оптимизация производительности PostgreSQL

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

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

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

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

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

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

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

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

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

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

• Как (не) работают оценки
• Как мы справились с миграцией выражений BULK COLLECT
• Почему мы избавились от выражений REF CURSOR
• Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
• Как мы справились с иерархическими запросами и детализацией иерархии