Если вы не много экспериментировали с SQL Server 2022, вы может быть незнакомы с функциями DATE_BUCKET и DATETRUNC. Обе они полезны, когда дело доходит до агрегирования данных. Давайте рассмотрим каждую из этих функций на нескольких примерах.
DATE_BUCKET
Начнем с DATE_BUCKET. DATE_BUCKET дает вам возможность агрегировать данные на основе выбранного вами интервала. Допустим, мы имеем такой набор событий:
config_file сообщает серверу PostgreSQL, где находится postgresql.conf, что должно заставить вас на мгновение задуматься. Если сервер узнаёт, где находится его файл конфигурации, из параметра, а параметры берутся из файла конфигурации, как он вообще находит первый файл?
compute_query_id по умолчанию имеет значение auto, потому что разработчики PostgreSQL оказались в тупике. PostgreSQL 14 переместил вычисление идентификатора запроса в ядро сервера, чтобы всё, что нуждается в идентификаторе запроса — pg_stat_statements, pg_stat_activity, EXPLAIN и журналы, — могло использовать одно каноническое значение вместо того, чтобы в каждом случае изобретать своё. Это оставило вопрос о том, каким должно быть значение по умолчанию, и оба очевидных ответа были плохими. Вычислять идентификатор для всех — значит облагать каждый фоновый процесс хэшированием, которое ему, возможно, никогда не понадобится; не вычислять ни для кого — значит незаметно сломать все стеки мониторинга и руководства по настройке, которые предполагали наличие идентификаторов запросов. auto — это выход: вычислять идентификатор только тогда, когда кто-то, кому он нужен, запрашивает его.
Логическая репликация прошла долгий путь с момента её появления в PostgreSQL. Сейчас она применяется шире, чем когда-либо, обеспечивая обновления между версиями, мультирегиональные развёртывания и конвейеры аналитики в реальном времени. Однако значительные возможности для улучшения всё ещё остаются.
В этой статье мы покажем практические идеи по улучшению логической репликации PostgreSQL. Вы узнайте о производительности, исправлении ошибок, рефакторинге кода и улучшении функциональности подписчика.
Будут рассмотрены узкие места производительности, отсутствующие функции и тонкие ошибки — всё это ждёт своих исправителей, готовых погрузиться в код.
В этой статье мы делимся практическими уроками, которые мы извлекли из работы над логической репликацией PostgreSQL: на что обращать внимание, как тестировать и какие подводные камни ожидают на стороне издателя и подписчика. Независимо от того, новичок вы в контрибуции или опытный разработчик в поисках следующего проекта, мы надеемся, что это руководство даст вам полезный старт.
commit_timestamp_buffers — первый в алфавитном порядке из семи параметров, которые PostgreSQL 17 добавил для выполнения одной и той же задачи для семи различных кэшей, поэтому эта статья объясняет эту задачу, а остальная часть кластера параметров может остаться краткой.
commit_delay — это та единственная настройка, которая говорит групповой фиксации (group commit) PostgreSQL ждать более многочисленной группы. База данных уже сама группирует сбросы WAL: когда один фоновый процесс выполняет сброс WAL, другие, готовые к фиксации, выстраиваются за ним и присоединяются к тому же fsync. commit_delay заставляет процесс, инициирующий этот сброс, сделать паузу на заданное количество микросекунд перед его началом, в предположении, что за время паузы подойдут ещё несколько транзакций и присоединятся к группе. commit_siblings — это сторожевой параметр, который решает, стоит ли вообще делать эту паузу.
cluster_name выглядит как косметический параметр: метка, которая отображается в выводе ps, чтобы вы могли различать свои три экземпляра Postgres. На первичном сервере это всё, что он делает. На резервном сервере (standby) он может незаметно стать именем, которое первичный сервер использует, чтобы определить, удовлетворена ли синхронная репликация, — это гораздо более серьёзная задача для параметра, который большинство людей устанавливают и забывают.
"Не могли бы вы помочь мне, мы удалили файл журнала транзакций базы данных и теперь она застряла в ‘Recovery Pending’?"
Такой крик о помощи я получил пару недель назад.
"Конечно, без проблем, нам придется восстановить вашу последнюю резервную копию", - ответил я.
А потом неизбежное: "Это только база данных разработки, мы не делаем резервных копий."
Позвольте мне лирическое отступление. Вне зависимости от того, что это всего лишь база данных разработки, если это настолько важно, что вы сразу обращаетесь ко мне, значит это достаточно важно, чтобы делать бэкапы. Возможно, достаточно делать еженедельный полный бэкап, но, пожалуйста, убедитесь, что у вас всегда есть точка восстановления.
Эта история началась с книги, подаренной коллегой. Читая книгу Джимми Ангелакоса «PostgreSQL Mistakes and How to Avoid Them», я осознал одну вещь, которая давно меня беспокоила: в Postgres команда EXPLAIN выдаёт слишком много информации. Примеры, которые авторы обычно приводят при обсуждении различных аспектов систем баз данных, усложняют анализ рассматриваемой проблемы и отвлекают читателя. Так родилась идея пост-обработки вывода EXPLAIN — чтобы сделать планы запросов более читаемыми и сфокусированными на проблеме.
client_min_messages управляет тем, сколько сервер говорит вам: сообщения, которые возвращаются по сети в ваш сеанс. Его постоянно путают с параметром, управляющим тем, что сервер записывает в свой собственный журнал. Это разные задачи с разными параметрами, и путаница — это то место, где начинается большинство проблем.
client_encoding объявляет, в какой кодировке символов говорит клиент. Сервер использует этот параметр для преобразования между своей внутренней кодировкой (устанавливается во время initdb, для каждой базы данных, часто UTF-8) и тем, что клиент отправляет и ожидает получить. Значение по умолчанию — «the server’s encoding», то есть без преобразования. Контекст параметра — user, с переменной окружения PGCLIENTENCODING, которую libpq учитывает автоматически, по аналогии с application_name.
В мире UTF-8 этот параметр редко проявляется. Сервер — UTF-8, клиент — UTF-8, преобразования не происходит, жизнь хороша. Но «редко проявляется» — это не то же самое, что «не существует», и случаи, когда он проявляется, стоят понимания.
Два параметра, смежных с контрольными точками, объединённые алфавитной близостью, а не тематическим родством. checkpoint_flush_after — третий из четырёх параметров *_flush_after для выталкивания (writeback); checkpoint_warning — это журнальный параметр, который выводит предупреждение, когда контрольные точки срабатывают слишком часто. Разные задачи, разная аудитория, но ни один из них не требует 400 слов отдельно.
Кластер параметров на букву C открывается первыми двумя параметрами контрольных точек. Мы выводим их из алфавитного порядка, потому что checkpoint_completion_target определён как доля от checkpoint_timeout и не имеет смысла без него. Алфавит может подождать одну статью.
