PGConf.Russia 2024

Сейчас у нас есть задачи разных классов, которые решают разные продукты, но, если "копнуть" глубже, эти продукты одного класса и решают много однотипных задач. После того, как мы представили на рынок встроенную отказоустойчивость (BiHA),мы решили продолжить модернизацию наших кластреных возможностей, которые работают "из коробки".

В данном докладе сделаем краткий обзор базовых технических требований к новой функциональности PostgresPro Enterprise, которая появится в 17 версии.

Что вы можете вспомнить по ключевому слову «безопасность»? Скорее всего, только ролевую модель доступа. На самом деле арсенал средств защиты современных СУБД гораздо шире. Если вам незнакомы такие аббревиатуры, как RLS, FGAC, DLP, PAM, WAF, LBAC, TDE, KMS и масса других, то этот доклад — для вас. Мы расшифруем эти иероглифы, поговорим о том, какие из них действительно важны, а главное — когда и от чего надо защищать базу данных.

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

Довольно часто в кластерных конфигурациях PostgreSQL можно встретить настройку, отвечающую за ввод отказавшего ведущего сервера обратно в кластер в качестве реплики. Утилита pg_rewind выполнит синхронизацию данных между двумя серверами. Она копирует изменения из WAL-файлов основного сервера, которые не применялись на отстающем сервере (бывшем мастере). Однако без механизма fencing существует риск потери данных, если оба сервера (старый мастер и новый мастер) активны одновременно и оба принимают изменения данных. Эта ситуация называется split-brain, возникновение ее катастрофично для целостности данных. Поговорим о том, как минимизировать риски потери данных, какие есть варианты fencing-а, какие практики стоит использовать и в каких ситуациях.