При обновлении между основными версиями PostgreSQL есть несколько способов. Дамп и восстановление (dump/restore) — самый простой с точки зрения понимания, но время простоя растёт прямо пропорционально размеру базы данных, поэтому для всего, что больше нескольких терабайт, этот вариант не подходит. Логическая репликация позволяет добиться почти нулевого времени простоя, но она работает только начиная с PostgreSQL 10; если ваш исходный кластер работает на версии ниже 10, этот путь в нативном виде недоступен. Остаётся pg_upgrade — инструмент, поддерживаемый сообществом для обновления основных версий «на месте». С флагом –link он создаёт жёсткие ссылки вместо копирования файлов данных, поэтому сам шаг обновления остаётся быстрым, независимо от размера базы данных.
Эта статья основан на обновлении с версии 9.6 до 17 на Ubuntu с использованием pg_upgrade. Я проведу вас через каждый этап, отмечу моменты, которые застают людей врасплох, и поделюсь проверочными запросами, которые мы выполняем после завершения обновления.
extra_float_digits — это настройка, чья задача изменилась под ней. На протяжении большей части истории PostgreSQL она принуждала к выбору между выводом чисел с плавающей точкой, который был удобен для чтения, и выводом, который был абсолютно точным, и нельзя было иметь и то, и другое. Начиная с PostgreSQL 12 вам больше не нужно выбирать, поэтому параметр, к которому вы, возможно, привыкли прибегать, теперь вам редко понадобится.
PostgreSQL уже записывает PID-файл. Каждый раз при запуске postmaster он помещает postmaster.pid в каталог данных и удаляет его при чистом завершении работы. Этот файл является блокировкой, которая предотвращает запуск второго postmaster с тем же каталогом данных, и содержит восемь строк с деталями работающего экземпляра: PID, каталог данных, время запуска, порт, каталог сокетов и так далее. external_pid_file не заменяет его. Он просит postmaster записать второй, гораздо меньший файл в другом месте.
На протяжении всей истории PostgreSQL до настоящего момента расширение должно было находиться ровно в одном месте. CREATE EXTENSION foo читал foo.control из встроенного каталога расширений, на который указывает pg_config --sharedir, и нигде больше не искал. Если вы хотели, чтобы расширение было доступно, его файлы должны были находиться в этом каталоге, что на практике означало установку от root в системное дерево или встраивание в образ. extension_control_path, новый в PostgreSQL 18, отменяет это допущение.
Когда люди говорят, что Python медленный, они обычно обвиняют язык.
В действительности это часто зависит от того, как мы пишем код.
Python является выразительным, читабельным и мощным. Но небольшие ошибки в структуре и обработке данных могут незаметно влиять на производительность...особенно в серверных системах или приложениях с большим объемом данных.
PostgreSQL сортирует свои проблемы по степени серьёзности. ERROR прерывает текущий оператор и откатывает транзакцию, но сессия продолжает жить; вы выполняете ROLLBACK и продолжаете работать. FATAL завершает сессию, разрывая это одно подключение, пока сервер работает дальше. PANIC останавливает весь сервер. В нормальной работе граница между «ваш оператор не выполнился» и «ваше подключение потеряно» проходит между ERROR и FATAL, и почти всё, что идёт не так в повседневном SQL — опечатка, нарушение ограничения, деление на ноль — является всего лишь ERROR.
9:12 утра в понедельник. Кто-то из вашей команды открывает каталог pg_wal/archive_status/ во время паники по поводу хранилища и видит длинный список файлов, оканчивающихся на .ready. Возникает вопрос, который многие из нас задавали хотя бы раз: «Сломалась ли репликация?» Потоковые реплики всё ещё выглядят в основном нормально, но файлы .ready продолжают накапливаться, использование диска продолжает расти, и никто до конца не уверен, что на самом деле означают .ready и .done.
Что такое .ready и какие (если вообще какие) действия мне нужно предпринять? Давайте поговорим об этом сегодня.
Подсказка: Это о доставке WAL
Представьте доставку WAL как три независимых шага:
Генерация WAL
Транспортировка WAL
Воспроизведение или потребление WAL
archive_command — это один из способов транспортировки. Потоковая репликация — другой. Обратите внимание, что логическая репликация также имеет канал транспортировки, но она транспортирует декодированные данные логических изменений, а не сырые файлы сегментов WAL.
Событийный триггер (event trigger) срабатывает на события базы данных, а не на изменения строк: на ddl_command_start, sql_drop, table_rewrite и, начиная с PostgreSQL 17, на login. Они используются для аудита DDL или наложения запрета на DDL, и они идут с хорошо известным способом выстрелить себе в ногу. Напишите триггер на ddl_command_start, функция которого вызывает исключение, и теперь каждая команда DDL в базе данных завершается ошибкой, включая DROP EVENT TRIGGER, который вы использовали бы для его удаления. Документация содержит ровно этот пример — функцию abort_any_command, настроенную на прерывание всего, предположительно для того, чтобы вы узнали форму ошибки, когда уже её совершили.
event_source — это параметр для Windows, что означает, что для большинства читающих это не делает ровно ничего. Если вы запускаете PostgreSQL на Linux или в управляемом сервисе, там нет журнала событий Windows, с которым он мог бы взаимодействовать, и эта строка навсегда остаётся со значением по умолчанию. То, что следует далее, предназначено для меньшинства пользователей Windows, и сводится к одному факту, который стоит знать.
Вы просто хотите посмотреть ваши данные. Вы быстро набираете display(df) в ячейке notebook и жмете Выполнить. Это кажется совершенно безобидно - кроме того, это всего лишь предварительный просмотр вашего фрейма данных, не так ли?
Но через несколько мгновений ваш кластер начинает вращаться, ячейка работает намного дольше, чем ожидалось, и ваш браузер может даже заикаться.
Хотя display() является фантастическим инструментом для интерактивного исследования, но, если слишком сильно полагаться на него, он может незаметно задушить ваши задания Apache Spark. Давайте заглянем под капот, чтобы точно выяснить, что происходит, когда вы вызываете display(), почему все замедляется, и как простое переключение на show() может радикально улучшить вашу производительность. Продолжить чтение "Любопытный случай с display(df)"
Существует распространённое заблуждение, которое беспокоит большинство разработчиков, использующих PostgreSQL: настройте VACUUM или запустите VACUUM, и ваша база данных останется здоровой. Мёртвые кортежи будут очищены. Идентификаторы транзакций переработаны. Пространство освобождено. Дальнейших действий не требуется.
Но есть пара «грязных» секретов, о которых люди не знают. Первый из них заключается в том, что VACUUM лжёт вам о ваших индексах.
escape_string_warning включён по умолчанию уже около двадцати лет, и на современном PostgreSQL, настроенном обычным образом, он никогда не скажет вам ни слова. Это не неисправность. Условие, о котором он предупреждает, перестало быть поведением по умолчанию в 2011 году.
enable_tidscan — это параметр enable_*, который вы почти наверняка никогда не установите, и на этот раз это не предупреждение, а просто факт о том, как происходят сканирования TID. Вы не натыкаетесь на него случайно, как на последовательное сканирование или сортировку. Сканирование TID появляется только тогда, когда вы явно написали условие на ctid, поэтому тип плана, которым управляет этот параметр, появляется именно тогда, когда вы его запросили, и никак иначе.
(Для протокола: я за всю свою жизнь ни разу не видел узел tidscan.)
