Компания Postgres Professional

pg_upgrade
Пред.	Наверх	Серверные приложения PostgreSQL	Начало	След.

pg_upgrade

pg_upgrade — обновить экземпляр сервера PostgreSQL

Синтаксис

pg_upgrade -b старый_каталог_bin [-B новый_каталог_bin] -d старый_каталог_конфигурации -D новый_каталог_конфигурации [параметр...]

Описание

Программа pg_upgrade (ранее называвшаяся pg_migrator) позволяет обновить данные в каталоге базы данных PostgreSQL до последней основной версии PostgreSQL без операции выгрузки/восстановления данных, обычно необходимой при обновлениях основной версии, например, при переходе от 12.14 к 13.10 или от 14.9 к 15.5. Эти действия не требуются при установке корректирующей версии, например, при переходе от 12.7 к 12.8 или от 14.1 к 14.5.

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

Программа pg_upgrade делает всё возможное, чтобы убедиться в том, что старый и новый кластеры двоично-совместимы, в частности проверяя параметры времени компиляции и разрядность (32/64 бита) исполняемых файлов. Важно, чтобы и все внешние модули тоже были двоично-совместимыми, хотя это pg_upgrade проверить не может.

pg_upgrade поддерживает обновление с версии 9.2.X и новее до текущей основной версии PostgreSQL, включая бета-выпуски и сборки снимков кода.

Предупреждение

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

Параметры

pg_upgrade принимает следующие аргументы командной строки:

-b каталог_bin --old-bindir=каталог_bin

каталог с исполняемыми файлами старой версии PostgreSQL; переменная окружения PGBINOLD

-B каталог_bin --new-bindir=каталог_bin

каталог с исполняемыми файлами новой версии PostgreSQL, по умолчанию это каталог, в котором располагается pg_upgrade; переменная окружения PGBINNEW

-c --check

только проверить кластеры, не изменять никакие данные

-d каталог_конфигурации --old-datadir=каталог_конфигурации

каталог конфигурации старого кластера; переменная окружения PGDATAOLD

-D каталог_конфигурации --new-datadir=каталог_конфигурации

каталог конфигурации нового кластера; переменная окружения PGDATANEW

-j число_заданий --jobs=число_заданий

число одновременно задействуемых подключений и процессов/потоков

-k --link

использовать жёсткие ссылки вместо копирования файлов в новый кластер

-N --no-sync

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

-o параметры --old-options параметры

параметры, передаваемые непосредственно старой программе postgres; несколько параметров складываются вместе

-O параметры --new-options параметры

параметры, передаваемые непосредственно новой программе postgres; несколько параметров складываются вместе

-p порт --old-port=порт

номер порта старого кластера; переменная окружения PGPORTOLD

-P порт --new-port=порт

номер порта нового кластера; переменная окружения PGPORTNEW

-r --retain

сохранить SQL и журналы сообщений даже при успешном завершении

-s каталог --socketdir=каталог

каталог, в котором будет создавать сокеты процесс postmaster во время обновления; по умолчанию выбирается текущий рабочий каталог; переменная окружения PGSOCKETDIR

-U имя_пользователя --username=имя_пользователя

имя пользователя, установившего кластер; переменная окружения PGUSER

-v --verbose

включить подробные внутренние сообщения

-V --version

показать версию, а затем завершиться

--clone

Использовать эффективное клонирование файлов (в ряде систем это называется «reflink») вместо копирования файлов в новый кластер. В результате файлы данных могут копироваться практически мгновенно, как и с использованием -k/--link, но последующие изменения не будут затрагивать старый кластер.

Клонирование файлов поддерживается не во всех операционных системах и только с определёнными файловыми системами. Если этот режим выбран, но клонирование не поддерживается, при выполнении pg_upgrade произойдёт ошибка. В настоящее время оно поддерживается в Linux (с ядром 4.5 или новее) с Btrfs и XFS (если файловая система была создана с поддержкой reflink), а также в macOS с APFS.

--copy

Копировать файлы в новый кластер. Это поведение по умолчанию. (См. также --link, --clone, --copy-file-range и --swap.)

--copy-file-range

Использовать системный вызов copy_file_range для эффективного копирования. В некоторых файловых системах результаты будут схожи с --clone, позволяя совместное использование физических дисковых блоков, в то время как на других могут копироваться блоки, но по оптимизированному пути. В настоящее время параметр поддерживается в Linux и FreeBSD.

--no-statistics

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

--set-char-signedness=параметр

Вручную задать наличие знака у типа данных char по умолчанию в новых кластерах. Возможные значения: signed (со знаком) и unsigned (без знака).

В языке C наличие знака у типа char по умолчанию различается между платформами, если это не указано явно. Например, на процессорах x86 для char по умолчанию становится signed char, но на процессорах ARM используется unsigned char .

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

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

Если после обновления вы планируете переходить на другую платформу, не используйте этот параметр. В этом случае поведение по умолчанию будет правильным. Вместо этого обновите исходную платформу без этого ключа, а затем перенесите кластер. Это рекомендуемый и самый безопасный подход.
Если вы уже перенесли кластер на платформу с другой знаковостью у типа char (например, с системы на базе x86 на систему на базе ARM), вам нужно использовать этот параметр, чтобы указать знаковость типа char, использующуюся по умолчанию на исходной платформе. Кроме того, важно не изменять никакие файлы данных между переносом файлов и запуском pg_upgrade. Команда pg_upgrade должна быть первой операцией, которая запускает кластер на новой платформе.

--swap

Перемещать каталоги данных из старого кластера в новый кластер. Затем заменять файлы каталога файлами, сгенерированными для нового кластера. Этот режим будет работать лучше --link, --clone, --copy и --copy-file-range, особенно в кластерах с большим количеством отношений.

Однако этот режим создаёт много файлов мусора в старом кластере, что может удлинить шаг синхронизации файлов, если используется параметр --sync-method=syncfs. Таким образом, рекомендуется использовать параметр --sync-method=fsync с --swap.

Кроме того, как только начнётся шаг передачи файлов, старый кластер будет деструктивно изменён, и следовательно, его запуск станет небезопасным. За подробностями обратитесь к Шаг 17.

--sync-method=метод

Со значением fsync (по умолчанию) pg_upgrade рекурсивно откроет и синхронизирует все файлы в каталоге данных обновлённого кластера. Поиск файлов будет осуществляться по символическим ссылкам для каталога WAL и каждого настроенного табличного пространства.

В Linux возможен вариант syncfs, когда от ОС требуется синхронизировать целиком каждую из файловых систем, содержащих каталог данных обновлённого кластера, файлы WAL и табличные пространства. Более подробно особенности использования syncfs описаны в recovery_init_sync_method.

В режиме --no-sync этот параметр не оказывает никакого влияния.

-? --help

показать справку, а затем завершиться

Использование

Далее описан план обновления с использованием pg_upgrade:

Примечание

Здесь не рассматриваются шаги обновления кластеров логической репликации. За подробностями обратитесь к Разделу 29.13.

Переместить старый кластер (необязательно)
Если ваш каталог инсталляции привязан к версии, например, /opt/PostgreSQL/18, перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.
Если ваш каталог инсталляции не привязан к версии, например /usr/local/pgsql, необходимо переместить каталог текущей инсталляции PostgreSQL, чтобы он не конфликтовал с новой инсталляцией PostgreSQL. Когда текущий сервер PostgreSQL отключён, каталог этой инсталляции 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, совместимые с флагами в старом кластере. Многие готовые инсталляторы выполняют это действие автоматически. Запускать новый кластер не требуется.
Установить разделяемые объектные файлы расширения
Многие расширения и пользовательские модули, как из contrib, так и из других источников, используют разделяемые объектные файлы (или библиотеки DLL), например, pgcrypto.so. Если они использовались в старом кластере, разделяемые объектные файлы, соответствующие новому исполняемому файлу сервера, должны быть установлены в новом кластере, обычно средствами операционной системы. Не загружайте определения схемы, например, выполняя CREATE EXTENSION pgcrypto, потому что они будут скопированы из старого кластера. Если доступны обновления расширений, pg_upgrade сообщит об этом и создаст скрипт, который можно будет запустить позже, чтобы обновить эти расширения.
Скопировать пользовательские файлы полнотекстового поиска
Скопировать пользовательские файлы полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов) из старого кластера в новый.
Настроить аутентификацию
Программа pg_upgrade будет подключаться к новому и старому серверу несколько раз, так что имеет смысл установить режим аутентификации peer в pg_hba.conf или использовать файл ~/.pgpass (см. Раздел 32.16).
Остановить оба сервера
Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:
```
pg_ctl -D /opt/PostgreSQL/12 stop
pg_ctl -D /opt/PostgreSQL/18 stop
```
А в Windows, с соответствующими именами служб:
```
NET STOP postgresql-12
NET STOP postgresql-18
```
Ведомые серверы с потоковой репликацией и трансляцией журнала должны продолжать работать во время этого отключения, чтобы получить все изменения.
Подготовиться к обновлению ведомых серверов
Если вы производите обновление ведомых серверов (как описано в разделе Шаг 11), удостоверьтесь, что эти серверы находятся в актуальном состоянии, запустив pg_controldata в старых ведущем и ведомых кластерах. Убедитесь в том, что «Положение последней контрольной точки» во всех кластерах одинаковое. Также смените wal_level на replica в файле postgresql.conf нового ведущего кластера.
Запустить pg_upgrade
Всегда запускайте программу pg_upgrade от нового сервера, а не от старого. pg_upgrade требует указания каталогов данных старого и нового кластера, а также каталогов исполняемых файлов (bin). Вы можете также определить имя пользователя и номера портов, и нужно ли копировать файлы данных (по умолчанию), клонировать их, создавать ссылки на них или перенести их.
Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_wal могут находиться в других файловых системах.) Вариант с клонированием работает так же быстро и экономит место на диске, но позволяет сохранить рабочее состояние старого кластера при запуске нового. Для этого варианта тоже требуется, чтобы старый и новый каталоги данных находились в одной файловой системе. Клонирование возможно только в некоторых операционных системах с определёнными файловыми системами. Вариант с переносом может быть самым быстрым, если в кластере много отношений, но вы лишитесь возможности обращаться к вашему старому кластеру, как только начнётся шаг передачи файлов. Для этого варианта также требуется, чтобы каталоги данных старого и нового кластеров находились в одной файловой системе.
Установка параметра --jobs в значение 2 или выше позволяет pg_upgrade обрабатывать параллельно несколько баз данных и табличных пространств. Хорошим начальным значением будет количество процессорных ядер на компьютере. Этот параметр может существенно сократить время обновления сервера с несколькими базами данных или несколькими табличными пространствами.
В Windows вы должны войти в систему с административными полномочиями и затем запустить pg_upgrade с путями каталогов в кавычках, например, так:
```
pg_upgrade.exe
        --old-datadir "C:/Program Files/PostgreSQL/12/data"
        --new-datadir "C:/Program Files/PostgreSQL/18/data"
        --old-bindir "C:/Program Files/PostgreSQL/12/bin"
        --new-bindir "C:/Program Files/PostgreSQL/18/bin"
```
При запуске pg_upgrade проверит два кластера на совместимость и, если всё в порядке, выполнит обновление. Также возможно запустить pg_upgrade --check, чтобы ограничиться только проверками (при этом старый сервер может продолжать работать). Команда pg_upgrade --check также сообщит, какие коррективы вам нужно будет внести вручную после обновления. Если вы планируете использовать режим ссылок, клонирования, копирования блоков или переноса, укажите вместе с параметром --check параметр --link, --clone, --copy-file-range или --swap, чтобы включить специальные проверки для этих режимов. Программе pg_upgrade требуются права на запись в текущий каталог.
Очевидно, никто не должен обращаться к кластерам в процессе обновления. Программа pg_upgrade по умолчанию запускает серверы с портом 50432, чтобы не допустить нежелательных клиентских подключений. В процессе обновления оба кластера могут использовать один номер порта, так как они не будут работать одновременно. Однако для проверки старого работающего сервера новый порт должен отличаться от старого.
Если при восстановлении схемы базы данных происходит ошибка, pg_upgrade завершает свою работу и вы должны вернуться к старому кластеру, как описывается ниже в Шаг 17. Чтобы попробовать pg_upgrade ещё раз, вы должны внести коррективы в старом кластере, чтобы pg_upgrade могла успешно восстановить схему. Если проблема возникла в модуле contrib, может потребоваться удалить этот модуль contrib в старом кластере, а затем установить его в новом после обновления (предполагается, что этот модуль не хранит пользовательские данные).
Обновить ведомые серверы с потоковой репликацией и трансляцией журнала
Если вы используете режим ссылок и у вас реализована потоковая репликация (см. Подраздел 26.2.5) или трансляция журнала (см. Раздел 26.2) для ведомых серверов, вы можете быстро обновить эти серверы следующим образом. Вам не нужно будет запускать на них pg_upgrade, вместо этого вы выполните rsync на ведущем. Не запускайте никакие серверы на этом этапе.
Если вы не используете режим ссылок, либо у вас нет rsync или вы не хотите его использовать, либо если вам нужен более простой вариант, пропустите инструкции в этом разделе и просто пересоздайте ведомые серверы сразу после завершения pg_upgrade и запуска нового ведущего сервера.
1. Установите новые исполняемые файлы PostgreSQL на ведомых серверах
  Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.
2. Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют
  Новые каталоги данных ведомых серверов должны отсутствовать либо быть пустыми. Если запускалась программа initdb, удалите новые каталоги данных на ведомых.
3. Установить разделяемые объектные файлы расширения
  Установите на новых ведомых серверах те же разделяемые объектные файлы расширения, что вы установили в новом ведущем кластере.
4. Остановите ведомые серверы
  Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.
5. Сохраните файлы конфигурации
  Сохраните все нужные вам файлы конфигурации из старых каталогов конфигурации ведомых серверов, в частности postgresql.conf (и все файлы, включённые в него), postgresql.auto.conf и pg_hba.conf, так как они будут перезаписаны или удалены на следующем этапе.
6. Запустите rsync
  Когда используется режим ссылок, ведомые серверы можно быстро обновить, применив rsync. Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем:
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
```
  Здесь каталоги old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится над каталогами старого и нового кластера на ведомом. Структура подкаталогов в заданных каталогах на ведущем и ведомых серверах должна быть одинаковой. Обратитесь к странице руководства rsync, где подробно описано, как указать удалённый каталог, например так:
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/12 \
      /opt/PostgreSQL/18 standby.example.com:/opt/PostgreSQL
```
  Проверить, что будет делать команда, можно, воспользовавшись параметром rsync --dry-run. Выполнить rsync на ведущем необходимо как минимум с одним ведомым, но затем, пока обновлённый ведомый остаётся остановленным, можно запускать rsync на нём для обновления других ведомых.
  В ходе этой операции записываются ссылки, созданные режимом ссылок pg_upgrade, связывающие файлы нового и старого кластера на ведущем сервере. Затем в старом кластере ведомого находятся соответствующие файлы и в новом кластере ведомого создаются ссылки на них. Файлы, не связанные ссылками на ведущем, копируются с него на ведомый. (Обычно их объём невелик.) Это позволяет произвести обновление ведомого быстро. К сожалению, при этом rsync будет напрасно копировать файлы, связанные с временными и нежурналируемыми таблицами, так как они обычно не будут существовать на ведомых серверах.
  Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_12_201909212 \
      /vol1/pg_tblsp/PG_18_202307071 standby.example.com:/vol1/pg_tblsp
```
  Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.
7. Настройте ведомые серверы с потоковой репликацией и трансляцией журнала
  Настройте серверы для трансляции журнала. (Запускать pg_backup_start() и pg_backup_stop() или делать копию файловой системы не нужно, так как ведомые серверы остаются синхронизированными с ведущим.) Если версия старого ведущего ниже 17.0, слоты не будут копироваться на новый ведомый, и все слоты нужно будет воссоздавать вручную. Если старый ведущий сервер версии 17.0 или выше, логические слоты на ведущем сервере будут скопированы на новый ведомый сервер, но слоты на старом ведомом сервере копироваться не будут, и их нужно будет воссоздавать вручную.
Восстановить pg_hba.conf
Если вы изменяли pg_hba.conf, восстановите его исходное состояние. Также может потребоваться скорректировать другие файлы конфигурации в новом кластере, чтобы они соответствовали старому, например, postgresql.conf (и файлы, включённые в него) и postgresql.auto.conf.
Запустить новый сервер
Теперь можно безопасно запустить новый сервер, а затем ведомые серверы, синхронизированные с ним с помощью rsync.
Действия после обновления
Если после обновления требуются какие-то дополнительные действия, программа pg_upgrade выдаст предупреждения об этом по завершении работы. Она также сгенерирует файлы скриптов, которые должны запускаться администратором. Эти скрипты будут подключаться к каждой базе данных, требующей дополнительных операций. Каждый такой скрипт следует выполнять командой:
```
psql --username=postgres --file=script.sql postgres
```
Эти скрипты могут выполняться в любом порядке, а после выполнения их можно удалить.
Внимание
Обычно к таблицам, задействованным в перестраивающих базу скриптах, опасно обращаться, пока эти скрипты не сделают свою работу; при этом можно получить некорректный результат или плохую производительность. К таблицам, не задействованным в таких скриптах, можно обращаться немедленно.
Статистика
Если не указан параметр --no-statistics, pg_upgrade будет переносить большую часть статистики оптимизатора из старого кластера в новый. Не переносится статистика, созданная явно с помощью CREATE STATISTICS, пользовательская статистика, добавленная расширением, и статистика, полученная из системы накопительной статистики.
Так как не вся статистика оптимизатора передаётся в процессе работы pg_upgrade, вы получите указание запустить соответствующие команды для воссоздания этой информации после обновления. Возможно, для этого вам понадобится установить параметры подключения к новому кластеру.
Прежде всего используйте команду vacuumdb --all --analyze-in-stages --missing-stats-only для быстрой генерации минимальной статистики оптимизатора для отношений, у которых её нет. Затем используйте vacuumdb --all --analyze-only, чтобы гарантированно обновить сводную статистику всех отношений для запущенных очистки и анализа. Для обеих команд используйте параметр --jobs, чтобы ускорить процесс. Если значение vacuum_cost_delay не равно нулю, его можно переопределить, чтобы ускорить генерацию статистики с помощью PGOPTIONS, например PGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ....
Удалить старый кластер
Если вы удовлетворены результатами обновления, вы можете удалить каталоги данных старого кластера, запустив скрипт, упомянутый в выводе pg_upgrade после обновления. (Автоматическое удаление невозможно, если в старом каталоге данных находятся дополнительные табличные пространства.) Также вы можете удалить каталоги старой инсталляции (например, bin, share).
Возврат к старому кластеру
Если выполнив команду pg_upgrade, вы захотите вернуться к старому кластеру, возможны следующие варианты:
- Если использовался ключ --check, в старом кластере ничего не меняется; его можно просто перезапустить.
- Если не использовался ни ключ --link, ни ключ --swap, в старом кластере ничего не меняется; его можно просто перезапустить.
- Если использовался ключ --link, у старого и нового кластера могут оказаться общие файлы данных:
  - Если работа pg_upgrade была прервана до начала расстановки ссылок, в старом кластере ничего не меняется; его можно просто перезапустить.
  - Если вы не запускали новый кластер, старый кластер не претерпел никаких изменений, за исключением того, что при создании ссылки на данные к имени $PGDATA/global/pg_control было добавлено окончание .old. Чтобы продолжить использование старого кластера, достаточно убрать окончание .old из имени файла $PGDATA/global/pg_control; после этого старый кластер можно будет перезапустить.
  - Если вы запускали новый кластер, он внёс изменения в общие файлы, и использовать старый кластер небезопасно. В этом случае старый кластер нужно будет восстановить из резервной копии.
- Если использовался параметр --swap, старый кластер может быть деструктивно изменён:
  - Если работа pg_upgrade прерывается до сообщения о том, что запускать старый кластер больше небезопасно, в старом кластере ничего не меняется; его можно просто перезапустить.
  - Если команда pg_upgrade сообщила о том, что запускать старый кластер больше небезопасно, старый кластер был деструктивно изменён. В этом случае старый кластер нужно будет восстановить из резервной копии.

Переменные окружения

Некоторые переменные окружения могут передавать значения по умолчанию для параметров командной строки:

PGBINOLD: Каталог с исполняемыми файлами старой версии PostgreSQL; параметр -b/--old-bindir.
PGBINNEW: Каталог с исполняемыми файлами новой версии PostgreSQL; параметр -B/--new-bindir.
PGDATAOLD: Каталог конфигурации старого кластера; параметр -d/--old-datadir.
PGDATANEW: Каталог конфигурации нового кластера; параметр -D/--new-datadir.
PGPORTOLD: Номер порта старого кластера; параметр -p/--old-port.
PGPORTNEW: Номер порта нового кластера; параметр -P/--new-port.
PGSOCKETDIR: Каталог, в котором будет создавать сокеты postmaster во время обновления; параметр -s/--socketdir.
PGUSER: Имя пользователя для установки кластера; параметр -U/--username.

Примечания

Программа pg_upgrade создаёт различные временные файлы, например выгружая схему базы, в своём рабочем каталоге pg_upgrade_output.d внутри каталога данных нового кластера. При каждом запуске в этом рабочем каталоге создаётся подкаталог с именем, содержащим отметку времени в формате стандарта ISO 8601 (%Y%m%dT%H%M%S), и в данный подкаталог помещаются все создаваемые файлы. Каталог pg_upgrade_output.d со всем содержимым удаляется автоматически в случае успешного выполнения pg_upgrade; но если возникает проблема, сохранённые в нём файлы могут быть полезны для диагностики.

Программа pg_upgrade запускает на короткое время процессы postmaster со старым и новым каталогом данных. Временные файлы сокетов Unix для взаимодействия с этими процессами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях путь к файлу в текущем каталоге может оказаться слишком длинным для имени сокета. В этом случае вы можете передать параметр -s, чтобы файлы сокетов создавались в другом каталоге с более коротким путём. В целях безопасности этот каталог не должен быть доступен для чтения и записи другим пользователям. (В Windows это не поддерживается.)

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

Для проверки развёртывания новой версии создайте копию только схемы старого кластера, наполните этот кластер фиктивными данными, и попробуйте обновить его.

pg_upgrade не поддерживает обновление баз данных, в которых есть таблицы со столбцами, имеющими следующие системные типы данных reg*, ссылающиеся на OID:

regcollation

regconfig

regdictionary

regnamespace

regoper

regoperator

regproc

regprocedure

(Обновление regclass, regrole и regtype поддерживается.)

Если вы хотите использовать режим ссылок на данные, но при этом исключить изменения в старом кластере при запуске нового, вам может подойти режим клонирования. Если же этот режим недоступен, сделайте копию старого кластера и обновите его в этом режиме. Чтобы получить рабочую копию старого кластера, воспользуйтесь командой rsync и создайте предварительную копию кластера при работающем сервере, а затем отключите старый сервер и ещё раз запустите rsync --checksum, чтобы привести эту копию в согласованное состояние. (Ключ --checksum необходим, потому что rsync различает время с точностью только до секунд.) При этом вы можете исключить некоторые файлы, например postmaster.pid, как описано в Подразделе 25.3.4. Если ваша файловая система поддерживает снимки файловой системы или копирование при записи, вы можете воспользоваться этим для создания копии старого кластера и табличных пространств; при этом важно, чтобы такие снимки и копии файлов создавались одномоментно или когда сервер баз данных отключён.

См. также

initdb, pg_ctl, pg_dump, postgres

Пред.	Наверх	След.
pg_test_timing	Начало	pg_waldump

pg_upgrade
Prev	Up	PostgreSQL Server Applications	Home	Next

pg_upgrade

pg_upgrade — upgrade a PostgreSQL server instance

Synopsis

pg_upgrade -b oldbindir [-B newbindir] -d oldconfigdir -D newconfigdir [option...]

Description

pg_upgrade (formerly called pg_migrator) allows data stored in PostgreSQL data files to be upgraded to a later PostgreSQL major version without the data dump/restore typically required for major version upgrades, e.g., from 12.14 to 13.10 or from 14.9 to 15.5. It is not required for minor version upgrades, e.g., from 12.7 to 12.8 or from 14.1 to 14.5.

Major PostgreSQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. pg_upgrade uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files. If a future major release ever changes the data storage format in a way that makes the old data format unreadable, pg_upgrade will not be usable for such upgrades. (The community will attempt to avoid such situations.)

pg_upgrade does its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, including 32/64-bit binaries. It is important that any external modules are also binary compatible, though this cannot be checked by pg_upgrade.

pg_upgrade supports upgrades from 9.2.X and later to the current major release of PostgreSQL, including snapshot and beta releases.

Warning

Upgrading a cluster causes the destination to execute arbitrary code of the source superusers' choice. Ensure that the source superusers are trusted before upgrading.

Options

pg_upgrade accepts the following command-line arguments:

-b bindir --old-bindir=bindir

the old PostgreSQL executable directory; environment variable PGBINOLD

-B bindir --new-bindir=bindir

the new PostgreSQL executable directory; default is the directory where pg_upgrade resides; environment variable PGBINNEW

-c --check

check clusters only, don't change any data

-d configdir --old-datadir=configdir

the old database cluster configuration directory; environment variable PGDATAOLD

-D configdir --new-datadir=configdir

the new database cluster configuration directory; environment variable PGDATANEW

-j njobs --jobs=njobs

number of simultaneous connections and processes/threads to use

-k --link

use hard links instead of copying files to the new cluster

-N --no-sync

By default, pg_upgrade will wait for all files of the upgraded cluster to be written safely to disk. This option causes pg_upgrade to return without waiting, which is faster, but means that a subsequent operating system crash can leave the data directory corrupt. Generally, this option is useful for testing but should not be used on a production installation.

-o options --old-options options

options to be passed directly to the old postgres command; multiple option invocations are appended

-O options --new-options options

options to be passed directly to the new postgres command; multiple option invocations are appended

-p port --old-port=port

the old cluster port number; environment variable PGPORTOLD

-P port --new-port=port

the new cluster port number; environment variable PGPORTNEW

-r --retain

retain SQL and log files even after successful completion

-s dir --socketdir=dir

directory to use for postmaster sockets during upgrade; default is current working directory; environment variable PGSOCKETDIR

-U username --username=username

cluster's install user name; environment variable PGUSER

-v --verbose

enable verbose internal logging

-V --version

display version information, then exit

--clone

Use efficient file cloning (also known as “reflinks” on some systems) instead of copying files to the new cluster. This can result in near-instantaneous copying of the data files, giving the speed advantages of -k/--link while leaving the old cluster untouched.

File cloning is only supported on some operating systems and file systems. If it is selected but not supported, the pg_upgrade run will error. At present, it is supported on Linux (kernel 4.5 or later) with Btrfs and XFS (on file systems created with reflink support), and on macOS with APFS.

--copy

Copy files to the new cluster. This is the default. (See also --link, --clone, --copy-file-range, and --swap.)

--copy-file-range

Use the copy_file_range system call for efficient copying. On some file systems this gives results similar to --clone, sharing physical disk blocks, while on others it may still copy blocks, but do so via an optimized path. At present, it is supported on Linux and FreeBSD.

--no-statistics

Do not restore statistics from the old cluster into the new cluster.

--set-char-signedness=option

Manually set the default char signedness of new clusters. Possible values are signed and unsigned.

In the C language, the default signedness of the char type (when not explicitly specified) varies across platforms. For example, char defaults to signed char on x86 CPUs but to unsigned char on ARM CPUs.

Starting from PostgreSQL 18, database clusters maintain their own default char signedness setting, which can be used to ensure consistent behavior across platforms with different default char signedness. By default, pg_upgrade preserves the char signedness setting when upgrading from an existing cluster. However, when upgrading from PostgreSQL 17 or earlier, pg_upgrade adopts the char signedness of the platform on which it was built.

This option allows you to explicitly set the default char signedness for the new cluster, overriding any inherited values. There are two specific scenarios where this option is relevant:

If you are planning to migrate to a different platform after the upgrade, you should not use this option. The default behavior is right in this case. Instead, perform the upgrade on the original platform without this flag, and then migrate the cluster afterward. This is the recommended and safest approach.
If you have already migrated the cluster to a platform with different char signedness (for example, from an x86-based system to an ARM-based system), you should use this option to specify the signedness matching the original platform's default char signedness. Additionally, it's essential not to modify any data files between migrating data files and running pg_upgrade. pg_upgrade should be the first operation that starts the cluster on the new platform.

--swap

Move the data directories from the old cluster to the new cluster. Then, replace the catalog files with those generated for the new cluster. This mode can outperform --link, --clone, --copy, and --copy-file-range, especially on clusters with many relations.

However, this mode creates many garbage files in the old cluster, which can prolong the file synchronization step if --sync-method=syncfs is used. Therefore, it is recommended to use --sync-method=fsync with --swap.

Additionally, once the file transfer step begins, the old cluster will be destructively modified and therefore will no longer be safe to start. See Step 17 for details.

--sync-method=method

When set to fsync, which is the default, pg_upgrade will recursively open and synchronize all files in the upgraded cluster's data directory. The search for files will follow symbolic links for the WAL directory and each configured tablespace.

On Linux, syncfs may be used instead to ask the operating system to synchronize the whole file systems that contain the upgraded cluster's data directory, its WAL files, and each tablespace. See recovery_init_sync_method for information about the caveats to be aware of when using syncfs.

This option has no effect when --no-sync is used.

-? --help

show help, then exit

Usage

These are the steps to perform an upgrade with pg_upgrade:

Note

The steps to upgrade logical replication clusters are not covered here; refer to Section 29.13 for details.

Optionally move the old cluster
If you are using a version-specific installation directory, e.g., /opt/PostgreSQL/18, you do not need to move the old cluster. The graphical installers all use version-specific installation directories.
If your installation directory is not version-specific, e.g., /usr/local/pgsql, it is necessary to move the current PostgreSQL install directory so it does not interfere with the new PostgreSQL installation. Once the current PostgreSQL server is shut down, it is safe to rename the PostgreSQL installation directory; assuming the old directory is /usr/local/pgsql, you can do:
```
mv /usr/local/pgsql /usr/local/pgsql.old
```
to rename the directory.
For source installs, build the new version
Build the new PostgreSQL source with configure flags that are compatible with the old cluster. pg_upgrade will check pg_controldata to make sure all settings are compatible before starting the upgrade.
Install the new PostgreSQL binaries
Install the new server's binaries and support files. pg_upgrade is included in a default installation.
For source installs, if you wish to install the new server in a custom location, use the prefix variable:
```
make prefix=/usr/local/pgsql.new install
```
Initialize the new PostgreSQL cluster
Initialize the new cluster using initdb. Again, use compatible initdb flags that match the old cluster. Many prebuilt installers do this step automatically. There is no need to start the new cluster.
Install extension shared object files
Many extensions and custom modules, whether from contrib or another source, use shared object files (or DLLs), e.g., pgcrypto.so. If the old cluster used these, shared object files matching the new server binary must be installed in the new cluster, usually via operating system commands. Do not load the schema definitions, e.g., CREATE EXTENSION pgcrypto, because these will be duplicated from the old cluster. If extension updates are available, pg_upgrade will report this and create a script that can be run later to update them.
Copy custom full-text search files
Copy any custom full text search files (dictionary, synonym, thesaurus, stop words) from the old to the new cluster.
Adjust authentication
pg_upgrade will connect to the old and new servers several times, so you might want to set authentication to peer in pg_hba.conf or use a ~/.pgpass file (see Section 32.16).
Stop both servers
Make sure both database servers are stopped using, on Unix, e.g.:
```
pg_ctl -D /opt/PostgreSQL/12 stop
pg_ctl -D /opt/PostgreSQL/18 stop
```
or on Windows, using the proper service names:
```
NET STOP postgresql-12
NET STOP postgresql-18
```
Streaming replication and log-shipping standby servers must be running during this shutdown so they receive all changes.
Prepare for standby server upgrades
If you are upgrading standby servers using methods outlined in section Step 11, verify that the old standby servers are caught up by running pg_controldata against the old primary and standby clusters. Verify that the “Latest checkpoint location” values match in all clusters. Also, make sure wal_level is not set to minimal in the postgresql.conf file on the new primary cluster.
Run pg_upgrade
Always run the pg_upgrade binary of the new server, not the old one. pg_upgrade requires the specification of the old and new cluster's data and executable (bin) directories. You can also specify user and port values, and whether you want the data files linked, cloned, or swapped instead of the default copy behavior.
If you use link mode, the upgrade will be much faster (no file copying) and use less disk space, but you will not be able to access your old cluster once you start the new cluster after the upgrade. Link mode also requires that the old and new cluster data directories be in the same file system. (Tablespaces and pg_wal can be on different file systems.) Clone mode provides the same speed and disk space advantages but does not cause the old cluster to be unusable once the new cluster is started. Clone mode also requires that the old and new data directories be in the same file system. This mode is only available on certain operating systems and file systems. Swap mode may be the fastest if there are many relations, but you will not be able to access your old cluster once the file transfer step begins. Swap mode also requires that the old and new cluster data directories be in the same file system.
Setting --jobs to 2 or higher allows pg_upgrade to process multiple databases and tablespaces in parallel. A good starting point is the number of CPU cores on the machine. This option can substantially reduce the upgrade time for multi-database and multi-tablespace servers.
For Windows users, you must be logged into an administrative account, and then run pg_upgrade with quoted directories, e.g.:
```
pg_upgrade.exe
        --old-datadir "C:/Program Files/PostgreSQL/12/data"
        --new-datadir "C:/Program Files/PostgreSQL/18/data"
        --old-bindir "C:/Program Files/PostgreSQL/12/bin"
        --new-bindir "C:/Program Files/PostgreSQL/18/bin"
```
Once started, pg_upgrade will verify the two clusters are compatible and then do the upgrade. You can use pg_upgrade --check to perform only the checks, even if the old server is still running. pg_upgrade --check will also outline any manual adjustments you will need to make after the upgrade. If you are going to be using link, clone, copy-file-range, or swap mode, you should use the option --link, --clone, --copy-file-range, or --swap with --check to enable mode-specific checks. pg_upgrade requires write permission in the current directory.
Obviously, no one should be accessing the clusters during the upgrade. pg_upgrade defaults to running servers on port 50432 to avoid unintended client connections. You can use the same port number for both clusters when doing an upgrade because the old and new clusters will not be running at the same time. However, when checking an old running server, the old and new port numbers must be different.
If an error occurs while restoring the database schema, pg_upgrade will exit and you will have to revert to the old cluster as outlined in Step 17 below. To try pg_upgrade again, you will need to modify the old cluster so the pg_upgrade schema restore succeeds. If the problem is a contrib module, you might need to uninstall the contrib module from the old cluster and install it in the new cluster after the upgrade, assuming the module is not being used to store user data.
Upgrade streaming replication and log-shipping standby servers
If you used link mode and have Streaming Replication (see Section 26.2.5) or Log-Shipping (see Section 26.2) standby servers, you can follow these steps to quickly upgrade them. You will not be running pg_upgrade on the standby servers, but rather rsync on the primary. Do not start any servers yet.
If you did not use link mode, do not have or do not want to use rsync, or want an easier solution, skip the instructions in this section and simply recreate the standby servers once pg_upgrade completes and the new primary is running.
1. Install the new PostgreSQL binaries on standby servers
  Make sure the new binaries and support files are installed on all standby servers.
2. Make sure the new standby data directories do not exist
  Make sure the new standby data directories do not exist or are empty. If initdb was run, delete the standby servers' new data directories.
3. Install extension shared object files
  Install the same extension shared object files on the new standbys that you installed in the new primary cluster.
4. Stop standby servers
  If the standby servers are still running, stop them now using the above instructions.
5. Save configuration files
  Save any configuration files from the old standbys' configuration directories you need to keep, e.g., postgresql.conf (and any files included by it), postgresql.auto.conf, pg_hba.conf, because these will be overwritten or removed in the next step.
6. Run rsync
  When using link mode, standby servers can be quickly upgraded using rsync. To accomplish this, from a directory on the primary server that is above the old and new database cluster directories, run this on the primary for each standby server:
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
```
  where old_cluster and new_cluster are relative to the current directory on the primary, and remote_dir is above the old and new cluster directories on the standby. The directory structure under the specified directories on the primary and standbys must match. Consult the rsync manual page for details on specifying the remote directory, e.g.,
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/12 \
      /opt/PostgreSQL/18 standby.example.com:/opt/PostgreSQL
```
  You can verify what the command will do using rsync's --dry-run option. While rsync must be run on the primary for at least one standby, it is possible to run rsync on an upgraded standby to upgrade other standbys, as long as the upgraded standby has not been started.
  What this does is to record the links created by pg_upgrade's link mode that connect files in the old and new clusters on the primary server. It then finds matching files in the standby's old cluster and creates links for them in the standby's new cluster. Files that were not linked on the primary are copied from the primary to the standby. (They are usually small.) This provides rapid standby upgrades. Unfortunately, rsync needlessly copies files associated with temporary and unlogged tables because these files don't normally exist on standby servers.
  If you have tablespaces, you will need to run a similar rsync command for each tablespace directory, e.g.:
```
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_12_201909212 \
      /vol1/pg_tblsp/PG_18_202307071 standby.example.com:/vol1/pg_tblsp
```
  If you have relocated pg_wal outside the data directories, rsync must be run on those directories too.
7. Configure streaming replication and log-shipping standby servers
  Configure the servers for log shipping. (You do not need to run pg_backup_start() and pg_backup_stop() or take a file system backup as the standbys are still synchronized with the primary.) If the old primary is prior to version 17.0, then no slots on the primary are copied to the new standby, so all the slots on the old standby must be recreated manually. If the old primary is version 17.0 or later, then only logical slots on the primary are copied to the new standby, but other slots on the old standby are not copied, so must be recreated manually.
Restore pg_hba.conf
If you modified pg_hba.conf, restore its original settings. It might also be necessary to adjust other configuration files in the new cluster to match the old cluster, e.g., postgresql.conf (and any files included by it), postgresql.auto.conf.
Start the new server
The new server can now be safely started, and then any rsync'ed standby servers.
Post-upgrade processing
If any post-upgrade processing is required, pg_upgrade will issue warnings as it completes. It will also generate script files that must be run by the administrator. The script files will connect to each database that needs post-upgrade processing. Each script should be run using:
```
psql --username=postgres --file=script.sql postgres
```
The scripts can be run in any order and can be deleted once they have been run.
Caution
In general it is unsafe to access tables referenced in rebuild scripts until the rebuild scripts have run to completion; doing so could yield incorrect results or poor performance. Tables not referenced in rebuild scripts can be accessed immediately.
Statistics
Unless the --no-statistics option is specified, pg_upgrade will transfer most optimizer statistics from the old cluster to the new cluster. This does not transfer all statistics, such as those created explicitly with CREATE STATISTICS, custom statistics added by an extension, or statistics collected by the cumulative statistics system.
Because not all statistics are transferred by pg_upgrade, you will be instructed to run commands to regenerate that information at the end of the upgrade. You might need to set connection parameters to match your new cluster.
First, use vacuumdb --all --analyze-in-stages --missing-stats-only to quickly generate minimal optimizer statistics for relations without any. Then, use vacuumdb --all --analyze-only to ensure all relations have updated cumulative statistics for triggering vacuum and analyze. For both commands, the use of --jobs can speed it up. If vacuum_cost_delay is set to a non-zero value, this can be overridden to speed up statistics generation using PGOPTIONS, e.g., PGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ....
Delete old cluster
Once you are satisfied with the upgrade, you can delete the old cluster's data directories by running the script mentioned when pg_upgrade completes. (Automatic deletion is not possible if you have user-defined tablespaces inside the old data directory.) You can also delete the old installation directories (e.g., bin, share).
Reverting to old cluster
If, after running pg_upgrade, you wish to revert to the old cluster, there are several options:
- If the --check option was used, the old cluster was unmodified; it can be restarted.
- If neither --link nor --swap was used, the old cluster was unmodified; it can be restarted.
- If the --link option was used, the data files might be shared between the old and new cluster:
  - If pg_upgrade aborted before linking started, the old cluster was unmodified; it can be restarted.
  - If you did not start the new cluster, the old cluster was unmodified except that, when linking started, a .old suffix was appended to $PGDATA/global/pg_control. To reuse the old cluster, remove the .old suffix from $PGDATA/global/pg_control; you can then restart the old cluster.
  - If you did start the new cluster, it has written to shared files and it is unsafe to use the old cluster. The old cluster will need to be restored from backup in this case.
- If the --swap option was used, the old cluster might be destructively modified:
  - If pg_upgrade aborts before reporting that the old cluster is no longer safe to start, the old cluster was unmodified; it can be restarted.
  - If pg_upgrade has reported that the old cluster is no longer safe to start, the old cluster was destructively modified. The old cluster will need to be restored from backup in this case.

Environment

Some environment variables can be used to provide defaults for command-line options:

PGBINOLD: The old PostgreSQL executable directory; option -b/--old-bindir.
PGBINNEW: The new PostgreSQL executable directory; option -B/--new-bindir.
PGDATAOLD: The old database cluster configuration directory; option -d/--old-datadir.
PGDATANEW: The new database cluster configuration directory; option -D/--new-datadir.
PGPORTOLD: The old cluster port number; option -p/--old-port.
PGPORTNEW: The new cluster port number; option -P/--new-port.
PGSOCKETDIR: Directory to use for postmaster sockets during upgrade; option -s/--socketdir.
PGUSER: Cluster's install user name; option -U/--username.

Notes

pg_upgrade creates various working files, such as schema dumps, stored within pg_upgrade_output.d in the directory of the new cluster. Each run creates a new subdirectory named with a timestamp formatted as per ISO 8601 (%Y%m%dT%H%M%S), where all its generated files are stored. pg_upgrade_output.d and its contained files will be removed automatically if pg_upgrade completes successfully; but in the event of trouble, the files there may provide useful debugging information.

pg_upgrade launches short-lived postmasters in the old and new data directories. Temporary Unix socket files for communication with these postmasters are, by default, made in the current working directory. In some situations the path name for the current directory might be too long to be a valid socket name. In that case you can use the -s option to put the socket files in some directory with a shorter path name. For security, be sure that that directory is not readable or writable by any other users. (This is not supported on Windows.)

All failure, rebuild, and reindex cases will be reported by pg_upgrade if they affect your installation; post-upgrade scripts to rebuild tables and indexes will be generated automatically. If you are trying to automate the upgrade of many clusters, you should find that clusters with identical database schemas require the same post-upgrade steps for all cluster upgrades; this is because the post-upgrade steps are based on the database schemas, and not user data.

For deployment testing, create a schema-only copy of the old cluster, insert dummy data, and upgrade that.

pg_upgrade does not support upgrading of databases containing table columns using these reg* OID-referencing system data types:

regcollation

regconfig

regdictionary

regnamespace

regoper

regoperator

regproc

regprocedure

(regclass, regrole, and regtype can be upgraded.)

If you want to use link mode and you do not want your old cluster to be modified when the new cluster is started, consider using the clone mode. If that is not available, make a copy of the old cluster and upgrade that in link mode. To make a valid copy of the old cluster, use rsync to create a dirty copy of the old cluster while the server is running, then shut down the old server and run rsync --checksum again to update the copy with any changes to make it consistent. (--checksum is necessary because rsync only has file modification-time granularity of one second.) You might want to exclude some files, e.g., postmaster.pid, as documented in Section 25.3.4. If your file system supports file system snapshots or copy-on-write file copies, you can use that to make a backup of the old cluster and tablespaces, though the snapshot and copies must be created simultaneously or while the database server is down.

pg_upgrade

Синтаксис

Описание

Предупреждение

Параметры

Использование

Примечание

Внимание

Переменные окружения

Примечания

См. также

pg_upgrade

Synopsis

Description

Warning

Options

Usage

Note

Caution

Environment

Notes

See Also