Доклады

За последние несколько десятилетий было написано огромное количество инструментов диагностики для Unix/Linux окружений. Поэтому инженеру сопровождения при возникновении проблемы достаточно запустить одну-две команды, чтобы понять первопричину проблемы. Но, увы, иногда этого недостаточно, и за несколько лет технической поддержки в нашей компании мы разработали ряд инструментов для диагностики проблем PostgreSQL, без которых теперь даже не можем представить свою работу.

 Приходите на доклад, чтобы узнать:

- что такое операционный лог и почему это не имеет отношения к медицине

- о том, как оставить следы при segfault-ах базы, и в чём секрет сигнала номер 40 в Postgres Pro

- как запрофилировать время работы внутренних функций PostgreSQL без прав администратора операционной системы.

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

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

1. Узнаем что такое эзотерические языки программирования и зачем писать код, который невозможно прочитать

2. Научимся создавать расширения PostgreSQL и посмотрим необычные примеры

3. Креативное применение SQL: пишем любовную поэму и рисуем карту мира Игры Престолов

4. Какие есть варианты учиться SQL играючи? Подборка идей от текстовых квестов и до... DOOM в вашей СУБД???

В течение жизни сервис может столкнуться с ситуациями, к которым его не готовили. Причины оставим за кадром, но я расскажу про последствия, которые приходится исправлять DevOps-инженерам. В докладе — пара историй из практики: о партицировании большой таблицы на ходу и неожиданном замедлении производительности сервиса при выполнении запросов в БД.

Представьте, что у вас есть огромная активная база, живущая без резервной копии... И админ, который вручную удаляет старые "ненужные" файлы и аварийно останавливает сервер БД. Стандартные методы диагностики не работают, попытка воспользоваться pg_dump приводит к зависанию.

Неужели это точка невозврата?

- Разберёмся почему база может запуститься, но работать не будет. И как этого избежать

- Какими инструментами мониторинга можно воспользоваться, когда ничего не помогает: gdb, crash_info... 

- Плюсы работы с open source: хакнуть код pg_dump ради всеобщего блага!

Увлекательная история о том, как мы помогали спасти данные в экстренных условиях.