Расшифровка доклада/tutorial "Управление высокодоступными PostgreSQL кластерами с помощью Patroni". А.Клюкин, А.Кукушкин

Patroni — это Python-приложение для создания высокодоступных PostgreSQL кластеров на основе потоковой репликации. Оно используется такими компаниями как Red Hat, IBM Compose, Zalando и многими другими. С его помощью можно преобразовать систему из ведущего и ведомых узлов (primary — replica) в высокодоступный кластер с поддержкой автоматического контролируемого (switchover) и аварийного (failover) переключения. Patroni позволяет легко добавлять новые реплики в существующий кластер, поддерживает динамическое изменение конфигурации PostgreSQL одновременно на всех узлах кластера и множество других возможностей, таких как синхронная репликация, настраиваемые действия при переключении узлов, REST API, возможность запуска пользовательских команд для создания реплики вместо pg_basebackup, взаимодействие с Kubernetes и т.д.

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

• область применения: какие задачи HA успешно решаются Patroni
• обзор архитектуры
• создание тестового кластера
• утилита patronictl
• изменение конфигурации PostgreSQL для кластера, управляемого Patroni
• мониторинг с помощью API
• подходы к переключению клиентов
• дополнительные возможности: ручное переключение, перезагрузка по расписанию, режим паузы
• настройка синхронной репликации
• расширяемость и универсальность
• частые ошибки и их диагностика

В прошлой статье, где я рассказывал о мониторинге БД PostgreSQL, была такая фраза:

Растут wait — приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.

Такая ситуация — одна из самых неприятных для DBA:

• на первый взгляд, база работает
• никакие ресурсы сервера не исчерпаны
• … но часть запросов при этом «подтормаживает»

Шансов поймать блокировки «в моменте» крайне мало, да и длиться они могут всего по несколько секунд, но ухудшая при этом плановое время выполнения запроса в десятки раз. А хочется-то не сидеть и ловить происходящее в онлайн-режиме, а в спокойной обстановке разобраться постфактум, кого из разработчиков покарать в чем именно была проблема — кто, с кем и из-за какого ресурса базы вступил в конфликт.

Но как? Ведь, в отличие от запроса с его планом, который позволяет детально понять, на что пошли ресурсы, и сколько времени это заняло, подобных наглядных следов блокировка не оставляет после себя…

Разве что короткую запись в логе:

process ... still waiting for ...

А давайте попробуем зацепиться именно за нее!

Прим. перев.: Jaana Dogan — опытный инженер из Google, которая в данный момент занимается вопросами наблюдаемости production-сервисов компании, написанных на Go. В этой статье, снискавшей большую популярность у англоязычной аудитории, она в 17 пунктах собрала важные технические детали, касающиеся СУБД (а иногда — распределённых систем в целом), которые полезно учитывать разработчикам крупных/требовательных приложений.



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

О себе

Здравствуй, Хабр! Меня зовут Павел, я работаю техническим директором в компании, занимающейся производством IoT устройств. Производим много чего — начиная от контроллеров для умных домов, заканчивая умными приборами учёта на своём запатентованном протоколе сенсорных сетей.

Также исполняют обязанности генерального директора ит-компании. В прошлом полуфиналист ЧМ по программированию ACM ICPC.

Мотивация

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

Эмбеддинг – это отображение из дискретного вектора категориальных признаков в непрерывный вектор с заранее заданной размерностью.

Geometry of Flowers by Mookiezoolook

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

Но как оценить, какая схема лучше? И что вообще значит «лучше», когда мы говорим об архитектуре БД? Команда Mail.ru Cloud Solutions предлагает познакомиться с рекомендациями Майка Алча, консультанта по разработке программного обеспечения. Нам кажется, что он довольно лаконично резюмировал некоторые принципы грамотной архитектуры.

Привет, Хабр! Меня зовут Максим Васильев, я работаю аналитиком и менеджером проектов в FINCH. Сегодня я хотел бы рассказать, как с помощью ElasticSearch, мы смогли обработать 15 млн запросов за 6 минут и оптимизировать ежедневные нагрузки на сайте одного из наших клиентов. К сожалению, придётся обойтись без имён, так как у нас NDA, надеемся, что содержание статьи от этого не пострадает. Let`s go.

Привет, Хабр! 25 и 26 мая будет РИТ++. Это большая онлайн-конференция для всех, кто делает интернет. В обычных условиях мы бы встретились на стенде Авито в зале мероприятия, но 2020 перевернул всё с ног на голову. Так что общение переносится в Зум, где 11 наших инженеров из разных команд ответят на вопросы про базы данных, перформанс, мониторинг, микросервисную архитектуру и многое другое.

Участвовать в консультации можно независимо от того, есть у вас билет на конференцию или нет. Все встречи доступны любому желающему. Расписание, экспертные области участников и нужные ссылки — под катом. Кроме консультаций мы подготовили пару развлечений, о них в конце анонса.

Я уже рассказывал, как мы «ловим» проблемы PostgreSQL с помощью массового мониторинга логов на сотнях серверов одновременно. Но ведь кроме логов, эта СУБД предоставляет нам еще и множество инструментов для анализа ее состояния — грех ими не воспользоваться.

Правда, если просто смотреть на них с консоли, можно очень быстро окосеть без какой-либо пользы, потому что количество доступных нам данных превышает все разумные пределы.


Поэтому, чтобы ситуация все же оставалась контролируемой, мы разработали надстройку над Zabbix, которая поставляет метрики, формирует экраны и задает единые правила мониторинга для всех серверов и баз на них.

Сегодняшняя статья — о том, какие выводы можно сделать, наблюдая в динамике различные метрики баз PostgreSQL-сервера, и где может скрываться проблема.

Меня зовут Денис Рожков, я руководитель разработки ПО в компании «Газинформсервис», в команде продукта Jatoba. Законодательство и корпоративные нормы накладывают определенные требования к безопасности хранения данных. Никто не хочет, чтобы третьи лица получили доступ к конфиденциальной информации, поэтому для любого проекта важны следующие вопросы: идентификация и аутентификация, управление доступами к данным, обеспечение целостности информации в системе, регистрация событий безопасности. Поэтому я хочу рассказать о некоторых интересных моментах, касающихся безопасности СУБД.

В сложных ERP-системах многие сущности имеют иерархическую природу, когда однородные объекты выстраиваются в дерево отношений «предок — потомок» — это и организационная структура предприятия (все эти филиалы, отделы и рабочие группы), и каталог товаров, и участки работ, и география точек продаж,…



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

Существует много способов хранения такого дерева в СУБД, но мы сегодня остановимся только на одном варианте:

CREATE TABLE hier(
  id
    integer
      PRIMARY KEY
, pid
    integer
      REFERENCES hier
, data
    json
);

CREATE INDEX ON hier(pid); -- не забываем, что FK не подразумевает автосоздание индекса, в отличие от PK

И пока вы всматриваетесь в глубину иерархии, она терпеливо ждет, насколько же [не]эффективными окажутся ваши «наивные» способы работы с такой структурой.


Давайте разберем типовые возникающие задачи, их реализацию на SQL и попробуем улучшить их производительность.

Всем привет! Меня зовут Андрей Капустин. Я работаю системным аналитиком в Mail.ru Group. Наши продукты формируют единую экосистему для пользователя, в которой данные генерируют множество независимых инфраструктур: службы заказов такси и еды, почтовые сервисы, соцсети. Сегодня чем быстрее и точнее мы можем спрогнозировать потребность клиента, тем быстрее и вернее мы можем предложить ему наши продукты.

Многие системные аналитики и инженеры сейчас задаются вопросами:

1. Как спроектировать архитектуру триггерной платформы для real-time маркетинга?
2. Как организовать структуру данных, соответствующую требованиям маркетинговой стратегии взаимодействия с клиентами?
3. Как обеспечить стабильную работу подобной системы в условиях очень высоких нагрузок?

В основе таких систем лежат технологии высоконагруженной обработки и анализа больших данных. Мы накопили немалый опыт в этих сферах. И на примере одной реальной истории расскажу о нашем подходе к аналитике и разработке решений в сфере Real-time Marketing с использованием Tarantool.

По прогнозам IDC, к 2025 году общий объем данных, хранящихся в организациях здравоохранения, вырастет до 2,3 зеттабайт, причем на долю различных медицинских снимков будет приходиться до 80-90% используемой емкости систем хранения. О том, насколько важно эффективное хранение медицинских снимков, говорит следующий пример.

Сделал dashboard Postgresql overview для postgres_exporter.

Чем отличается от других дашбородов postgres_exporter?

Я объединил все другие дашборды postgres_exporter в один.

Этот дашборд показывает общую информацию по кластеру.

Скриншоты и краткая инструкция по установке: postgresql, postgres_exporter, prometheus, grafana под катом.

Всем привет. На связи Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Помимо преподавания, как вы могли заметить, я занимаюсь написанием авторского материала для блога OTUS на хабре и сегодняшнюю статью хочу приурочить к запуску курса «PostgreSQL», на который прямо сейчас открыт набор.

---

Введение

В прошлый раз мы с вами поговорили про то, что транзакции в базах данных служат для решения двух задач: обеспечения отказоустойчивости и доступа к данным в конкурентной среде. Для полноценного выполнения этих задач транзакция должна обладать свойствами ACID. Сегодня мы подробно поговорим про букву I (isolation) в данной аббревиатуре.

Расшифровка доклада 2018 года Алексея Лесовского "Давайте отключим vacuum?!"

Примечание редактора: Любые рекомендации по изменению параметров всегда стоит сравнивать в других докладах

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum (далее по тексту просто "вакуум"). По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам вакуум, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про него. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум — главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.

Предлагаю ознакомиться с расшифровкой доклада начала 2016 года Андрея Сальникова "Типовые ошибки в приложениях, которые ведут к bloat в postgresql"

В данном докладе я разберу основные ошибки в приложениях, которые возникают на этапе проектирования и написания кода приложения. И возьму только те ошибки, которые ведут к bloat в Postgresql. Как правило, это начало конца производительности вашей системы в целом, хотя изначально никаких предпосылок к этому не было видно.

Прогресс не стоит на месте, поэтому причины обновиться на актуальные версии MySQL становятся всё более весомыми. Не так давно в одном из наших проектов настало время обновлять уютные кластеры Percona Server 5.7 до 8-й версии. Всё это происходило на платформе Ubuntu Linux 16.04. Как выполнить подобную операцию с минимальным простоем и с какими проблемами мы столкнулись при обновлении — читайте в этой статье.

В апреле инженеры Авито собирались на онлайн-посиделки с главным разработчиком ClickHouse Алексеем Миловидовым и Кириллом Шваковым, Golang-разработчиком из компании Integros. Обсуждали, как мы используем систему управления базами данных и какие сложности у нас возникают.

По мотивам встречи мы собрали статью с ответами экспертов на наши и зрительские вопросы про бэкапы, решардинг данных, внешние словари, Golang-драйвер и обновление версий ClickHouse. Она может быть полезна разработчикам, которые уже активно работают с СУБД «Яндекса» и интересуются её настоящим и будущим. По умолчанию ответы Алексея Миловидова, если не написано иное.

Осторожно, под катом много текста. Надеемся, что содержание с вопросами поможет вам сориентироваться.

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

В рамках этой задачи пользователи могут задавать системе запросы следующего вида:

• сколько посетителей прошло из области "A" в область "Б";
• сколько посетителей прошло из области "A" в область "Б" через область "C", а затем через область "Д";
• сколько времени заняло прохождение посетителя определенного типа из области "А" в область "Б".

и еще ряд подобных аналитических запросов.

Движение посетителя по областям представляет собой направленный граф. Почитав интернеты, я обнаружил, что графовые СУБД используются и для аналитических отчетов. У меня появилось желание посмотреть как будут справляться с подобными запросами графовые СУБД (TL;DR; плохо).

Предлагаю ознакомиться с расшифровкой доклада начала 2016 года Владимира Ситникова "PostgreSQL и JDBC выжимаем все соки"