Мастер-класс: Управление высокодоступными PostgreSQL кластерами с помощью Patroni

Patroni - это Python-приложение для создания высокодоступных PostgreSQL кластеров на основе потоковой репликации. Оно используется такими компаниями как Red Hat, IBM Compose, Zalando и многими другими. С его помощью можно преобразовать систему из ведущего и ведомых узлов (primary - replica) в высокодоступный кластер с поддержкой автоматического контролируемого (switchover) и аварийного (failover) переключения. Patroni позволяет легко добавлять новые реплики в существующий кластер, поддерживает динамическое изменение конфигурации PostgreSQL одновременно на всех узлах кластера и множество других возможностей, таких как синхронная репликация, настраиваемые действия при переключении узлов, REST API, возможность запуска пользовательских команд для создания реплики вместо pg_basebackup, взаимодействие с Kubernetes и т.д.

Слушатели мастер-класса подробно узнают, как работает Patroni, получат практические навыки настройки высокодоступных кластеров на его основе, познакомятся с различными дополнительными возможностями и поучаствуют в диагностике проблем. Будут рассмотрены следующие темы:

• область применения: какие задачи HA успешно решаются Patroni
• обзор архитектуры
• создание тестового кластера
• утилита patronictl
• изменение конфигурации PostgreSQL для кластера, управляемого Patroni
• мониторинг с помощью API
• подходы к переключению клиентов
• дополнительные возможности: ручное переключение, перезагрузка по расписанию, режим паузы
• настройка синхронной репликации
• расширяемость и универсальность
• частые ошибки и их диагностика

Для полного участия в мастер-классе вам понадобится ноутбук с установленным git, vagrant и virtual box.

Vagrant можно загрузить со страницы https://www.vagrantup.com или установить с помощью пакетов в вашем дистрибутиве. Virtualbox: https://www.vagrantup.com

После установки Vagrant и Virtualbox нужно выполнить:

$ git clone https://github.com/alexeyklyukin/patroni-training
$ cd patroni-training
$ vagrant up

После того, как patroni box поднимется и установит необходимые пакеты к нему можно подключиться с помощью vagrant ssh.

Практика обновления версий PostgreSQL

В большинстве своем, системные администраторы и ДБА бояться как огня делать мажорные обновления версий баз данных (RDBMS), особенно если эта база данных в эксплуатации и имеет достаточно высокую нагрузку. Главной причиной тому некоторый даунтайм базы данных, который всегда подразумевается при планировании таких работ.

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

В Data Egret мы накопили огромный опыт проведения мажорных апгрейдов PostgreSQL в проектах, где нет права на ошибку. Я поделюсь своим опытом и расскажу о следующих шагах процесса: как правильно подготовиться к upgrade-у PostgreSQL? что необходимо сделать на этапе подготовки? как запланировать последовательность действий на сам upgrade? как провести процедуру upgrade-а успешно, без возврата на предыдущую версию бд? как минимизировать или вообще избежать простоя всей системы во время upgrade-а? какие действия необходимо выполнить после успешного upgrade-а PostgreSQL? Я также расскажу про две наиболее популярные процедуры апгрейда PostgreSQL - pg_upgrade и pg_dump/pg_restore, плюсы и минусы каждого из методов и расскажу про все типичные проблемы на всех этапах этой процедуры, и как их избежать.

Доклад будет интересен как новичкам так и тем ДБА которые уже давно работают с PostgreSQL, но хотят побольше узнать о том как правильно планировать и проводить upgrade максимально безболезненно.

PostgreSQL SaaS в Rambler&Co

Rambler&Co - это множество изданий, сервисов и проектов. Появляются новые и растут существующие. Такой среде нужна надежная, отказоустойчивая, масштабируемая, автоматизированная система.

Расскажу об устройстве нашего PostgreSQL SaaS, какие инструменты и технологии мы используем. Кворум из 3 Дата-центров. Единая точка входа для клиентов на основе динамической маршрутизации. Аварийное переключение мастера. Прозрачное масштабирование на чтение. Создание реплики без нагрузки на кластер. Прозрачный перенос PostgreSQL cluster на другие серверы. Актуализация dev окружения из prod для разработки. Резервное копирование с компрессией и использованием нескольких CPU на стороне database, восстановление одной БД из basebackup. Мониторинг sql запросов.

Опыт миграции высоконагруженных игровых проектов с MySQL на PostgreSQL

В докладе будет рассказано о том, как мы переносили два высоконагруженных игровых проекта, изначально разработанных для работы с MySQL на Postgres. Какие проблемы мы видели изначально при миграции на Postgres, с какими очевидными и не очень сложностями столкнулись во время миграции и как их решали. Какие проблемы выявились в процессе эксплуатации. Какие фичи Postgres нам оказались очень полезными, а чего нам не хватало при переносе.