pg_upgrade#
pg_upgrade
pg_upgrade — Обновление экземпляра сервера Tantor SE-1C
Синтаксис
pg_upgrade
-b
oldbindir
[-B
newbindir
] -d
oldconfigdir
-D
newconfigdir
[option
...]
Описание
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 и выше до текущего основного релиза Tantor SE-1C, включая снимки и бета-версии.
Опции
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
njobs
--jobs=
njobs
количество одновременных процессов или потоков для использования
-k
--link
Используйте жесткие ссылки вместо копирования файлов в новый кластер.
-N
--no-sync
По умолчанию
pg_upgrade
будет ожидать, пока все файлы обновленного кластера будут безопасно записаны на диск. Этот параметр позволяетpg_upgrade
вернуться без ожидания, что ускоряет процесс, но означает, что последующий сбой операционной системы может повредить каталог данных. Обычно этот параметр полезен для тестирования, но не следует использовать его в рабочей установке.-o
options
--old-options
options
опции, которые должны быть переданы непосредственно команде
postgres
; несколько вызовов опций добавляются-O
options
--new-options
options
опции, которые должны быть переданы непосредственно команде
postgres
; несколько вызовов опций добавляются-p
port
--old-port=
port
старый номер порта кластера; переменная среды
PGPORTOLD
-P
port
--new-port=
port
новый номер порта кластера; переменная среды
PGPORTNEW
-r
--retain
сохранять SQL и файлы журналов даже после успешного завершения
-s
dir
--socketdir=
dir
каталог, используемый для сокетов постмастера во время обновления; по умолчанию - текущий рабочий каталог; переменная среды
PGSOCKETDIR
-U
username
--username=
username
имя пользователя установки кластера; переменная среды
PGUSER
-v
--verbose
включить подробное внутреннее ведение журнала
-V
--version
отобразить информацию о версии, затем выйти
--clone
Используйте эффективное клонирование файлов (также известное как “reflinks” в некоторых системах) вместо копирования файлов в новый кластер. Это может привести к почти мгновенному копированию файлов данных, обеспечивая преимущества скорости
-k
/--link
, при этом не затрагивая старый кластер.Воспроизведение файлов поддерживается только на некоторых операционных системах и файловых системах. Если оно выбрано, но не поддерживается, выполнение pg_upgrade завершится с ошибкой. В настоящее время оно поддерживается на Linux (ядро 4.5 или более поздней версии) с Btrfs и XFS (на файловых системах, созданных с поддержкой reflink), а также на macOS с APFS.
--copy
Скопируйте файлы в новый кластер. Это значение по умолчанию. (См. также
--link
и--clone
.)-?
--help
Показать справку, а затем выйти
Использование
Следуйте этим шагам для выполнения обновления с помощью pg_upgrade:
При желании, переместите старый кластер
Если вы используете каталог установки для конкретной версии, например,
/opt/PostgreSQL/16
, вам не нужно перемещать старый кластер. Все графические инсталляторы используют каталоги установки для конкретной версии.Если ваш каталог установки не зависит от версии, например,
/usr/local/pgsql
, необходимо переместить текущий каталог установки PostgreSQL, чтобы он не мешал новой установке Tantor SE-1C. После остановки текущего сервера Tantor SE-1C можно безопасно переименовать каталог установки 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 и запуска нового основного сервера.
Установите новые двоичные файлы PostgreSQL на резервные серверы.
Убедитесь, что новые двоичные файлы и файлы поддержки установлены на всех серверах-резервах.
Убедитесь, что новые каталоги данных для резервной копии не существуют.
Убедитесь, что новые каталоги данных резервного сервера не существуют или пусты. Если была выполнена команда initdb, удалите новые каталоги данных резервных серверов.
Установка расширения файлов shared object
Установите те же файлы расширения shared object на новых резервных серверах, которые вы установили в новом основном кластере.
Остановить резервные серверы
Если резервные серверы все еще работают, остановите их сейчас, используя вышеуказанные инструкции.
Сохранить конфигурационные файлы
Сохраните все файлы конфигурации из каталогов конфигурации старых резервных копий, которые вам нужно сохранить, например,
postgresql.conf
(и любые файлы, включенные в него),postgresql.auto.conf
,pg_hba.conf
, потому что они будут перезаписаны или удалены на следующем шаге.Запустить 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/16 standby.example.com:/opt/PostgreSQL
Вы можете проверить, что команда сделает, используя опцию
--dry-run
у rsync. В то время как 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_16_202307071 standby.example.com:/vol1/pg_tblsp
Если вы переместили
pg_wal
вне каталогов данных, необходимо также запустить rsync в этих каталогах.Настройка потоковой репликации и резервных серверов с доставкой журналов
Настройте серверы для резервного копирования журналов. (Вам не нужно запускать функции
pg_backup_start()
иpg_backup_stop()
или выполнять резервное копирование файловой системы, так как резервные копии все еще синхронизированы с основным сервером). Слоты репликации не копируются и должны быть воссозданы.
Восстановить
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
нужно вернуться к старому кластеру, есть несколько вариантов:Если использована опция
--check
, старый кластер не изменяется и может быть перезапущен.Если опция
--link
не использовалась, старый кластер остается без изменений и может быть перезапущен.Если использована опция
--link
, то файлы данных могут быть общими для старого и нового кластера.Если
pg_upgrade
прервался до начала связывания, старый кластер остался без изменений и может быть перезапущен.Если вы не запустили новый кластер, старый кластер остался без изменений, за исключением того, что при запуске связи к
$PGDATA/global/pg_control
был добавлен суффикс.old
. Чтобы повторно использовать старый кластер, удалите суффикс.old
из$PGDATA/global/pg_control
; затем вы можете перезапустить старый кластер.Если вы запустили новый кластер, то он записался в общие файлы и использование старого кластера становится небезопасным. В этом случае старый кластер должен быть восстановлен из резервной копии.
Примечания
pg_upgrade создает различные рабочие файлы, такие как дампы схемы, хранящиеся внутри pg_upgrade_output.d
в каталоге нового кластера. Каждый запуск создает новый подкаталог с именем, отформатированным в соответствии с ISO 8601 (%Y%m%dT%H%M%S
), где хранятся все сгенерированные файлы.
pg_upgrade_output.d
и его содержимое будут автоматически удалены, если pg_upgrade успешно завершится; но в случае проблем файлы там могут предоставить полезную отладочную информацию.
pg_upgrade запускает постмастеры с коротким жизненным циклом в старом и новом каталогах данных. Временные файлы сокетов Unix для связи с этими постмастерами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях путь к текущему каталогу может быть слишком длинным для допустимого имени сокета. В этом случае вы можете использовать опцию -s
, чтобы поместить файлы сокетов в какой-то каталог с более коротким именем пути. Для безопасности убедитесь, что этот каталог не доступен для чтения или записи другими пользователями.
(Не поддерживается в Windows).
Все случаи сбоев, восстановления и переиндексации будут отражены в отчете pg_upgrade, если они затрагивают вашу установку; скрипты после обновления для восстановления таблиц и индексов будут сгенерированы автоматически. Если вы пытаетесь автоматизировать обновление множества кластеров, вы должны обнаружить, что кластеры с идентичными схемами баз данных требуют одних и тех же шагов после обновления для всех обновлений кластеров; это связано с тем, что шаги после обновления основаны на схемах баз данных, а не на пользовательских данных.
Для тестирования развертывания создайте копию старого кластера только схемы, вставьте фиктивные данные и выполните обновление.
pg_upgrade не поддерживает обновление баз данных, содержащих столбцы таблиц, использующих системные типы данных reg*
с ссылками на OID.
regcollation |
regconfig |
regdictionary |
regnamespace |
regoper |
regoperator |
regproc |
regprocedure |
(regclass
, regrole
и regtype
могут быть обновлены).
Если нужно использовать режим ссылок и не хотите, чтобы ваша старая кластерная система
была изменена при запуске новой кластерной системы, рассмотрите возможность использования режима клонирования.
Если это невозможно, создайте копию
старой кластерной системы и обновите ее в режиме ссылок. Чтобы создать допустимую копию
старой кластерной системы, используйте rsync
для создания "грязной"
копии старой кластерной системы во время работы сервера, затем остановите
старый сервер и снова запустите rsync --checksum
, чтобы обновить
копию с любыми изменениями и сделать ее согласованной. (--checksum
необходимо, потому что rsync
имеет точность изменения времени модификации файла
в одну секунду). Возможно, вам захочется исключить некоторые
файлы, например, postmaster.pid
, как указано в Раздел 24.3.3. Если ваша файловая система поддерживает
снимки файловой системы или копии файлов с копированием при записи, вы можете использовать это
для создания резервной копии старой кластерной системы и таблиц-пространств, хотя снимок
и копии должны быть созданы одновременно или во время отключения базы данных.