Перейти к основному содержимому

Обновление кластера PostgreSQL

примечание

Эта страница переведена при помощи нейросети GigaChat.

В данном разделе рассматривается процесс обновления данных базы данных с одной версии PostgreSQL до более новой.

Текущие номера версий PostgreSQL состоят из основной и второстепенной версии. Например, в номере версии 10.1 цифра 10 является основным номером версии, а 1 - второстепенным номером версии, что означает, что это будет первым второстепенным выпуском основного выпуска 10. Для выпусков до версии PostgreSQL 10.0 номера версий состоят из трех чисел, например, 9.5.3. В этих случаях основная версия состоит из первых двух групп цифр номера версии, например, 9.5, а второстепенная версия - это третье число, например, 3, что означает, что это будет третьим второстепенным выпуском основной версии 9.5.

Второстепенные выпуски никогда не изменяют внутренний формат хранения и всегда совместимы с предыдущими и последующими второстепенными выпусками той же основной версии. Например, версия 10.1 совместима с версией 10.0 и версией 10.6. Аналогично, например, 9.5.3 совместим с 9.5.0, 9.5.1 и 9.5.6. Чтобы обновить совместимые версии, достаточно заменить исполняемые файлы при выключенном сервере и перезапустить сервер. Каталог данных остается неизменным - второстепенные обновления настолько просты.

Для основных выпусков PostgreSQL внутренний формат хранения данных может изменяться, что усложняет обновления. Традиционный метод переноса данных на новую основную версию заключается в выгрузке и восстановлении базы данных, хотя это может быть медленно. Более быстрый способ – использование утилиты pg_upgrade. Также доступны методы репликации, о чем пойдет речь ниже. (Если используется предварительно упакованная версия PostgreSQL, она может предоставлять сценарии для помощи при обновлении основной версии. Подробности можно найти в документации уровня пакета.)

Новые основные версии также обычно вводят некоторые несовместимости, видимые пользователю, поэтому могут потребоваться изменения в программировании приложений. Все видимые пользователем изменения перечислены в примечаниях к выпуску (Приложение E); особое внимание следует обратить на раздел с пометкой \«Миграция\». Хотя можно обновить одну основную версию до другой без обновления промежуточных версий, рекомендуется прочитать важные примечания ко всем промежуточным версиям.

Осторожные пользователи захотят протестировать свои клиентские приложения на новой версии, прежде чем полностью перейти на нее; поэтому часто хорошей идеей является установка параллельных установок старых и новых версий. При тестировании основного обновления PostgreSQL следует учитывать следующие категории возможных изменений.

Администрирование

: Возможности, доступные администраторам для мониторинга и управления сервером, часто изменяются и улучшаются в каждом крупном выпуске.

SQL

: Обычно это включает новые возможности команд SQL и не изменения поведения, если явно указано в примечаниях к выпуску.

Библиотека API

: Как правило, библиотеки, такие как libpq, добавляют только новую функциональность, опять же, если об этом упоминается в примечаниях к выпуску.

Системные каталоги

: Изменения системного каталога обычно влияют только на инструменты управления базами данных.

Серверный API на языке C

: Это включает изменения в API функций бэкенда, которые написаны на языке программирования C. Такие изменения затрагивают код, который ссылается на функции бэкенда глубоко внутри сервера.

Обновление данных через pg_dumpall​

Один из методов обновления заключается в том, чтобы выгрузить данные из одной основной версии PostgreSQL и восстановить их в другой. Для этого необходимо использовать инструмент логического резервного копирования, такой как логический pg_dumpall; методы резервного копирования на уровне файловой системы не будут работать. (Существуют проверки, которые предотвращают использование каталога данных с несовместимой версией PostgreSQL, поэтому большой вред от попытки запуска неправильной версии сервера на каталоге данных не будет.)

Рекомендуется использовать программы pg_dump и pg_dumpall из новой версии PostgreSQL, чтобы воспользоваться улучшениями, которые могли быть внесены в эти программы. Текущие выпуски программ дампа могут считывать данные с любого сервера, начиная с версии 9.2.

Эти инструкции предполагают, что существующая установка находится в каталоге /usr/local/pgsql, а область данных - в /usr/local/pgsql/data. Подставьте свои пути соответствующим образом.

  1. Если создается резервная копия, необходимо убедиться, что база данных не обновляется. Это не влияет на целостность резервной копии, но измененные данные, конечно же, включены не будут. При необходимости отредактируйте разрешения в файле /usr/local/pgsql/data/pg_hba.conf (или эквивалентном), чтобы запретить доступ всем, кроме администратора СУБД. См. раздел «Аутентификация клиентского приложения» для получения дополнительной информации о контроле доступа.

    Чтобы создать резервную копию установки базы данных, введите:

    pg_dumpall > outputfile

    Чтобы создать резервную копию, используйте команду pg_dumpall из текущей версии. Однако для достижения наилучших результатов рекомендуется использовать команду pg_dumpall из PostgreSQL 15.5, так как эта версия содержит исправления ошибок и улучшения по сравнению со старыми версиями. Хотя этот совет может показаться странным, поскольку новая версия еще не установлена, рекомендуется следовать ему, если планируется установить новую версию параллельно со старой версией. В этом случае можно будет завершить установку нормально и перенести данные позже. Это также сократит время простоя.

  2. Выключите старый сервер:

    pg_ctl stop

    На системах, где PostgreSQL запускается при загрузке, вероятно, существует файл запуска, который выполнит ту же задачу. Например, на системе Red Hat Linux можно обнаружить, что это работает:

  3. /etc/rc.d/init.d/postgresql stop

    См. раздел «Настройка и эксплуатация сервера» для получения подробной информации о запуске и остановке сервера.

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

    mv /usr/local/pgsql /usr/local/pgsql.old

    (Убедитесь, что перемещаете каталог как единое целое, чтобы относительные пути остались неизменными.)

  5. Установите новую версию PostgreSQL, как описано в разделе Процедура установки.

  6. Создайте новый кластер баз данных при необходимости. Помните, что эти команды должны быть выполнены от имени специальной учетной записи пользователя базы данных (которая уже существует, если выполняется обновление).

    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

  7. Восстановите предыдущие настройки pg_hba.conf и любые изменения в postgresql.conf.

  8. Запустите сервер базы данных снова, используя специальную учетную запись пользователя базы данных:

    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

  9. Восстановите данные из резервной копии:

    /usr/local/pgsql/bin/psql -d postgres -f outputfile

    используя новую версию psql.

Минимального времени простоя можно достичь путем установки нового сервера в другом каталоге и запуска старого и нового серверов параллельно на разных портах. Затем можно использовать:

pg_dumpall -p 5432 | psql -d postgres -p 5433

для передачи данных.

Обновление данных через pg_upgrade​

Модуль pg_upgrade позволяет выполнять миграцию установки непосредственно с одной основной версии PostgreSQL на другую. Обновления могут быть выполнены за считанные минуты, особенно в режиме --link. Для этого требуются шаги, аналогичные шагам pg_dumpall, описанным выше, например, запуск/остановка сервера, выполнение команды initdb. В документации к pg_upgrade описаны необходимые шаги.

Обновление данных с помощью репликации​

Возможно использовать методы логической репликации для создания резервного сервера с обновленной версией PostgreSQL. Это возможно, поскольку логическая репликация поддерживает репликацию между разными основными версиями PostgreSQL. Резервный сервер может находиться на том же компьютере или на другом компьютере. После синхронизации с основным сервером (на котором работает более старая версия PostgreSQL) можно переключить основные серверы и сделать резервный сервер основным, а старую базу данных отключить. Такое переключение приводит к простою всего в несколько секунд при обновлении.

Этот метод обновления можно выполнить с использованием встроенных средств логической репликации, а также с использованием внешних систем логической репликации, таких как pglogical, Slony, Londiste и Bucardo.