pg_upgrade

примечание

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

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

Синтаксис

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

Описание

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

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

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

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

Параметры

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

-b bindir
--old-bindir=bindir

Указывает каталог старых исполняемых файлов PostgreSQL. Переменная окружения: PGBINOLD.

-B bindir
--new-bindir=bindir

Указывает каталог новых исполняемых файлов PostgreSQL. По умолчанию это каталог, в котором находится pg_upgrade. Переменная окружения: PGBINNEW.

-c
--check

Проверяет кластеры без внесения изменений в данные.

-d configdir
--old-datadir=configdir

Указывает каталог конфигурации старого кластера баз данных. Переменная окружения: PGDATAOLD.

-D configdir
--new-datadir=configdir

Указывает каталог конфигурации нового кластера баз данных. Переменная окружения: PGDATANEW.

-j n_jobs
--jobs=n_jobs

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

-k
--link

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

-N
--no-sync

Завершает процесс 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.

-r
--retain

Сохраняет файлы SQL и журналов, даже если обновление завершилось успешно.

-s dir
--socketdir=dir

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

-U username
--username=username

Указывает имя пользователя, выполняющего установку кластера. Переменная окружения: PGUSER.

-v
--verbose

Включает подробный журнал выполнения.

-V
--version

Выводит версию pg_upgrade и завершается.

--clone

Использует эффективное клонирование файлов (также известное как «reflinks» в некоторых системах) вместо их копирования в новый кластер. Это может значительно ускорить процесс копирования, оставляя старый кластер нетронутым.

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

--copy

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

--copy-file-range

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

--sync-method=method

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

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

Этот параметр не оказывает никакого влияния, когда используется --no-sync.

-?
--help

Показывает справку о параметрах командной строки утилиты pg_upgrade и завершается.

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

Ниже приведен порядок действий для обновления кластера PostgreSQL с помощью утилиты pg_upgrade:

Шаги для выполнения обновления с помощью pg_upgrade:

1. Переименование старого каталога установки (опционально).

   При использовании каталога установки, привязанного к версии (например, /opt/PostgreSQL/15) перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.

   Если же каталог установки не привязан к версии (например, /usr/local/pgsql), необходимо переместить текущий каталог установки PostgreSQL, чтобы он не мешал новой установке PostgreSQL.

   Остановите сервер текущей PostgreSQL, затем переместите или, в случае с /usr/local/pgsql, переименуйте каталог установки, чтобы новая инсталляция могла использовать тот же путь:

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

2. Сборка новой версии из исходников.

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

3. Установка двоичных файлов новой версии.

   Установите новые бинарные файлы сервера и необходимые библиотеки (pg_upgrade включен в установку по умолчанию).

   Для установки в пользовательскую директорию используйте параметр prefix:

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

4. Инициализация нового кластера.

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

5. Установка общих расширений.

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

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

6. Копия пользовательских файлов полнотекстового поиска.

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

7. Настройка авторизации.

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

8. Подготовка к обновлению издателя

   pg_upgrade пытается перенести логические слоты. Это помогает избежать необходимости вручную определять те же самые логические слоты на новом публикаторе. Перенос логических слотов поддерживается только тогда, когда старая версия кластера равна или выше 17.0. Логические слоты в версиях до 17.0 будут молча игнорироваться.

   Перед тем, как начать обновление кластера-публикатора, убедитесь, что подписка временно отключена, выполнив команду ALTER SUBSCRIPTION ... DISABLE. Включите подписку после завершения обновления.

   Есть некоторые предварительные условия для того, чтобы pg_upgrade мог обновить логические слоты. Если они не выполнены, будет выдано сообщение об ошибке.

   • Новый кластер должен иметь wal_level установленным как logical.
   • Новый кластер должен иметь max_replication_slots, настроенным на значение большее или равное количеству слотов, присутствующих в старом кластере.
   • Плагин вывода, указанный слотами в старом кластере, должен быть установлен в директории исполняемых файлов нового PostgreSQL.
   • Старый кластер реплицировал все транзакции и сообщения логического декодирования подписчикам.
   • Все слоты в старом кластере должны быть пригодны для использования, то есть нет слотов, у которых значение поля pg_replication_slots.conflicting не равно true.
   • Новый кластер не должен иметь постоянных логических слотов, то есть не должно быть слотов, где поле pg_replication_slots.temporary имеет значение false.

9. Подготовка к обновлению подписчика

   Настройте конфигурацию подписчика в новом подписчике. Утилита pg_upgrade пытается перенести зависимости подписки, включая информацию о таблицах подписки из системного каталога pg_subscription_rel, а также происхождение репликации подписки. Это позволяет продолжить логическую репликацию на новом подписчике с того места, до которого дошла старая подписка. Перенос зависимостей подписки поддерживается только при условии, что версия старого кластера равна 17.0 или выше. Зависимости подписки в версиях кластеров ниже 17.0 будут игнорироваться.

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

   • Все таблицы подписки в старом подписчике должны находиться в состоянии i (инициализация) или r (готовность). Это можно проверить, проверив поле pg_subscription_rel.srsubstate.
   • Запись происхождения репликации, соответствующая каждой из подписок, должна существовать в старом кластере. Ее можно найти, проверив системные таблицы pg_subscription и pg_replication_origin.
   • В новом кластере параметр max_replication_slots должен быть настроен на значение большее или равное количеству подписок, присутствующих в старом кластере.

10. Остановка обоих серверов.

Остановите оба сервера базы данных перед запуском обновления. Для этого в Unix выполните:

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

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

NET STOP postgresql-12
NET STOP postgresql-17

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

11. Синхронизация реплик.

Если планируется обновление резервных серверов с использованием методов, указанных в шаге 11, необходимо предварительно убедиться, что старые резервные серверы синхронизированы с основным.

Для этого запустите pg_controldata как для основного, так и для резервных кластеров, и проверьте, что значения «положение последней контрольной точки» совпадают. Кроме того, убедитесь, что в конфигурационном файле postgresql.conf нового основного кластера параметр wal_level не установлен в значение minimal.

12. Запуск pg_upgrade.

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

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

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

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

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

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

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

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

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

13. (ru-ru.PGUPGRADE-STEP-REPLICAS)= Обновление резервных серверов.

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

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

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

    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/17 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_17_202307071 standby.example.com:/vol1/pg_tblsp

       Если каталог pg_wal был вынесен за пределы каталогов данных, запустите также rsync на этих каталогах.

    7. Настройка резервных серверов с потоковой репликацией и трансляцией журнала.

       Настройте серверы для передачи журналов. Нет необходимости запускать pg_backup_start() и pg_backup_stop() или создавать резервную копию файловой системы, так как резервные копии остаются синхронизированы с главным сервером. Если старый главный сервер имеет версию до 17.0, слоты на главном сервере не копируются на новый резервный сервер, поэтому все слоты на старом резервном сервере должны быть созданы вручную. Если версия старого главного сервера — 17.0 или новее, только логические слоты на главном сервере копируются на новый резервный сервер; другие слоты на старом резервном сервере не копируются, поэтому их тоже придется создать вручную.

14. Восстановление pg_hba.conf

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

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

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

16. Действия после обновления

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

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

    Порядок запуска сценариев произвольный. После выполнения их можно удалить.

    Осторожно

    Не рекомендуется обращаться к таблицам, указанным в перестраивающих базу скриптах, до их полного выполнения. Это может привести к ошибкам в данных или ухудшению производительности. Таблицы, которые не упомянуты в этих скриптах, можно использовать сразу.

17. Статистика

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

    Использование vacuumdb --all --analyze-only позволяет эффективно генерировать такую статистику, а использование --jobs ускоряет этот процесс. Опция --analyze-in-stages может использоваться для быстрого создания минимальной статистики. Если значение параметра vacuum_cost_delay отлично от нуля, его можно переопределить для ускорения генерации статистики с помощью PGOPTIONS, например, так: PGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ....

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

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

19. (ru-ru.PGUPGRADE-STEP-REVERT)= Возврат к старому кластеру

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

    • Использовалась только проверка (--check), старый кластер не был затронут и может быть запущен заново.

    • Режим ссылок (--link) не применялся, данные старого кластера остались неизменными, и он может быть повторно запущен.

    • Использовался режим ссылок (--link), возможны следующие ситуации, если:

      • pg_upgrade был прерван до создания ссылок, старый кластер остается неизменным и может быть снова запущен.
      • Новый кластер не запускался, старый изменен только частично — к файлу $PGDATA/global/pg_control добавлен суффикс .old. Для восстановления достаточно удалить этот суффикс, после чего кластер снова станет работоспособным.
      • Новый кластер запускался, он мог изменить общие файлы. В этом случае использование старого кластера небезопасно, и для восстановления потребуется резервная копия.

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

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

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 завершается успешно, каталог pg_upgrade_output.d и его содержимое удаляются автоматически. В случае сбоя эти файлы могут оказаться полезными для отладки.

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

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

Для предварительного тестирования можно создать копию старого кластера, включающую только структуру (схему), дополнить ее фиктивными данными и выполнить обновление.

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

• regcollation
• regconfig
• regdictionary
• regnamespace
• regoper
• regoperator
• regproc
• regprocedure

Обновление возможно для типов regclass, regrole и regtype.

Если планируется использовать режим ссылок (--link), но необходимо избежать изменений в старом кластере после запуска нового, следует применить режим клонирования (--clone). При отсутствии поддержки клонирования в файловой системе можно вручную создать копию старого кластера и выполнить обновление этой копии в режиме ссылок.

Для получения корректной копии работающего кластера рекомендуется сначала создать так называемую «грязную» копию с помощью rsync, пока старый сервер продолжает работать. Затем необходимо остановить сервер и снова выполнить rsync с параметром --checksum, чтобы учесть все возможные изменения и добиться согласованности копии. Параметр --checksum критичен, так как rsync использует точность времени модификации файлов с шагом в одну секунду.

При необходимости можно исключить отдельные файлы, такие как postmaster.pid, как указано в разделе «Создание резервной копии базы данных с использованием низкоуровневого API», чтобы избежать нежелательного поведения.

сли файловая система поддерживает снимки файловой системы или копирование при записи, эти возможности можно использовать для создания резервной копии старого кластера и табличных пространств. Однако такие снимки и копии должны быть сделаны одновременно либо в период, когда сервер базы данных остановлен.

Смотрите также

initdb, pg_ctl, pg_dump, postgres