Сетевой фильтр PostgreSQL для EnvoyProxy

Как вы осуществляете мониторинг Postgres? Какую информацию вы собираете и насколько она помогает решать возникающие проблемы? Что если вам хочется или нужно логировать все запросы? Высоконагруженные базы данных могут выйти из строя при таком подходе.

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

Полезные ссылки:

• https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/postgres#arch-overview-postgres
• https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/

Constraints или о том, как попытаться спокойно жить

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

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

• Как (не) работают оценки
• Как мы справились с миграцией выражений BULK COLLECT
• Почему мы избавились от выражений REF CURSOR
• Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
• Как мы справились с иерархическими запросами и детализацией иерархии

Лучшие практики для бэкапов с помощью pgBackRest

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

В этом докладе мы рассмотрим лучшие практики резервного копирования баз данных и способы их реализации с помощью pgBackRest, в том числе:

• архивирование и хранение журнала предзаписи (WAL);
• частоту снятия резервных копий и срок их хранения;
• достижение целей по времени / точке восстановления;
• варианты конфигурации;
• обоснование с точки зрения производительности.