Upgrade PostgreSQL Version without uninstall Existing PostgreSQL in Ubuntu
PostgreSQL is an open-source database management system that is used for object-relational mapping and data storage. It is a powerful and versatile database system that is used by many businesses and individuals for their data storage needs. If you are running an old version of PostgreSQL on your Ubuntu 20.04 system, you may want to upgrade it to the latest version. This tutorial will guide you through the process of upgrading PostgreSQL on Ubuntu 20.04.
Before starting the upgrade process, you should make sure that all of your databases are backed up and that you have a working backup of your current PostgreSQL installation. It is also important to note that the upgrade process may take some time, depending on the size of your database.
However, if you want to upgrade or downgrade the PostgreSQL version on your Ubuntu system, you can do so using the following steps.
Step-1: The first step is to update your system packages. This can be done by running the following command in a terminal:
Step-2: To find the installed versions that you currently have on your machine
Step-3: Once your system packages have been updated, you can upgrade PostgreSQL by running the following command:
Replace the <version> with the version of PostgreSQL you want to install.
Step-4: You can also list the clusters that are on your machine by running.
Какой командой можно выполнить обновление конфигурации postgresql
pg_upgrade — обновить экземпляр сервера PostgreSQL
Синтаксис
pg_upgrade -b старый_каталог_bin [ -B новый_каталог_bin ] -d старый_каталог_конфигурации -D новый_каталог_конфигурации [ параметр . ]
Описание
Программа pg_upgrade (ранее называвшаяся pg_migrator ) позволяет обновить данные в каталоге базы данных PostgreSQL до последней основной версии PostgreSQL без операции выгрузки/восстановления данных, обычно необходимой при обновлениях основной версии, например, при переходе от 9.5.8 к 9.6.4 или от 10.7 к 11.2. Эти действия не требуются при установке корректирующей версии, например, при переходе от 9.6.2 к 9.6.3 или от 10.1 к 10.2.
С выходом новых основных версий в PostgreSQL регулярно добавляются новые возможности, которые часто меняют структуру системных таблицы, но внутренний формат хранения меняется редко. Учитывая этот факт, pg_upgrade позволяет выполнить быстрое обновление, создавая системные таблицы заново, но сохраняя старые файлы данных. Если при обновлении основной версии формат хранения данных изменится так, что данные в старом формате окажутся нечитаемыми, pg_upgrade не сможет произвести такое обновление. (Сообщество разработчиков постарается не допустить подобных ситуаций.)
Программа pg_upgrade делает всё возможное, чтобы убедиться в том, что старый и новый кластеры двоично-совместимы, в частности проверяя параметры времени компиляции и разрядность (32/64 бита) исполняемых файлов. Важно, чтобы и все внешние модули тоже были двоично-совместимыми, хотя это pg_upgrade проверить не может.
pg_upgrade поддерживает обновление с версии 9.2.X и новее до текущей основной версии PostgreSQL , включая бета-выпуски и сборки снимков кода.
Параметры
pg_upgrade принимает следующие аргументы командной строки:
каталог с исполняемыми файлами старой версии 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. -?
—help
показать справку, а затем завершиться
Использование
Далее описан план обновления с использованием pg_upgrade :
Переместить старый кластер (необязательно)
Если ваш каталог инсталляции привязан к версии, например, /opt/PostgreSQL/15 , перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.
Если ваш каталог инсталляции не привязан к версии, например /usr/local/pgsql , необходимо переместить каталог текущей инсталляции PostgreSQL, чтобы он не конфликтовал с новой инсталляцией PostgreSQL . Когда текущий сервер PostgreSQL отключён, каталог этой инсталляции PostgreSQL можно безопасно переместить; если старый каталог /usr/local/pgsql , его можно переименовать, выполнив:
Собрать новую версию при установке из исходного кода
Соберите из исходного кода новую версию PostgreSQL с флагами configure , совместимыми с флагами старого кластера. Программа pg_upgrade проверит результаты pg_controldata , чтобы убедиться, что все параметры совместимы, прежде чем начинать обновление.
Установить новые исполняемые файлы PostgreSQL
Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.
При установке из исходного кода, если вы хотите разместить сервер в нестандартном каталоге, воспользуйтесь переменной prefix :
Инициализировать новый кластер PostgreSQL
Инициализируйте новый кластер, используя initdb . При этом так же необходимо указать флаги initdb , совместимые с флагами в старом кластере. Многие готовые инсталляторы выполняют это действие автоматически. Запускать новый кластер не требуется.
Установить разделяемые объектные файлы расширения
Многие расширения и пользовательские модули, как из contrib , так и из других источников, используют разделяемые объектные файлы (или библиотеки DLL), например, pgcrypto.so . Если они использовались в старом кластере, разделяемые объектные файлы, соответствующие новому исполняемому файлу сервера, должны быть установлены в новом кластере, обычно средствами операционной системы. Не загружайте определения схемы, например, выполняя CREATE EXTENSION pgcrypto , потому что они будут скопированы из старого кластера. Если доступны обновления расширений, pg_upgrade сообщит об этом и создаст скрипт, который можно будет запустить позже, чтобы обновить эти расширения.
Скопируйте пользовательские файлы полнотекстового поиска
Скопировать пользовательские файлы полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов) из старого кластера в новый.
Настроить аутентификацию
Программа pg_upgrade будет подключаться к новому и старому серверу несколько раз, так что имеет смысл установить режим аутентификации peer в pg_hba.conf или использовать файл
Остановить оба сервера
Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:
А в Windows, с соответствующими именами служб:
Ведомые серверы с потоковой репликацией и трансляцией журнала могут продолжать работать до последнего шага.
Подготовиться к обновлению ведомых серверов
Если вы производите обновление ведомых серверов (как описано в разделе Шаг 11), удостоверьтесь, что эти серверы находятся в актуальном состоянии, запустив pg_controldata в старых ведущем и ведомых кластерах. Убедитесь в том, что « Положение последней контрольной точки » во всех кластерах одинаковое. (Несовпадение будет иметь место, если старые ведомые серверы будут отключены раньше, чем старый ведущий, или если старые ведомые серверы всё ещё продолжают работать.) Также убедитесь в том, что в файле postgresql.conf нового ведущего кластера значение wal_level выше minimal .
Запустить pg_upgrade
Всегда запускайте программу pg_upgrade от нового сервера, а не от старого. pg_upgrade требует указания каталогов данных старого и нового кластера, а также каталогов исполняемых файлов ( bin ). Вы можете также определить имя пользователя и номера портов, и нужно ли копировать файлы данных (по умолчанию), клонировать их или создавать ссылки на них.
Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_wal могут находиться в других файловых системах.) Вариант с клонированием работает так же быстро и экономит место на диске, но позволяет сохранить рабочее состояние старого кластера при запуске нового. Для этого варианта тоже требуется, чтобы старый и новый каталоги данных находились в одной файловой системе. Клонирование возможно только в некоторых операционных системах с определёнными файловыми системами.
Параметр —jobs позволяет задействовать для копирования/связывания файлов и для выгрузки/восстановления схем баз данных несколько процессорных ядер. В качестве начального значения параметра стоит выбрать максимум из числа процессорных ядер и числа табличных пространств. Этот параметр может радикально сократить время обновления сервера со множеством баз данных, работающего в многопроцессорной системе.
В Windows вы должны войти в систему с административными полномочиями, затем запустить командную строку от имени пользователя postgres , задать подходящий путь:
Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:
При запуске pg_upgrade проверит два кластера на совместимость и, если всё в порядке, выполнит обновление. Также возможно запустить pg_upgrade —check , чтобы ограничиться только проверками (при этом старый сервер может продолжать работать). Команда pg_upgrade —check также сообщит, какие коррективы вам нужно будет внести вручную после обновления. Если вы планируете использовать режим ссылок на данные или клонирования, укажите вместе с —check или —clone параметр —link , чтобы были проведены специальные проверки для этого режима. Программе pg_upgrade требуются права на запись в текущий каталог.
Очевидно, никто не должен обращаться к кластерам в процессе обновления. Программа pg_upgrade по умолчанию запускает серверы с портом 50432, чтобы не допустить нежелательных клиентских подключений. В процессе обновления оба кластера могут использовать один номер порта, так как они не будут работать одновременно. Однако для проверки старого работающего сервера новый порт должен отличаться от старого.
Если при восстановлении схемы базы данных происходит ошибка, pg_upgrade завершает свою работу и вы должны вернуться к старому кластеру, как описывается ниже в Шаг 17. Чтобы попробовать pg_upgrade ещё раз, вы должны внести коррективы в старом кластере, чтобы pg_upgrade могла успешно восстановить схему. Если проблема возникла в модуле contrib , может потребоваться удалить этот модуль contrib в старом кластере, а затем установить его в новом после обновления (предполагается, что этот модуль не хранит пользовательские данные).
Обновить ведомые серверы с потоковой репликацией и трансляцией журнала
Если вы используете режим ссылок и у вас реализована потоковая репликация (см. Подраздел 27.2.5) или трансляция журнала (см. Раздел 27.2) для ведомых серверов, вы можете быстро обновить эти серверы следующим образом. Вам не нужно будет запускать на них pg_upgrade , вместо этого вы выполните rsync на ведущем. Не запускайте никакие серверы на этом этапе.
Если вы не используете режим ссылок, либо у вас нет rsync или вы не хотите его использовать, либо если вам нужен более простой вариант, пропустите инструкции в этом разделе и просто пересоздайте ведомые серверы сразу после завершения pg_upgrade и запуска нового ведущего сервера.
Установите новые исполняемые файлы PostgreSQL на ведомых серверах
Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.
Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют
Новые каталоги данных ведомых серверов должны отсутствовать либо быть пустыми. Если запускалась программа initdb , удалите новые каталоги данных на ведомых.
Установить разделяемые объектные файлы расширения
Установите на новых ведомых серверах те же разделяемые объектные файлы расширения, что вы установили в новом ведущем кластере.
Остановите ведомые серверы
Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.
Сохраните файлы конфигурации
Сохраните все нужные вам файлы конфигурации из старых каталогов конфигурации ведомых серверов, в частности postgresql.conf (и все файлы, включённые в него), postgresql.auto.conf и pg_hba.conf , так как они будут перезаписаны или удалены на следующем этапе.
Запустите rsync
Когда используется режим ссылок, ведомые серверы можно быстро обновить, применив rsync . Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем :
Здесь каталоги old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится над каталогами старого и нового кластера на ведомом. Структура подкаталогов в заданных каталогах на ведущем и ведомых серверах должна быть одинаковой. Обратитесь к странице руководства rsync , где подробно описано, как указать удалённый каталог, например так:
Проверить, что будет делать команда, можно, воспользовавшись параметром rsync —dry-run . Выполнить rsync на ведущем необходимо как минимум с одним ведомым, но затем, пока обновлённый ведомый остаётся остановленным, можно запускать rsync на нём для обновления других ведомых.
В ходе этой операции записываются ссылки, созданные режимом ссылок pg_upgrade , связывающие файлы нового и старого кластера на ведущем сервере. Затем в старом кластере ведомого находятся соответствующие файлы и в новом кластере ведомого создаются ссылки на них. Файлы, не связанные ссылками на ведущем, копируются с него на ведомый. (Обычно их объём невелик.) Это позволяет произвести обновление ведомого быстро. К сожалению, при этом rsync будет напрасно копировать файлы, связанные с временными и нежурналируемыми таблицами, так как они обычно не будут существовать на ведомых серверах.
Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:
Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.
Настройте ведомые серверы с потоковой репликацией и трансляцией журнала
Восстановить pg_hba.conf
Если вы изменяли pg_hba.conf , восстановите его исходное состояние. Также может потребоваться скорректировать другие файлы конфигурации в новом кластере, чтобы они соответствовали старому, например, postgresql.conf (и файлы, включённые в него) и postgresql.auto.conf .
Запустить новый сервер
Теперь можно безопасно запустить новый сервер, а затем ведомые серверы, синхронизированные с ним с помощью rsync .
Действия после обновления
Если после обновления требуются какие-то дополнительные действия, программа pg_upgrade выдаст предупреждения об этом по завершении работы. Она также сгенерирует файлы скриптов, которые должны запускаться администратором. Эти скрипты будут подключаться к каждой базе данных, требующей дополнительных операций. Каждый такой скрипт следует выполнять командой:
Эти скрипты могут выполняться в любом порядке, а после выполнения их можно удалить.
Внимание
Обычно к таблицам, задействованным в перестраивающих базу скриптах, опасно обращаться, пока эти скрипты не сделают свою работу; при этом можно получить некорректный результат или плохую производительность. К таблицам, не задействованным в таких скриптах, можно обращаться немедленно.
Статистика
Так как статистика оптимизатора не передаётся в процессе работы 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 запускает на короткое время процессы postmaster со старым и новым каталогом данных. Временные файлы сокетов Unix для взаимодействия с этими процессами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях путь к файлу в текущем каталоге может оказаться слишком длинным для имени сокета. В этом случае вы можете передать параметр -s , чтобы файлы сокетов создавались в другом каталоге с более коротким путём. В целях безопасности этот каталог не должен быть доступен для чтения и записи другим пользователям. (В Windows это не поддерживается.)
Программа pg_upgrade сообщит обо всех актуальных для вашей инсталляции ошибках и потребностях перестроения или переиндексации базы; при этом будут созданы завершающие обновление скрипты, перестраивающие таблицы или индексы. Если вы попытаетесь автоматизировать обновление множества серверов, вы обнаружите, что для кластеров с одинаковыми схемами баз данных потребуются одинаковые действия после обновления; это объясняется тем, что эти действия диктуются схемой базы данных, а не данными пользователей.
Для проверки развёртывания новой версии создайте копию только схемы старого кластера, наполните этот кластер фиктивными данными, и попробуйте обновить его.
Обновление PostgreSQL сервера
Эти инструкции предполагают, что домашняя дерриктория pgsql расположена в /usr/local/pgsql, и данные находится в /usr/local/pgsql/data.
Если ваша конфигурация другая, замените соответствующие пути на свои. Внутренний формат хранения данных типично изменяется в каждом главном выпуске PostgreSQL. Поэтому, если Вы обновляете существующую установку, младше версии “8.3.x”, Вы должны сделать резервную копию, а затем восстановить данные. Если Вы обновляете PostgreSQL “8.3.x”, новая версия может использовать Ваши текущие файлы с данными, таким образом Вы сможете пропустить этапы резервного копирования и восстановления.
1. Делая резервную копию, удостоверьтесь, что Ваша база данных не обновляется. Это не затронет целостность резервной копии, но измененные данные не будут внесены. В случае необходимости, отредактируйте разрешения в файле/usr/local/pgsql/data/pg_hba.conf, чтобы закрыть доступ от всем кроме Вас. Чтобы создать резервную копию БД введите
Если Вам нужно сохранить OIDs используйте ключ -o. Чтобы сделать резервную копию, Вы можете использовать команду pg_dumpall от версии, которой Вы в настоящий момент установлена. Для лучших результатов, однако, следует использовать команду pg_dumpall от PostgreSQL 8.3.5, так как эта версия содержит исправления ошибок и усовершенствования по старшим версиям. Совет может показаться странным, так как Вы еще не установили новую версию, можно последовать ему, если Вы планируете установить новую версию без предварительного удаления старой версии. В этом случае Вы можете сначала заканчивать установку и потом перенести данные. Это также уменьшит время простоя.
2. Остановите старый сервер:
или (в зависимости от установки PgSQL в вашей системе)
3. Переименуйте или удалите старый домашний каталог pgsql. Можно переименовать справочник, вместо того, чтобы удалить его, в случае, если появятся проблемы при установке вы сможете вернуться к старой версии. Имейте в виду, что домашний каталог базы может занимать существенное дисковое пространство. Чтобы переименовать справочник, используйте команду:
mv /usr/local/pgsql /usr/local/pgsql.old
4. Установите новую версию PostgreSQL (http://www.postgresql.org/docs/current/static/install-procedure.html)
5. Инициализируйте вновь установленную базу данных (необходимо запускать команды от пользователя под которым будет работать сервер БД, обычно это пользователь pgsql).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
6. Восстановите необходимые настройки pg_hba.conf и postgresql.conf.
7. Запустите сервер базы данных (опять же от пользователя под которым должен работать сервер БД):
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
8. Наконец, восстановите свои данные из резервной копии
/usr/local/pgsql/bin/psql -d postgres -f outputfile
Используйте новую версию PgSQL!
upd: перед обновлением тщательно подумайте над тем что делаете, т.к. версии не всегда совместимы, и приложения которые ранее работали с вашим сервером могут перестать работать.
upd2: в случае если вы столкнулись с тем, Что ваши приложения несовместимы с обновленной версией, установите обратно предыдущую версию и замените в ней каталог /usr/local/pgsql/data на ранее сохраненный (если вы его не удалили, а переименовали в п.3).
Обновление PostgreSQL на CentOS
Опубликовано: 28.09.2022
В нашей инструкции мы рассмотрим пример обновления СУБД PostgreSQL с версии 11 на версию 13. В качестве рабочей операционной системы будет использоваться CentOS, однако, с заменой путей до баз и конфигурационных файлов, можно будет выполнить обновление для других систем.
Процедура обновления состоит из нескольких шагов:
- Создание резервных копий.
- Установка и запуск PostgreSQL новой версии (она будет работать параллельно со старой).
- Запуск pg_upgrade для проверки возможности обновления.
- Запуск pg_upgrade для выполнения обновления.
- Проверка работоспособности СУБД.
- Настройка новой версии в качестве основного экземпляра сервера баз данных.
Предполагается, что у нас уже установлена одна СУБД, которую мы и будем обновлять.
Прежде чем начать
1. Операция по обновлению PostgreSQL, потенциально, опасна. Поэтому стоит позаботиться о создании резервной копии.
Подробнее процесс описан в инструкции Резервное копирование PostgreSQL.
Также, если мы работает на виртуальной машине, можно создать снапшот.
2. Заранее посмотрим список расширений, которые мы используем в текущем PostgreSQL (это делается из консоли psql):
su — postgres -c "psql"
Мы можем увидеть что-то на подобие:
Name | Version | Schema | Description
—————+———+————+—————————————
btree_gin | 1.3 | public | support for indexing common datatypes
btree_gist | 1.5 | public | support for indexing common datatypes
В данной таблице представлен список установленных расширений postgresql. Вам нужно будет установить те же расширения для новой версии СУБД. Также обратите внимание, что некоторые расширения могут быть установлены для конкретной базы. Нужно по очереди подключиться к каждой базе:
И запросить список расширений:
После окончания работы, выходим из оболочки psql:
Установка и запуск PostgreSQL 13
В нашей инструкции мы планируем обновление до версии 13. Установим нужный нам пакет.
Для этого необходимо установить репозиторий.
Так как в нашей системе уже установлен PostgreSQL, скорее всего, репозиторий уже настроен, но мы все же, рассмотрим его установку.
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
* в данном примере мы установим репозиторий для CentOS 7 с архитектурой x86_64 (EL-7-x86_64). Полный список вариантов можно посмотреть по на странице репозитория PostgreSQL.
.
Error: Nothing to do
. значит репозиторий уже настроен. Идем дальше.
yum install postgresql13 postgresql13-server postgresql13-contrib
- postgresql13 — клиент.
- postgresql13-server — сервер.
- postgresql13-contrib — набор дополнительных утилит и расширений для postgresql.
Инициализируем базу для нового postgresql:
Откроем конфигурационный файл для postgresql 13:
Как минимум, нам нужно поменять порт, на котором должен запуститься наш сервер:
* порт по умолчанию 5432 и, скорее всего, на нем работает наш сервер версии 11, который мы будем обновлять. Поэтому мы поменяли порт, например, на 5433.
Стоит сравнить настройки для файлов postgresql.conf и pg_hba.conf. Некоторые настройки, которые явно менялись для текущей версии СУБД, стоит перенести в конфигурационные файлы нового postgresql.
Запускаем сервис для установленного PostgreSQL:
systemctl start postgresql-13
Стоит сразу проверить, запустилась ли служба и слушает ли сервис на нужном порту (мы настроили 5433):
systemctl status postgresql-13
ss -tunlp | grep :5433
Подключиться к новой версии СУБД можно командой:
su — postgres -c "PGPORT=5433 psql"
Сбор данных и запуск проверки на возможность обновления
И так, на текущий момент у нас запущены две версии postgresql (в нашем примере 11 и 13). Так как СУБД позволяет системному администратору тонко настроить расположение путей до рабочих данных и конфигов, выполним запросы, которые позволят однозначно определить их локацию.
Для текущей версии:
su — postgres -c "psql"
=# SELECT current_setting('data_directory'), current_setting('config_file');
su — postgres -c "PGPORT=5433 psql"
=# SELECT current_setting('data_directory'), current_setting('config_file');
Фиксируем полученные ответы. Они нам понадобятся для теста конфигурации.
Останавливаем службу postgresql для новой версии:
systemctl stop postgresql-13
Выполняем тест — в моем случае получилась такая команда:
su — postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
—old-datadir=/var/lib/pgsql/11/data \
—new-datadir=/var/lib/pgsql/13/data \
—old-bindir=/usr/pgsql-11/bin \
—new-bindir=/usr/pgsql-13/bin \
—old-options '-c config_file=/var/lib/pgsql/11/data/postgresql.conf' \
—new-options '-c config_file=/var/lib/pgsql/13/data/postgresql.conf' \
—check \
"
* еще раз стоит отметить, что пути зависят от версий postgresql и индивидуальных настроек.
Если все хорошо, то мы увидим:
Performing Consistency Checks on Old Live Server
————————————————
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*
Мы готовы обновить СУБД.
Обновление PostgreSQL
Остается выполнить само обновление.
Сначала нужно остановить текущий экземпляр СУБД:
systemctl stop postgresql-11
Для обновления используем такую же команду, как при проверке, за исключением опции check:
su — postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
—old-datadir=/var/lib/pgsql/11/data \
—new-datadir=/var/lib/pgsql/13/data \
—old-bindir=/usr/pgsql-11/bin \
—new-bindir=/usr/pgsql-13/bin \
—old-options '-c config_file=/var/lib/pgsql/11/data/postgresql.conf' \
—new-options '-c config_file=/var/lib/pgsql/13/data/postgresql.conf' \
"
Если размер базы большой, и места на сервере не хватит для создания полной копии, мы можем добавить опцию —link. Она создает символьные ссылки вместо полноценных копий данных.
После ее работы мы должны увидеть:
Upgrade Complete
—————-
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
В данном тексте предлагается перенести статистику оптимизатора на новый сервер. В двух словах, данная статистика позволяет делать большие запросы быстрее. Также, в сообщении предлагается удалить данные старого сервера.
Стартуем новый сервер:
systemctl start postgresql-13
Переносим статистику командой:
su — postgres -c "PGPORT=5433 /var/lib/pgsql/analyze_new_cluster.sh"
Тест сервера и завершение настройки
Напоследок, проверим, что наш сервер выполняет запросы и настроим ему порт по умолчанию.
Зайдем в командную оболочку нового сервера:
su — postgres -c "PGPORT=5433 psql"
На свое усмотрение, сделаем несколько запросов, чтобы убедиться в базовой работоспособности СУБД. Если запросы прошли, выходим из оболочки:
Открываем конфигурационный файл:
Меняем порт, на котором должен слушать сервер:
* ранее мы использовали порт 5433.
systemctl restart postgresql-13
Проверяем работу приложений, которые используют СУБД.
Если тесты прошли успешно и мы не использовали опцию —link при обновлении, то можно удалить данные старого кластера:
su — postgres -c "/var/lib/pgsql/delete_old_cluster.sh"
Обновление PostgreSQL можно считать, полностью, завершенным.
Возможные проблемы
В данном разделе рассмотрим проблемы, с которыми можно столкнуться при обновлении PostgreSQL.
Checking for presence of required libraries
Появляется при проверке на возможность сделать обновление. Ошибка также сопровождается текстом:
Your installation references loadable libraries that are missing from the
new installation. You can add these libraries to the new installation,
or remove the functions using them from the old installation. A list of
problem libraries is in the file:
loadable_libraries.txt
Причина: в новой версии PostgreSQL нет нужных библиотек для расширений, используемых в старой.
Решение: смотрим содержимое файла loadable_libraries.txt:
В нем перечислены библиотеки, которые нужно доустановить в новой версии. Установка расширений для postgresql, как правило, выполняется с помощью пакетного менеджера, например:
yum install pgtap_13
Однако, некоторые расширения нужно будет собирать, поэтому решение проблемы имеет индивидуальный характер.
Проблема подключения к СУБД после обновления
После завершения работы утилиты pg_upgrade и запуска службы, мы можем подключиться к СУБД от пользователя postgres, но не можем подключиться по сети или из приложения.
Причина: как правило, проблема в конфигурации pg_hba.
Решение: файл pg_hba.conf регламентирует условия подключения к СУБД — с каких узлов, для каких учетных записей, к каким базам и с помощью какого метода аутентификации. Необходимо привести в соответствие наши файлы. Данный файл находится в том же каталоге, что и основной файл конфигурации, в нашем примере это:
Файл для нового postgresql:
Также необходимо обратить внимание на методы шифрования паролей. Например, в 11 версии по умолчанию используется md5, например: