Развёртывание PostgreSQL-кластера с балансировщиком запросов и мониторингом в Kubernetes

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

Есть несколько решений для запуска кластера PostgreSQL на Kubernetes. Однако эти решения не предусматривают балансировку нагрузки. В этом выступлении я покажу вам, как объединить PostgreSQL-оператор с Pgpool-II для развертывания в Kubernetes кластера PostgreSQL с возможностью балансировки нагрузки.

Мониторинг - очень важная часть для любого реального продакшна. Хотя Kubernetes предоставляет базовый способ мониторинга состояния кластера PostgreSQL, этого недостаточно для управления кластером PostgreSQL в продакшне. Важным улучшением версии Pgpool-II 4.2 является возможность вывода более полезной статистики кластера PostgreSQL. В этом докладе я объясню, как отслеживать и визуализировать статистику кластера PostgreSQL в Prometheus для расширенного мониторинга кластера.

Постгрессовый планнер с памятью

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

Когда всё идёт не так: как надо и как не стоит реагировать на инциденты при поддержке СУБД

Однажды в Adjust мы столкнулись с проблемой скорого достижения предельного значения xid в очень централизованной базе данных из-за длительной остановки autovacuum. Поскольку мы заметили предупреждения за 5 часов до надвигающейся катастрофы, мы смогли минимизировать влияние проблемы на клиентов. Приходите на доклад, чтобы узнать, как мы использовали это время для подготовки и какие уроки это может преподать всем, кто сталкивается с необычными проблемами в больших базах данных.

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

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

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

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

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

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

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

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