PostgreSQL *

Задача 2

Методы наблюдения Golden Signals и RED являются шаблонами при построении мониторинга сервисов и определяют ключевые метрики которые нужны при наблюдении. Раньше об этих методах знали исключительно администраторы мониторинга или SRE. Сейчас тема инструментирования приложений уже не является чем-то новым и об этих методах знают более-менее все.

В этом посте я порассуждаю о том как в мониторинге покрыть PostgreSQL используя методы RED и Golden Signals. Подсистема мониторинга в Postgres реализована в те времена когда RED и Golden Signals еще не было и на мой скромный взгляд в ней есть некоторые недостатки и с ходу натянуть RED или Golden Signals на Postgres может показаться непростой задачей. В этом посте я постараюсь коротко рассмотреть возможности которые предоставляет Postgres для реализации наблюдения по методам RED/Golden Signals и дам конкретные направления к тому чтобы реализовать это. К тому же это на так сложно как можно подумать.

OFFSET start { ROW | ROWS }
FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES }

Привет, меня зовут Иван, и я делаю Авито Доставку.

Тестирую я как-то раз один из наших сервисов на быстродействие. И в метриках pgbouncer’a вижу вот такую печальную картину:

Зелёный — число активных клиентских соединений (cl_active), красные точки — число клиентских соединений, которым не досталось серверного соединения (cl_waiting, правая шкала)

Расследуя этот график, удалось выйти на занятный баг, снять блокер по переезду на четвёртую версию pgx, а также немного разобраться в устройстве pgx и pgbouncer’a.

Вольный перевод статьи «7 Best Practice Tips for PostgreSQL Bulk Data Loading»

Иногда возникает необходимость в несколько простых шагов загрузить в БД PostgreSQL большой объём данных. Данная практика обычно называется массовым импортом, когда в качестве источника данных служит один или несколько больших файлов. Данный процесс иногда может проходить неприемлемо медленно. Существует несколько причин такой низкой производительности. Вызывать задержки могут индексы, триггеры, внешние и первичные ключи или даже запись WAL – файлов.

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

Решение на базе Docker, которое позволит создать на локальном компьютере универсальную среду разработки на PHP за 30 - 40 минут. Несколько версий PHP — 7.3 и 7.1 с набором наиболее востребованных расширений. Готовый к работе монитор процессов Supervisor. Предварительно сконфигурированный веб-сервер Nginx. Базы данных: MySQL 5.7, MySQL 8, PostgreSQL, MongoDB 4.2, Redis. Настройка основных параметров окружения через файл .env. Возможность модификации сервисов через docker-compose.yml.

Это цитата одного из моих знакомых который когда-то давно обращался ко мне с вопросом про Postgres. Тогда мы за пару дней порешали его проблему и поблагодарив меня он добавил: "Хорошо, когда есть знакомый DBA".

Но что делать если нет знакомого DBA? Вариантов ответа может быть довольно много, начиная от поискать среди друзей друзей и заканчивая до изучить вопрос самостоятельно. Но какой бы ответ не пришел к вам в голову, у меня для вас хорошая новость. В тестовом режиме мы запустили сервис рекомендаций для Postgres'ов и всего что вокруг них.

При разработке приложений иногда возникает потребность в сравнении двух баз данных (например prod и dev).

Существует ряд подходов для решения этого вопроса - от создания dump-файла со структурой db и последующим использованием diff, до использования специализированных платных решений типа dbForge или RedGate.

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

Публикация основана на докладе тренера и инженера технической поддержки Zabbix Александра Петрова-Гаврилова.

Многих волнует вопрос о том как мигрировать с MySQL на PostgreSQL и воспользоваться преимуществами TimescaleDB.

Зачем мигрировать

Первый вопрос, который обычно возникает, — зачем мигрировать с MySQL на PostgreSQL при использовании Zabbix.

Вариантов не так много, особенно если система уже работает и работает неплохо. Возможные причины для миграции:

• Команда лучше разбирается в PostgeSQL.
• Желание попробовать TimescaleDB, учитывая обещанное повышение производительности и экономию места.
• Документация на русском языке
• Преимущества PostgreSQL Pro.

 
За основную часть перехода информационных систем с Oracle на PostgreSQL часто отвечают инструменты автоматической конвертации. Но среди гигантского объёма кода, покрываемого такими решениями, есть и исключительные истории, с которыми приходится импровизировать. В таких случаях первым делом, конечно, необходимо локализовать проблему, установить её причину и, чтобы подобрать правильное решение, подумать, нет ли аналогичных реальных или вымышленных ситуаций, которые могли бы иметь похожую природу. После этого обычно приходится рефакторить оригинальный код на Oracle, дорабатывать процессы конвертации и грамматику или реализовывать на PostgreSQL не имеющую аналогов функциональность Oracle. Однажды нам бросил вызов, на первый взгляд, примитивный запрос с ошибкой, для решения которой пришлось проводить целое расследование.

В этой статье мы научимся шифровать бэкапы, загружать их в S3-совместимое хранилище (вместо второго сервера-репозитория), восстанавливаться на чистый кластер и, наконец, восстанавливаться на определенный момент времени (point in time recovery, PITR).

Вы только что установили PostgreSQL и запустили ваш первый кластер, создали несколько таблиц, загрузили данные, и даже немного подкрутили конфигурацию PostgreSQL для улучшения производительности. Теперь вы думаете о том, как сделать ваш кластер высокодоступным. К сожалению, PostgreSQL не умеет сам выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно достичь с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую. И… вы уже на неправильном пути, потому что в первую очередь вы должны определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Постгреса с автоматическим переключением.