Как сохранить статистику при мажорном обновлении, и что за это бывает

Ни для кого не секрет, что статистика не переносится при мажорном обновлении. Для небольших и не сильно нагруженных баз это не проблема, можно быстро собрать новую статистику. Но у нас есть базы объемом порядка 5ТБ и нагрузкой порядка 100k rps, для которых это стало большой проблемой: взлетая без статистики, реплики даже не могли накатывать WAL. В своем докладе расскажу, на какие хитрости мы пошли, чтобы произвести обновление этих баз в условиях требований 100% доступности read only, о том, какие ошибки допустили, и о том как эти ошибки мучительно исправляли. Результатом этих ошибок стало расширение pg_dirty_hands, в котором мы будем собирать различные хаки, которые можно назвать «фол последней надежды».

Подключаемые хранилища

Тема подключаемых хранилищ для PostgreSQL стала уже притчей во языцех. Период споров о том, нужны ли подключаемые хранилища, или нет закончился. Позиции скептиков, говорящих, что подключаемые хранилища не нужны, поскольку являются источником неконсистентного поведения СУБД, заметно ослабли после критики реализации MVCC в PostgreSQL со стороны Uber'а. Стало понятно, что подключаемые хранилища нужны как-минимум для альтернативной реализации MVCC через undo-лог, и это стало одним из ориентиров для проектирования интерфейса.

На текущий момент работа над подключаемыми хранилищами перешла в практическую плоскость: ведётся тред, в котором несколько человек разрабатывают набор патчей, и ещё больше делают ревью.

В данном докладе будут рассмотрены следующие вопросы:

• обзор получившегося интерфейса для подключаемых хранилищ;
• изменения в ядре PostgreSQL, которые потребовались для реализации данного интерфейса;
• текущие и потенциальные применения данного интерфейса, включая heap с undo-логом и in-memory OLTP движок;
• текущее состояние патчей и перспектива их принятия в ядро;
• дальнейшее развитие интерфейса с целю расширения возможностей подключаемых хранилищ (columnar, index-organized, LSM и т.д.).

Особенности мониторинга и траблшутинга высоконагруженной БД PostgreSQL

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

• Квантовые эффекты или как наблюдатель влияет на наблюдаемую систему
• Особенности сбора метрик при мониторинге БД с помощю Zabbix
• Сбор данных для аналитики и визуализации запросов PostgreSQL с помощью rsyslog + kafka + clickhouse + grafana.
• Инструменты оперативного анализа лог-файлов БД

Разработка дельта-копий в WAL-G

WAL-G - простой и эффективный инструмент для резервного копирования PostgreSQL в облака. По своей основной функциональности он является наследником популярного инструмента WAL-E, но переписанным на Go. Но в WAL-G есть одна важная новая особенность - дельта-копии. Дельта-копии WAL-G (где это возможно) хранят страницы файлов, изменившиеся с предыдущей версии резервной копии. В этом докладе я расскажу о том, как эту особенность разрабатывал.

Наиболее важным и сложным, как ни странно, являлся вопрос интерфейса: WAL-E - простой и понятный, это свойство хотелось сохранить в первую очередь. Технические детали реализации также готовили несколько неожиданных открытий. Кроме того, хотелось бы обсудить перспективы развития технологии и поговорить о взаимодействии и координации со стороны разработчиков инструментов резервного копирования.