Каждое сообщение на пути к серверному журналу проходит через трое ворот: попадает ли оно туда вообще, едет ли вместе с ним SQL, который его вызвал, и сколько его полей будет напечатано. По одному параметру на каждые ворота. Все три управляют только копией сообщения в журнале; то, что видит клиент, — дело client_min_messages, и эти два потока фильтруются независимо. Все три имеют контекст superuser: их можно устанавливать на лету в сеансе, но только суперпользователем или ролью, которой предоставлено право SET на параметр (15 и новее), и суперпользователь может ограничить их область с помощью ALTER ROLE ... SET или ALTER DATABASE ... SET. Обычная роль входа подхватывает ALTER ROLE ... SET log_min_messages во время подключения, даже если она не может установить параметр сама; я проверил.
Строка журнала состоит из двух частей: сообщение, которое определяет PostgreSQL, и всё, что перед ним, что определяете вы. log_line_prefix — это ключ соединения. Каждый факт, позволяющий связать строку с сеансом, транзакцией, клиентом или моментом в журналах другой системы, должен быть в префиксе, потому что само сообщение его не несёт. Значение по умолчанию — '%m [%p] ' начиная с 10; двенадцать лет до этого оно было пустой строкой, и строка журнала PostgreSQL из коробки не имела отметки времени. log_timezone решает, какие часы читает %m.
Эти три параметра решают, когда сборщик журналов закрывает один файл и открывает другой, и они имеют смысл только вместе с log_filename, потому что сборщик никогда ничего не удаляет: ротация — это просто «вычислить имя по шаблону и открыть его». Что произойдёт дальше, полностью зависит от того, является ли это имя новым, и три параметра здесь управляют временем и одной деталью открытия. Два из трёх названы неверно, один — ловушка в собственном примере документации, а механика достаточно коротка, чтобы изложить её полностью.
Если вы имеете дело с SQL Server в средах с несколькими одновременно работающими пользователями, то, вероятно, встречались с тупиковыми ситуациями. Тупики случаются, когда две или более транзакций блокируют друг друга, делая продолжение невозможным. Когда это происходит, вмешивается SQL Server, который откатывает одну из транзакций, позволяя другим продолжить работу. Откат транзакции получает ошибку 1205.
Понимание того, как SQL Server решает, какую транзакцию прервать, важно для построения надежных приложений. В этой статье исследуются понятие тупика, то, как SQL Server обнаруживает его, правила выбора жертвы тупика, а также приводятся практические примеры, которые вы можете выполнить сами.
Продолжить чтение "Понимание выбора жертвы тупика в SQL Server"
Все эти три параметра ничего не делают, если logging_collector выключен; они описывают файлы, которые пишет сборщик. Где, как они называются и кто может их читать. Значения по умолчанию для всех трёх хороши для ноутбука и неправильны для сервера, и причины более механистичны, чем позволяет предположить документация.
Если вы не запросили syslog, каждое сообщение, которое регистрирует PostgreSQL, — это запись в стандартный поток ошибок. Таков весь механизм, и два десятка параметров log_*, следующих за этим, — лишь уточнения к нему: что записывается, в каком формате и что перехватывает это на другом конце. Эти два параметра — та самая часть «что перехватывает», поэтому данная статья несёт на себе всю сантехнику, а остальные из этого семейства могут ссылаться сюда (logging_collector идёт после log_truncate_on_rotation; я вынес его вперёд, потому что log_destination нельзя объяснить без него).
Большая часть семейства log_* посвящена тому, что происходило внутри сеанса. Эти три — о самом сеансе: кто появился, когда, сколько времени потребовалось, чтобы впустить его, сколько он оставался и (если настаиваете) как называлась его машина. Значения по умолчанию не протоколируют ничего из этого. Это понятный выбор для ноутбука и неправильный для любого сервера, о котором вам могут отправить уведомление.
А теперь наденем болотные сапоги и отправимся в топь, которой являются все GUC-параметры журналирования PostgreSQL.
PostgreSQL 8.3 — выпуск, в котором сервер всерьёз занялся собственным хозяйством: autovacuum включён по умолчанию, контрольные точки распределены по интервалу, а не сброшены в его конце, HOT-обновления. Тот же выпуск добавил три параметра для наблюдения за этим и поставил все три выключенными. Четырнадцать лет и четырнадцать мажорных версий спустя PostgreSQL 15 включил два из них. Третий всё ещё ждёт, и я объясню, почему он не должен ждать.
listen_addresses решает, какие TCP-сокеты существуют. Он ничего не говорит о том, кому можно ими пользоваться; это дело pg_hba.conf, и большая часть огорчений, которые вызывает этот параметр, происходит из-за путаницы в этих двух вещах.
lo_compat_privileges возвращает защиту больших объектов к состоянию PostgreSQL 8.4 — последнего выпуска, в котором большой объект не принадлежал никому конкретно и любая роль, способная подключиться к базе данных, могла его прочитать, перезаписать или удалить. В PostgreSQL 9.0 у больших объектов появился владелец и список управления доступом (ACL). Этот параметр — переключатель, который делает вид, будто этого не произошло.
local_preload_libraries — это параметр предзагрузки для тех, кому не разрешено использовать два других. Он загружает разделяемые библиотеки в фоновый процесс во время подключения, так же как session_preload_libraries, с двумя отличиями: любая роль может его установить, и в обмен на это он будет загружать только из одного каталога — $libdir/plugins, который в стандартной установке пуст, если вообще существует.
lock_timeout — это параметр безопасности миграций схемы, который, кстати, применяется ко всем блокировкам в системе. Он ограничивает, как долго оператор будет ждать получения любой отдельной «тяжёлой» блокировки, прежде чем сдаться с ошибкой ERROR: canceling statement due to lock timeout (SQLSTATE 55P03, тот же код, что и у сбоев NOWAIT, что удобно для клиентского кода). Значение по умолчанию — 0, что означает «отключено». Контекст — пользовательский. Миллисекунды, если вы не указали единицы измерения. Он появился в 9.3, и то, что он дождался 2013 года, говорит вам о том, как долго люди жили с проблемой, которую он решает.
Ни один из этих параметров не имеет никакого отношения к методу аутентификации krb5, поскольку PostgreSQL удалил этот метод в версии 9.4. Приставка krb_ сохраняется по той обычной причине, по которой имена параметров переживают всё: переименование GUC ломает каждый postgresql.conf, который его упоминает. На самом деле они настраивают аутентификацию GSSAPI — метод gss в pg_hba.conf, который означает Kerberos, а на практике это обычно означает Active Directory (их «собратьям повезло меньше: krb_server_hostname ушёл в 8.4, а krb_srvname пошёл ко дну вместе с кораблём в 9.4).
Большая часть политики GSSAPI живёт в pg_hba.conf, построчно: include_realm, krb_realm, map. Эти две настройки являются общесерверными, поэтому они вообще являются GUC. Обе имеют контекст sighup; перезагрузки конфигурации достаточно, перезапуск не нужен.
«Отказоустойчивый PostgreSQL» обычно означает выборы лидера, потоковые реплики, автоматическое переключение при сбое, проверки работоспособности и массу тщательного связывания. С оператором CYBERTEC PG Operator (CPO) это означает YAML-файл из 14 строк. Вот он целиком, от начала до конца, на ноутбуке с minikube.
Каждая команда и каждый вывод ниже взяты из учебного руководства, которое мы выполнили от начала до конца на свежем minikube (Kubernetes 1.30, CPO 0.9.2, PostgreSQL 18.4).
