PGConf.Russia 2018

Как бэкапировать PostgreSQL? Как хранить сделанные бэкапы? Как валидировать бэкап? Как валидировать PostgreSQL и можно ли ему вообще доверять? Можно ли доверять твоему инструменту? Как сделать всю эту паранойю удобной и производительной, если СУБД не помогает в этом деле? На какие компромиссы можно идти и на какие ни в коем случае нельзя? Создавая свой инструмент бэкапирования, мы были вынуждены искать ответы на эти и многие другие вопросы, о чем и хотелось бы рассказать.

В 10-й версии постгреса появилось встроенное партицирование таблиц. Однако ставить точку на развитии этого функционала, начало работы над которым ведётся с августа 2015 года, пока рано. В новом 11-ом релизе ведутся несколько параллельных работ по преодолению ограничений встроенного партицирования (update ключа партицирования, вставка в foreign партиции, локальные и глобальные индексы) и внедрение оптимизаций (runtime partition pruning, parallel append нода и partition-wise aggregation/grouping), которые восполнят многолетний пробел в этой области.

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

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

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

Этот доклад будет иметь мало общего с докладом про 10TB и выше, так как среды данных значительно отличаются. Мы рассмотрим эффективность аналитики, выравнивание данных, причины для разработки расширений на С, перемещение данных между серверами в нескольких центрах обработки данных.

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

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

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

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