При желании, переместите старый кластер

Если вы используете каталог установки для конкретной версии, например, /opt/PostgreSQL/16, вам не нужно перемещать старый кластер. Все графические инсталляторы используют каталоги установки для конкретной версии.

Если ваш каталог установки не зависит от версии, например, /usr/local/pgsql, необходимо переместить текущий каталог установки PostgreSQL, чтобы он не мешал новой установке Tantor BE. После остановки текущего сервера Tantor BE можно безопасно переименовать каталог установки PostgreSQL. При условии, что старый каталог - /usr/local/pgsql, вы можете выполнить следующее:

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

чтобы переименовать каталог.

Для установки из исходного кода соберите новую версию.

Соберите новый исходный код PostgreSQL с флагами configure, совместимыми со старым кластером. pg_upgrade будет проводить проверку pg_controldata, чтобы убедиться, что все настройки совместимы перед началом обновления.

Установите новые бинарные файлы PostgreSQL

Установите бинарные файлы и файлы поддержки нового сервера. pg_upgrade включен в стандартную установку.

При установке из исходного кода, если нужно установить новый сервер в конкретное местоположение, используйте переменную prefix:

make prefix=/usr/local/pgsql.new install

Запуск нового кластера PostgreSQL

Запустите новый кластер, используя команду initdb. Также используйте совместимые флаги initdb, соответствующие старому кластеру. Многие предустановленные инсталляторы выполняют этот шаг автоматически. Нет необходимости запускать новый кластер.

Установка расширения файлов shared object

Многие расширения и пользовательские модули, будь то из contrib или другого источника, используют общие объектные файлы (или DLL-библиотеки), например, pgcrypto.so. Если в старом кластере они использовались, то в новом кластере должны быть установлены общие объектные файлы, соответствующие новому серверному бинарному файлу, обычно с помощью операционной системы команд. Не загружайте определения схемы, например, CREATE EXTENSION pgcrypto, потому что они будут дублироваться из старого кластера. Если доступны обновления расширений, pg_upgrade сообщит об этом и создаст скрипт, который можно будет запустить позже для их обновления.

Скопируйте пользовательские файлы полнотекстового поиска.

Скопируйте все пользовательские файлы полнотекстового поиска (словарь, синонимы, тезаурус, стоп-слова) из старого кластера в новый.

Настройка аутентификации

pg_upgrade будет несколько раз подключаться к старому и новому серверам, поэтому вы можете захотеть установить аутентификацию в peer в файле pg_hba.conf или использовать файл ~/.pgpass (см. Раздел 31.16).

Остановите оба сервера

Убедитесь, что оба сервера баз данных остановлены, используя, например, на Unix:

pg_ctl -D /opt/PostgreSQL/12 stop
pg_ctl -D /opt/PostgreSQL/16 stop

или в Windows, используя соответствующие имена служб:

NET STOP postgresql-12
NET STOP postgresql-16

Серверы репликации потоков и резервные серверы с доставкой журналов должны работать во время этого завершения, чтобы они получили все изменения.

Подготовка к обновлению резервного сервера

Если вы обновляете резервные серверы, используя методы, описанные в разделе Step 11, убедитесь, что старые резервные серверы синхронизированы, запустив pg_controldata на старых основных и резервных кластерах. Убедитесь, что значения “Последнее местоположение контрольной точки” совпадают во всех кластерах. Также убедитесь, что wal_level не установлен в minimal в файле postgresql.conf на новом основном кластере.

Запустите pg_upgrade

Следует всегда запускать бинарный файл pg_upgrade нового сервера, а не старого. pg_upgrade требует указания каталогов данных и исполняемых файлов (bin) старого и нового кластеров. Также можно указать значения пользователя и порта, а также выбрать, хотите ли вы, чтобы файлы данных были связаны или клонированы, вместо стандартного копирования.

Если вы используете режим ссылки, обновление будет происходить намного быстрее (без копирования файлов) и занимать меньше дискового пространства, но после запуска нового кластера вы не сможете получить доступ к старому кластеру. Режим ссылки также требует, чтобы старый и новый каталоги данных кластера находились в одной файловой системе. (табличные пространства и pg_wal могут находиться в разных файловых системах). Режим клонирования обеспечивает те же преимущества скорости и экономии дискового пространства, но не делает старый кластер непригодным для использования после запуска нового кластера. Режим клонирования также требует, чтобы старые и новые каталоги данных находились в одной файловой системе. Этот режим доступен только на определенных операционных системах и файловых системах.

Опция --jobs позволяет использовать несколько ядер ЦП для копирования/связывания файлов и для параллельного выгрузки и восстановления схем баз данных; хорошим местом для начала является максимальное количество ядер ЦП и табличных пространств. Эта опция может значительно сократить время обновления многодатабазного сервера, работающего на многопроцессорной машине.

Для пользователей Windows необходимо войти в учетную запись с административными правами, а затем запустить оболочку от имени пользователя postgres и установить правильный путь:

RUNAS /USER:postgres "CMD.EXE"
SET PATH=%PATH%;C:\Program Files\PostgreSQL\16\bin;

а затем запустите pg_upgrade с указанием каталогов в кавычках, например:

pg_upgrade.exe
        --old-datadir "C:/Program Files/PostgreSQL/12/data"
        --new-datadir "C:/Program Files/PostgreSQL/16/data"
        --old-bindir "C:/Program Files/PostgreSQL/12/bin"
        --new-bindir "C:/Program Files/PostgreSQL/16/bin"

После запуска pg_upgrade будет проверять совместимость двух кластеров и затем выполнять обновление. Вы можете использовать pg_upgrade --check для выполнения только проверок, даже если старый сервер все еще работает. pg_upgrade --check также покажет любые ручные настройки, которые вам нужно будет сделать после обновления. Если вы собираетесь использовать режим ссылки или клонирования, вы должны использовать опцию --link или --clone с --check, чтобы включить режим-специфичные проверки. pg_upgrade требует разрешения на запись в текущем каталоге.

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

Если произошла ошибка при восстановлении схемы базы данных, pg_upgrade завершится и вам придется вернуться к старому кластеру, как описано в разделе Step 17 ниже. Чтобы повторить попытку выполнения pg_upgrade, вам потребуется изменить старый кластер так, чтобы восстановление схемы pg_upgrade прошло успешно. Если проблема связана с модулем contrib, вам может потребоваться удалить модуль contrib из старого кластера и установить его в новый кластер после обновления, предполагая, что модуль не используется для хранения пользовательских данных.

Обновление потоковой репликации и резервных серверов с доставкой журналов

Если вы использовали режим ссылки и у вас есть серверы репликации в режиме потоковой передачи (см. Раздел 25.2.5) или серверы резервного копирования журнала (см. Раздел 25.2), вы можете выполнить следующие шаги для быстрого их обновления. Вы не будете запускать pg_upgrade на серверах репликации, а вместо этого будете использовать rsync на основном сервере. Пока не запускайте ни одного сервера.

Если вы не использовали режим ссылки, не имеете или не хотите использовать rsync или хотите более простое решение, пропустите инструкции в этом разделе и просто пересоздайте резервные серверы после завершения pg_upgrade и запуска нового основного сервера.

Восстановить pg_hba.conf

Если вы изменили pg_hba.conf, восстановите его исходные настройки. Также может потребоваться настроить другие файлы конфигурации в новом кластере, чтобы они соответствовали старому кластеру, например, postgresql.conf (и любые файлы, включенные им), postgresql.auto.conf.

Начать новый сервер

Теперь новый сервер можно запустить безопасно, а затем любые резервные серверы, синхронизированные с помощью rsync, могут быть запущены.

Пост-обновление обработки

Если требуется какая-либо обработка после обновления, pg_upgrade выдаст предупреждения по мере завершения процесса. Он также сгенерирует файлы сценариев, которые должен выполнить администратор. Файлы сценариев будут подключаться к каждой базе данных, которая требует обработки после обновления. Каждый сценарий должен быть выполнен с помощью команды:

psql --username=postgres --file=script.sql postgres

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

Статистика

Поскольку статистика оптимизатора не передается с помощью команды pg_upgrade, вам будет предложено выполнить команду для восстановления этой информации в конце обновления. Возможно, вам потребуется установить параметры подключения, чтобы соответствовать вашему новому кластеру.

Удаление старого кластера

После того, как вы удовлетворены обновлением, вы можете удалить каталоги данных старого кластера, запустив скрипт, упомянутый при завершении pg_upgrade. (Автоматическое удаление невозможно, если у вас есть пользовательские таблицы внутри старого каталога данных). Также можно удалить старые каталоги установки (например, bin, share).

Возвращение к старому кластеру

Если после запуска команды pg_upgrade нужно вернуться к старому кластеру, есть несколько вариантов: