PostgreSQL: How to reload config settings without restarting database
Reloading the PostgreSQL configuration without restarting the entire database can be efficiently achieved using the pg_ctl reload command. Performing Postgres reload config is a simple one-liner and should be part of your toolbox.
Table of Contents
Why is Postgres Reload Config Important?
If you are making modifications to the Postgres configuration file postgresql.conf (or similar), and you want to new settings to take effect, reload Postgres config without restart in one of the ways shown below. Another similar command essential to PostgreSQL, is to reload pg_hba.conf.
Method 1: From the command-line shell
From the command-line prompt on your Linux server, run the following command:
Method 2: Using psql
From the command-line run the psql command and run the following SQL statement:
Method 3: Using systemctl reload postgresql
Using systemctl to reload the PostgreSQL configuration is a method common in Linux-based systems. In order to reload the PostgreSQL configuration without interrupting the database service, you simply need to type sudo systemctl reload postgresql in the command line. This command tells the system to load the latest configuration changes. It’s an effective way of ensuring your PostgreSQL system runs with the most updated settings without causing any downtime.
Using any method will not interrupt any active queries or connections to the database, thus applying these changes seamlessly.
pg_upgrade
pg_upgrade (ранее назывался pg_migrator)позволяет обновить данные,хранящиеся в файлах данных PostgreSQL,до более поздней основной версии PostgreSQL без дампа/восстановления данных,которые обычно требуются для обновления основных версий,например,с 9.5.8 до 9.6.4 или с 10.7 до 11.2.Это не требуется для обновления минорных версий,например,с 9.6.2 до 9.6.3 или с 10.1 до 10.2.
В основных релизах PostgreSQL регулярно добавляются новые функции,которые часто меняют компоновку системных таблиц,но внутренний формат хранения данных редко меняется.pg_upgrade использует этот факт для выполнения быстрого обновления путем создания новых системных таблиц и простого повторного использования старых пользовательских файлов данных.Если будущий основной выпуск когда-либо изменит формат хранения данных таким образом,что старый формат данных станет нечитаемым,pg_upgrade не будет использоваться для таких обновлений.(Сообщество постарается избежать таких ситуаций).
pg_upgrade делает все возможное,чтобы убедиться,что старый и новый кластеры бинарно совместимы,например,проверяя совместимые настройки времени компиляции,включая 32/64-битные двоичные файлы.Важно,чтобы любые внешние модули также были бинарно совместимы,хотя это не может быть проверено pg_upgrade.
pg_upgrade поддерживает обновление с версии 9.2.X и более поздних до текущего основного выпуска PostgreSQL,включая snapshot и бета-версии.
Options
pg_upgrade принимает следующие аргументы командной строки:
старый каталог исполняемых файлов PostgreSQL; переменная среды PGBINOLD
-B bindir —new-bindir= bindir
новый каталог исполняемых файлов PostgreSQL; по умолчанию — это каталог, в котором находится pg_upgrade; переменная среды PGBINNEW
проверять только кластеры,не изменять никаких данных.
-d configdir —old-datadir= configdir
каталог конфигурации старого кластера базы данных; переменная среды PGDATAOLD
-D configdir —new-datadir= configdir
каталог конфигурации нового кластера базы данных; переменная среды PGDATANEW
-j njobs —jobs=njobs
количество одновременных процессов или потоков для использования
использовать жесткие ссылки вместо копирования файлов в новый кластер
По умолчанию pg_upgrade будет ждать, пока все файлы обновленного кластера будут безопасно записаны на диск. Этот параметр заставляет pg_upgrade возвращаться без ожидания, что быстрее, но означает, что последующий сбой операционной системы может привести к повреждению каталога данных. Как правило, этот параметр полезен для тестирования, но его не следует использовать в производственной установке.
-o options —old-options options
параметры, передаваемые непосредственно старой команде postgres ; добавляются несколько вызовов опций
-O options —new-options options
параметры, которые нужно передать непосредственно новой команде postgres ; добавляются несколько вызовов опций
-p port —old-port= port
номер порта старого кластера; переменная среды PGPORTOLD
-P port —new-port= port
новый номер порта кластера; переменная среды PGPORTNEW
сохранять SQL и лог-файлы даже после успешного завершения работы
-s dir —socketdir= dir
каталог, используемый для сокетов postmaster во время обновления; по умолчанию — текущий рабочий каталог; переменная среды PGSOCKETDIR
-U username —username= username
имя пользователя установки кластера; переменная окружения PGUSER
подробный внутренний журнал
отобразить информацию о версии,затем выйти
Используйте эффективное клонирование файлов (также известное как «ссылки» в некоторых системах) вместо копирования файлов в новый кластер. Это может привести к почти мгновенному копированию файлов данных, давая преимущества скорости -k / —link , оставляя старый кластер нетронутым.
Клонирование файлов поддерживается только на некоторых операционных системах и файловых системах.Если он выбран,но не поддерживается,запуск pg_upgrade приведет к ошибке.В настоящее время оно поддерживается на Linux (ядро 4.5 или более поздняя версия)с Btrfs и XFS (на файловых системах,созданных с поддержкой отражения),а также на MacOS с APFS.
оказать помощь,затем выйти
Usage
Это шаги для выполнения обновления с помощью pg_upgrade:
При желании переместить старый кластер
Если вы используете каталог установки для конкретной версии, например, /opt/PostgreSQL/15 , вам не нужно перемещать старый кластер. Все графические установщики используют каталоги установки для конкретных версий.
Если ваш установочный каталог не зависит от версии, например, /usr/local/pgsql , необходимо переместить текущий установочный каталог PostgreSQL, чтобы он не мешал новой установке PostgreSQL. После выключения текущего сервера PostgreSQL можно безопасно переименовать установочный каталог PostgreSQL; предполагая, что старый каталог /usr/local/pgsql , вы можете сделать:
чтобы переименовать каталог.
Для исходных установок соберите новую версию
Соберите новый исходный код PostgreSQL с флагами configure , совместимыми со старым кластером. pg_upgrade проверит pg_controldata , чтобы убедиться, что все настройки совместимы, перед запуском обновления.
Установите новые двоичные файлы PostgreSQL
Установите исполняемые файлы нового сервера и файлы поддержки.pg_upgrade включена в установку по умолчанию.
Для исходных установок, если вы хотите установить новый сервер в произвольном месте, используйте prefix переменную:
Инициализируйте новый кластер PostgreSQL
Инициализируйте новый кластер с помощью initdb . Опять же, используйте совместимые флаги initdb , соответствующие старому кластеру. Многие готовые установщики делают этот шаг автоматически. Нет необходимости запускать новый кластер.
Установить файлы общих объектов расширения
Многие расширения и пользовательские модули, как из contrib ,так и из другого источника, используют общие объектные файлы (или библиотеки DLL), например, pgcrypto.so . Если старый кластер использовал их, файлы общих объектов, соответствующие новому бинарному файлу сервера, должны быть установлены в новом кластере, обычно с помощью команд операционной системы. Не загружайте определения схемы, например, CREATE EXTENSION pgcrypto , потому что они будут скопированы из старого кластера. Если обновления расширений доступны, pg_upgrade сообщит об этом и создаст сценарий, который можно будет запустить позже, чтобы обновить их.
Скопируйте пользовательские файлы полнотекстового поиска
Скопируйте любые пользовательские файлы полнотекстового поиска (словарь,синоним,тезаурус,стоп-слова)из старого кластера в новый.
Adjust authentication
pg_upgrade будет подключаться к старому и новому серверам несколько раз, поэтому вы можете установить аутентификацию на peer узлах в pg_hba.conf или использовать файл
Остановите оба сервера
Убедитесь,что оба сервера баз данных остановлены,например,на Unix:
или в Windows,используя правильные имена служб:
Потоковая репликация и резервные серверы отправки логов могут оставаться запущенными до следующего шага.
Подготовьтесь к обновлению резервного сервера
Если вы обновляете резервные серверы с помощью методов, описанных в разделе Шаг 11 , убедитесь, что старые резервные серверы подключены, запустив pg_controldata для старых основного и резервного кластеров. Убедитесь, что значения «Последнее расположение контрольной точки» совпадают во всех кластерах. (Возможно несоответствие, если старые резервные серверы были отключены раньше, чем старые первичные, или если старые резервные серверы все еще работают.) Кроме того, убедитесь, что в файле postgresql.conf в новом первичном кластере для wal_level не установлено minimal
Run pg_upgrade
Всегда запускайте двоичный файл pg_upgrade нового сервера, а не старого. pg_upgrade требует указания старых и новых каталогов данных и исполняемых файлов ( bin ) кластера . Вы также можете указать значения пользователя и порта, а также указать, хотите ли вы, чтобы файлы данных были связаны или клонированы вместо поведения копирования по умолчанию.
Если вы используете режим связывания, обновление будет намного быстрее (без копирования файлов) и будет использовать меньше дискового пространства, но вы не сможете получить доступ к своему старому кластеру после запуска нового кластера после обновления. В режиме связывания также требуется, чтобы старый и новый каталоги данных кластера находились в одной файловой системе. (Табличные пространства и pg_wal могут находиться в разных файловых системах.) Режим клонирования обеспечивает те же преимущества в скорости и дисковом пространстве, но не приводит к невозможности использования старого кластера после запуска нового кластера. Режим клонирования также требует, чтобы старый и новый каталоги данных находились в одной файловой системе. Этот режим доступен только в определенных операционных системах и файловых системах.
Параметр —jobs позволяет использовать несколько ядер ЦП для копирования/связывания файлов, а также для параллельного создания дампа и восстановления схем базы данных; хорошим местом для начала является максимальное количество ядер ЦП и табличных пространств. Этот вариант может значительно сократить время обновления сервера с несколькими базами данных, работающего на многопроцессорной машине.
Для пользователей Windows необходимо войти в учетную запись администратора, а затем запустить оболочку от имени пользователя postgres и указать правильный путь:
а затем запустите pg_upgrade с цитируемыми каталогами,например:
После запуска pg_upgrade проверит совместимость двух кластеров, а затем выполнит обновление. Вы можете использовать pg_upgrade —check только для выполнения проверок, даже если старый сервер все еще работает. pg_upgrade —check также укажет на любые ручные настройки, которые вам нужно будет сделать после обновления. Если вы собираетесь использовать режим ссылки или клонирования, вам следует использовать параметр —link или —clone с —check , чтобы включить проверки для конкретного режима. pg_upgrade требует разрешения на запись в текущий каталог.
Очевидно,что никто не должен получать доступ к кластерам во время обновления.pg_upgrade по умолчанию запускает серверы на порту 50432,чтобы избежать непреднамеренных клиентских подключений.Вы можете использовать один и тот же номер порта для обоих кластеров при обновлении,потому что старый и новый кластеры не будут работать одновременно.Однако,при проверке старого работающего сервера,старый и новый номера портов должны быть разными.
Если при восстановлении схемы базы данных pg_upgrade , pg_upgrade завершится, и вам придется вернуться к старому кластеру, как описано в шаге 17 ниже. Чтобы снова попробовать pg_upgrade , вам нужно будет изменить старый кластер, чтобы восстановление схемы pg_upgrade прошло успешно. Если проблема contrib модулем contrib , вам может потребоваться удалить модуль contrib из старого кластера и установить его в новом кластере после обновления, предполагая, что модуль не используется для хранения пользовательских данных.
Обновите резервные серверы потоковой репликации и доставки журналов
Если вы использовали режим связи и у вас есть резервные серверы Streaming Replication (см. Раздел 27.2.5 ) или Log-Shipping (см. Раздел 27.2 ), вы можете выполнить следующие действия, чтобы быстро обновить их. Вы не будете запускать pg_upgrade на резервных серверах, а скорее будете запускать rsync на основном. Пока не запускайте никакие серверы.
Если вы не использовали режим связи, у вас нет или вы не хотите использовать rsync или хотите более простое решение, пропустите инструкции в этом разделе и просто воссоздайте резервные серверы после завершения pg_upgrade и запуска нового основного.
Установите новые двоичные файлы PostgreSQL на резервные серверы
Убедитесь,что новые исполняемые файлы и файлы поддержки установлены на всех резервных серверах.
Убедитесь, что новые резервные каталоги данных не существуют
Убедитесь, что новые резервные каталоги данных не существуют или пусты. Если была запущена initdb, удалите новые каталоги данных резервных серверов.
Установить файлы общих объектов расширения
Установите на новые резервные копии те же файлы общих объектов расширений,которые вы установили в новом первичном кластере.
Остановить резервные серверы
Если резервные серверы все еще работают,остановите их сейчас,воспользовавшись приведенными выше инструкциями.
Сохранить файлы конфигурации
Сохраните любые файлы конфигурации из каталогов конфигурации старых резервных серверов, которые вам необходимо сохранить, например postgresql.conf (и любые файлы, включенные в него), postgresql.auto.conf , pg_hba.conf , потому что они будут перезаписаны или удалены в следующем шаг.
Run rsync
При использовании режима связи резервные серверы можно быстро обновить с помощью rsync. Для этого из каталога на первичном сервере, который находится над старым и новым каталогами кластера баз данных, запустите это на первичном сервере для каждого резервного сервера:
где old_cluster и new_cluster относятся к текущему каталогу на первичном remote_dir , а remote_dir находится над старым и новым каталогами кластера на резервном сервере . Структура каталогов в указанных каталогах на основном и резервном серверах должна совпадать. Обратитесь к странице руководства rsync для получения подробной информации об указании удаленного каталога, например,
Вы можете проверить, что будет делать команда, используя параметр rsync —dry-run . Хотя rsync должен запускаться на первичном по крайней мере для одного резервного, можно запустить rsync на модернизированном резервном для обновления других резервных, пока обновленный резервный не запущен.
Это делается для записи ссылок,созданных в режиме ссылок pg_upgrade,которые соединяют файлы старого и нового кластеров на основном сервере.Затем он находит соответствующие файлы в старом резервном кластере и создает для них ссылки в новом резервном кластере.Файлы,которые не были связаны на первичном сервере,копируются с первичного на резервный.(Обычно они маленькие.)Это обеспечивает быстрое обновление в режиме ожидания.К сожалению,rsync ненужно копировать файлы,связанные с временными и незарегистрированными таблицами,потому что эти файлы обычно не существуют на резервных серверах.
Если у вас есть табличные пространства,вам нужно запустить аналогичную команду rsync для каждого каталога табличных пространств,например:
Если вы переместили pg_wal за пределы каталогов данных, rsync должен быть запущен и в этих каталогах.
Настройка потоковой репликации и резервных серверов доставки журналов
Настройте серверы для доставки журналов. (Вам не нужно запускать pg_backup_start() и pg_backup_stop() или делать резервную копию файловой системы, поскольку резервные резервные копии все еще синхронизированы с основной.) Слоты репликации не копируются и должны создаваться заново.
Restore pg_hba.conf
Если вы изменили pg_hba.conf , восстановите его исходные настройки. Также может потребоваться настроить другие файлы конфигурации в новом кластере, чтобы они соответствовали старому кластеру, например postgresql.conf (и любые файлы, включенные в него), postgresql.auto.conf .
Запустить новый сервер
Теперь новый сервер можно безопасно запустить,а затем и любые резервные серверы rsync’ed.
Post-upgrade processing
Если требуется какая-либо пост-обработка,pg_upgrade будет выдавать предупреждения по мере ее завершения.Он также сгенерирует файлы скриптов,которые должны быть запущены администратором.Файлы скриптов будут подключаться к каждой базе данных,которая нуждается в пост-обработке.Каждый скрипт должен быть запущен с использованием:
Скрипты могут быть запущены в любом порядке и могут быть удалены после их запуска.
Caution
В целом небезопасно получать доступ к таблицам,на которые ссылаются в скриптах реконструкции,до тех пор,пока скрипты реконструкции не завершат свою работу;это может привести к неправильным результатам или низкой производительности.К таблицам,на которые нет ссылок в сценариях реконструкции,можно получить доступ немедленно.
Statistics
Поскольку статистика оптимизатора не передается с помощью pg_upgrade , вам будет предложено запустить команду для восстановления этой информации в конце обновления. Возможно, вам потребуется настроить параметры подключения в соответствии с вашим новым кластером.
Удалить старый кластер
Когда вы будете удовлетворены обновлением, вы можете удалить каталоги данных старого кластера, запустив упомянутый сценарий после завершения pg_upgrade . (Автоматическое удаление невозможно, если у вас есть определяемые пользователем табличные пространства внутри старого каталога данных.) Вы также можете удалить старые каталоги установки (например, bin , share ).
Возврат к старому кластеру
Если после запуска pg_upgrade вы захотите вернуться к старому кластеру, есть несколько вариантов:
Если —check опция —check , старый кластер не был изменен; его можно перезапустить.
Если опция —link не использовалась, старый кластер не был изменен; его можно перезапустить.
Если —link опция —link , файлы данных могли бы использоваться совместно старым и новым кластером:
Если pg_upgrade прервался до начала связывания, старый кластер не был изменен; его можно перезапустить.
Если вы не запускали новый кластер, старый кластер не был изменен, за исключением того, что при запуске связывания суффикс .old был добавлен к $PGDATA/global/pg_control . Чтобы повторно использовать старый кластер, удалите суффикс .old из $PGDATA/global/pg_control ; затем вы можете перезапустить старый кластер.
Если вы запустили новый кластер,он был записан в общие файлы,и использовать старый кластер небезопасно.В этом случае старый кластер нужно будет восстановить из резервной копии.
Notes
pg_upgrade создает различные рабочие файлы, такие как дампы схемы, хранящиеся в pg_upgrade_output.d в каталоге нового кластера. При каждом запуске создается новый подкаталог с отметкой времени, отформатированной в соответствии с ISO 8601 ( %Y%m%dT%H%M%S ), где хранятся все сгенерированные файлы. pg_upgrade_output.d и содержащиеся в нем файлы будут удалены автоматически, если pg_upgrade завершится успешно; но в случае возникновения проблем файлы могут предоставить полезную информацию для отладки.
pg_upgrade запускает недолговечные постмастеры в старом и новом каталогах данных. Временные файлы сокетов Unix для связи с этими почтмейстерами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях путь к текущему каталогу может быть слишком длинным, чтобы быть допустимым именем сокета. В этом случае вы можете использовать опцию -s , чтобы поместить файлы сокета в какой-либо каталог с более коротким именем пути. В целях безопасности убедитесь, что этот каталог недоступен для чтения или записи другим пользователям. (Это не поддерживается в Windows.)
Обо всех случаях отказа,восстановления и реиндексации будет сообщать pg_upgrade,если они повлияют на вашу установку;пост-обновленные скрипты для восстановления таблиц и индексов будут сгенерированы автоматически.Если вы пытаетесь автоматизировать обновление многих кластеров,вы должны обнаружить,что кластеры с идентичными схемами баз данных требуют одних и тех же шагов постобновления для всех обновлений кластеров;это происходит потому,что шаги постобновления основаны на схемах баз данных,а не на пользовательских данных.
Для тестирования развертывания создайте копию старого кластера только на основе схемы,вставьте фиктивные данные и обновите их.
pg_upgrade не поддерживает обновление баз данных, содержащих столбцы таблиц, с использованием этих системных типов данных, ссылающихся на reg* OID:
Обновление PostgreSQL в Linux
У блога появился хостинг, его любезно предоставила компания Облакотека. Облакотека — облачные сервисы для создания и управления виртуальной ИТ-инфраструктурой.
Если вам понравился мой блог и вы хотели бы видеть на нем еще больше полезных статей, большая просьба поддержать этот ресурс.
Если вы размещаете материалы этого сайта в своем блоге, соц. сетях, и т.д., убедительная просьба публиковать обратную ссылку на оригинал
How to upgrade PostgreSQL from 14 to 15
The new PostgreSQL 15 has been released. There are multiple ways to upgrade from the old version 14, and the easiest one is by using the pg_upgrade tool. Here is a quick tutorial for Ubuntu (or Debian) systems. And, please, do not forget to back up your data!
Update packages and install the new PostgreSQL 15.
Check if there are any differences in the config files.
Stop the PostgreSQL service.
Log in as the postgres user.
Check clusters (notice the —check argument, this will not change any data).
Migrate the data (without the —check argument).
Go back to the regular user.
Swap the ports for the old and new PostgreSQL versions.
Start the PostgreSQL service.
Log in as the postgres user again.
Check the new PostgreSQL version.
Run the recommended vacuumdb command:
Back to normal user.
Check which old PostgreSQL packages are installed.
Remove the old PostgreSQL packages (from the listing above).
Remove the old configuration.
Log in as the postgres user once more.
Finally, drop the old cluster data.
PS: If you want to upgrade to PostgreSQL 14, please check out the older tutorial, there are some important changes in the process. But if you want to upgrade to the older PostgreSQL 13, 12 or 11, this tutorial works perfectly well.
Juraj Kostolanský
I’m a software engineer from Slovakia working (mostly) as a full-stack Ruby on Rails web developer, or making my own side projects.
Let's stay in touch
Do you like what you read? Subscribe to get my content on web development, programming, system administration, side projects and more. No spam, unsubscribe at any time.