SQL-Ex blog

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 3: HAProxy

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Добро пожаловать в третью часть нашей серии по созданию высокодоступного кластера Postgres с помощью Patroni! Часть первая была полностью посвящена созданию DCS с использованием etcd для обеспечения критически важного уровня DCS для кластера, а часть вторая добавила Patroni и Postgres в программный стек. Хотя на этом этапе можно остановиться и использовать кластер как есть, есть ещё один компонент, который сделает его гораздо более функциональным в целом.

Новым соединениям нужен способ легко и надёжно достигать основного узла. Patroni предоставляет REST-интерфейс для опроса каждого узла о его состоянии, что делает его идеальным решением для любого программного обеспечения или уровня балансировки нагрузки, совместимого с HTTP-проверками. Часть третья посвящена добавлению HAProxy для выполнения этой роли, завершая кластер уровнем маршрутизации.

Надеюсь, у вас всё ещё есть три виртуальные машины, на которых вы установили etcd, Postgres и Patroni. Они нам понадобятся для финального этапа, так что если вы ещё не прошли шаги из частей первой и второй, вернитесь, когда будете готовы.

В противном случае, давайте завершим кластер!

Продолжить чтение "Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx"

Автор: Ilya Kosmodemiansky, An Ultimate Guide to Upgrading Your PostgreSQL Installation: From 17 to 18

Обновления мажорных версий PostgreSQL — одна из тех задач, с которой регулярно приходится сталкиваться каждому администратору баз данных. Это рутинная операция, но она также полна мелких, потенциально опасных деталей, которые могут превратить простое окно обслуживания в инцидент. Выполнив сотни обновлений в разных средах за многие годы, я хочу поделиться комплексным, практическим руководством по обновлению с PostgreSQL 17 на 18, с особым вниманием к тому, что изменилось и что наконец-то улучшилось в самом процессе обновления.

Эта статья основана на моём докладе на PGConf.EU 2024, дополненном с учётом пути обновления 17→18 и значительных улучшений, появившихся в версии 18. В это время года мы обычно рекомендуем нашим клиентам обновляться: текущий релиз 18.3 достаточно стабилен.

Продолжить чтение "Полное руководство по обновлению PostgreSQL с 17 на 18"

Пересказ статьи Jared Westover. Calculate a Moving Average with T-SQL Windowing Functions

Хотя мне нравится использовать SQL Server, есть несколько вещей, для которых лучше подходят другие инструменты. Например, вычисление скользящего среднего или накопительных итогов зачастую проще выполнить с помощью таких инструментов, как Power BI или Excel. Это связано с тем, что Microsoft разрабатывала эти программы, имея в виду подобную функциональность. Недавно мы оптимизировали сложный запрос скользящего среднего, написанный для SQL Server 2008R2. Сюрприз! В SQL Server нет встроенной функции для вычисления скользящего среднего. Но не беспокойтесь, я покажу вам, как это сделать.

В этой статье я рассмотрю два метода для создания скользящего среднего в SQL Server. Мы начнем со старого и менее производительного способа, который присутствовал в нашей производственной системе. Кто знает, может быть вы все еще используете устаревшую версию SQL Server. Затем я покажу современный способ с использованием оконных функций и то, как добавление индекса, все меняет. К концу статьи вы будете готовы, чтобы справиться с этим скользящим средним в следующий раз, когда это кому-то понадобится, а не просто скажете: "Используй Excel".

Продолжить чтение "Вычисление скользящего среднего с помощью оконных функций в T-SQL"

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 2: Postgres and Patroni

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Продолжить чтение "Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni"

Автор: Umair Shahid, Thinking of PostgreSQL High Availability as Layers

Высокая доступность для PostgreSQL часто рассматривается как единое, большое, драматичное решение: «Делаем мы HA или нет?»

Такой подход толкает команды к двум крайностям:

• «геройская архитектура», которая стоит дорого и всё равно вызывает напряжение при эксплуатации, или


• минималистичная архитектура, которую все надеются, что будет просто продолжать работать.

Более спокойный способ проектирования — рассматривать HA и аварийное восстановление (DR) как слои. Вы начинаете с базового уровня, а затем добавляете конкретные возможности только тогда, когда ваши RPO/RTO и бюджет их оправдывают.

Давайте пройдём по слоям от «одного основного узла» до «многосайтовой готовности к аварийному восстановлению».

Продолжить чтение "Представление о высокой доступности PostgreSQL как о слоях"

Пересказ статьи Tomasz Gintowt. PostgreSQL Prepared Queries (Statements) For Beginners

Когда мы пишем запросы SQL, то часто выполняем один и тот же запрос снова и снова лишь меняя значения.

PostgreSQL обладает функциональностью, которая помогает решить эту проблему, - подготовленные запросы (также называемые подготовленными операторами).

В этой статье мы выясним:

• Что такое подготовленные запросы.


• Чем они полезны.


• Как их использовать в PostgreSQL.


• Реальные примеры, которые вы сами сможете опробовать.

Никаких непонятных слов. Никакой сложной теории. Простые ясные примеры.
Продолжить чтение "Подготовленные запросы (операторы) в PostgreSQL для начинающих"

§ Новая задача DML от pegoopik опубликована под номером 27 (оценка сложности 2 балла).

Выполнены следующие переносы:

27 (старая) -> 18 -> 9 -> (-8)

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 179 (SELECT)		6		5
 Guest's book		5		10
 20 (DML)		4		7

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik  	5
 s108  	3
 selber  	3
 rock_4  	2

Продолжить чтение "Новости за 2026-03-14 - 2026-03-20"

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 1: etcd

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Предыдущая статья из цикла PG Phriday была посвящена архитектуре кластера Patroni — как и почему он устроен именно так. На этот раз речь пойдёт о непосредственном построении такого кластера. Я часто слышал, что эксплуатация Postgres может пугать, а Patroni находится на уровень выше. Что ж, со вторым я спорить не буду, но я могу хотя бы попытаться облегчить некоторые трудности.

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

• Etcd


• Postgres и Patroni


• HAProxy

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

С этим разобрались, давайте приступим!

Продолжить чтение "Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd"

Автор: Warda Bibi, How PostgreSQL Scans Your Data

Чтобы понять, как PostgreSQL сканирует данные, сначала нужно понять, как PostgreSQL их хранит.

Таблица хранится как набор 8-килобайтных страниц (по умолчанию) на диске. Каждая страница имеет заголовок, массив указателей на элементы (также называемых линейными указателями) и сами данные кортежей, растущие снизу вверх. Каждый кортеж имеет свой собственный заголовок, содержащий информацию о видимости: xmin, xmax, cmin/cmax и биты infomask.

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

• Последовательное сканирование (Sequential Scan)


• Индексное сканирование (Index Scan)


• Сканирование только индекса (Index-Only Scan)


• Сканирование по битовой карте (Bitmap Index Scan)

В этой статье мы рассмотрим каждый из этих типов сканирования по отдельности.

Продолжить чтение "Как PostgreSQL сканирует ваши данные"

Пересказ статьи Jeyaram Ayyalusamy. 29 - PostgreSQL 17 Performance Tuning: Understanding Estimates vs. Actuals in Query Plans

Настройка производительности в PostgreSQL часто сводится к единственному навыку: умению читать планы выполнения. Команда PostgreSQL EXPLAIN ANALYZE - главный инструмент для этого. Она показывает не только то, как выполняется запрос, но и то, чего ожидал оптимизатор PostgreSQL, и что произошло на самом деле.

При просмотре плана выполнения вы всегда должны задать себе два больших вопроса:

1. Оправданы ли временные параметры, указанные в выводе команды EXPLAIN ANALYZE, для данного запроса?


2. В каком месте происходит внезапный скачок времени выполнения?

Места этих скачков в плане выполнения часто обнаруживают точный узел или операцию, которая замедляет ваш запрос.
Продолжить чтение "Настройка производительности в PostgreSQL 17: понимание преполагаемого и действительного планов выполнения"

§ Изменения среди лидеров рейтинга

Рейтинг	Участник (решенные задачи)
 20		selber (179)

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Lysenko O. (Oleg15062025)     	15	26	22	0	22	2327
 Бадахьян С. (wamp.j)          	16	21	22	0	22	4014
 Odnokurtsev  (AlFochino)      	12	63	21	0	21	1099
 Kad V.Y.  (s108)              	11	57	17	0	17	968
 Сафронов П.А.  (Paulus73)     	7	97	14	3	17	260
 Сильван  (silvr)              	2	67	4	0	4	709

Продолжить чтение "Новости за 2026-03-07 - 2026-03-13"

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Fuzzy String Search II

В последней статье мы проверяли нечеткое соответствие строк при помощи новых функций в SQL Server 2025. Мы знаем, что сравнение строк всегда вызывало сложности, когда у нас нет качественных данных. Если нам нужно точное совпадение, SQL Server работает отлично. Однако мы часто ждем от пользователей ввода значений без опечаток и знать, какие значения они хотят найти. Или хотя бы знать часть строки.

В SQL Server 2025 появилось несколько новых функций, которые помогают с нечетким совпадением строк. В последней статье были рассмотрены функции расстояния, EDIT_DISTANCE() и EDIT_DISTANCE_SIMILARITY(). В этой статье мы проверим две другие функции, JARO_WINKLER_DISTANCE() и JARO_WINKLER_SIMILARITY(). Как и другие функции, они находятся в предварительной версии (по состоянию на январь 2026 г.), так что будьте осторожны с использованием их в продакшене. Вам также необходимо включить эти функции как часть конфигурации области базы данных. Мы рассмотрели это в первой статье.

Это часть серии статей, посвященной тому, как язык T-SQL развивается в SQL Server 2025.

Примечание. Некоторые из этих изменений уже доступны в различных продуктах Azure SQL.
Продолжить чтение "T-SQL в SQL Server 2025: нечеткий поиск строки II"

Автор: Shaun Thomas, How Patroni Brings High Availability to Postgres

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Давайте признаем: существует множество инструментов высокой доступности (High Availability) для управления кластерами Postgres. Этот ландшафт эволюционировал на протяжении десятилетий, достигнув своего нынешнего состояния, и в сообществе царит немалая путаница. Будь то Reddit, списки рассылки Postgres, Slack, Discord, IRC, доклады на конференциях или любые другие площадки, один из самых частых вопросов, которые мне задают: «Как сделать Postgres отказоустойчивым?»

Где-то с 2017 года мой ответ неизменен: «Просто используйте Patroni». Если только в экосистеме Postgres не произойдёт что-то чудесное, этот ответ вряд ли изменится. Но почему? Что делает Patroni «окончательным ответом», когда речь заходит о Postgres и высокой доступности? Это во многом связано с тем, как Patroni выполняет свою работу, и именно это мы и рассмотрим в данной статье.

Слон в посудной лавке

Сам по себе Postgres не является кластером в том смысле, который большинство людей вкладывает в это слово. Они могут представлять себе сложную массу взаимосвязанных серверов, яростно моргающих лампочками друг на друга, осведомлённых о каждом вычислении, совершаемом другими, и готовых взять на себя управление в случае сбоя одного из них. В реальности же «официальное» использование слова «кластер» в мире Postgres означает просто одну или несколько баз данных, связанных с одним экземпляром Postgres. Это прямо указано в документации по Creating a Database Cluster.

«A database cluster is a collection of databases that is managed by a single instance of a running database server».

Концепция взаимодействия нескольких таких экземпляров была настолько чужда Postgres, что даже не существовала до выхода версии 9.0, которая в 2010 году представила горячие резервные серверы (Hot Standbys) и потоковую репликацию. А как работают горячие резервные экземпляры? Так же, как и основной узел: они применяют страницы WAL к файлам кучи. Эти страницы WAL могут поступать из архивированных файлов WAL или передаваться потоком с основного сервера, но по сути это всё ещё непрерывное восстановление после сбоя под другим именем.

Это важно, потому что каждый узел Postgres до сих пор почти ничего не знает о других узлах в этом импровизированном кластере, спустя более чем 15 лет. Само по себе это не обязательно проблема, но это выдает определённую долю умышленного неведения со стороны каждого узла. Почему каждый узел не заботится о существовании других узлов или даже не признаёт их существования?

Конечно же, каждый узел должен заботиться о том, что другие узлы существуют! Именно так и родился каждый инструмент высокой доступности для Postgres. Slony и PgPool-II были, вероятно, первыми из них, использование Pacemaker и Corosync всегда было популярно в ранние дни, затем появились Bucardo, repmgr и EFM. Это лишь наиболее примечательные примеры, известные большинству сообщества.

Но после первоначального выпуска Patroni произошла забавная вещь: неумолимый поток инструментов высокой доступности для Postgres внезапно прекратился. Все сразу поняли, что в нём есть что-то, что кардинально отличает его от предшественников. Давайте поговорим о том, почему.

Продолжить чтение "Как Patroni обеспечивает высокую доступность PostgreSQL"

Пересказ статьи Aaron Bertrand. Common SQL Server Problems: Invalid Length

Это еще одна часть моей серии, представляющей общие проблемы в SQL Server. Сейчас мы поговорим о самой распространенной ошибке: invalid length (неверная длина).

Что означает ошибка invalid length в SQL Server?

Msg 537, Level 16, State 3

Invalid length parameter passed to the LEFT or SUBSTRING function.

Как показано выше, ошибка invalid length возникает, когда вы передаете некорректный или неожиданный параметр в строковую функцию. Например:

DECLARE @FirstName nvarchar(32) = N'frank';

SELECT LEFT(@FirstName, -1);

Продолжить чтение "Общие проблемы в SQL Server: Invalid Length"

Посетительниц сайта поздравляем с наступающим праздником 8 Марта! Желаем здоровья, счастья и вечной красоты!

§ Идя навстречу тем участникам, кто не является фанатом футбола, хоть и поздно, но опубликованы пояснения к схеме "Футбольный клуб" с подробным изложением правил игры от selber.

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 Certification		9		12
 55 (DML)		4		5
 59 (DML)		3		4
 51 (Learn)		3		9
 56 (DML)		2		2

Продолжить чтение "Новости за 2026-02-28 - 2026-03-06"