Как обновить базу данных PostgreSQL - pg_upgrade

  • Последнее обновление: 3 Апреля 2024 г.
  • Просмотры: 32
  • Автор: Админ
Как обновить базу данных PostgreSQL - pg_upgrade

Коллеги всем привет.

В сегодняшней статье мы поговорим о том как обновить кластер базы данных PostgresSQL до последней версии с помощью утилиты pg_upgrade. Обновления будем проводить из 13 версии на 14.

Рано или поздно вы столкнетесь с такой проблемой как обновить базу данных PostgresSQL до последней версии. Обновлять базу данных является очень важной и востребованной задачей в жизни администратора баз данных, так как разработчики СУБД PostgresSQL с каждой новой версией устраняют различные проблемы с производительностью и безопасностью, а так же добавляют новые функции.

Обновить базу данных можно двумя способами.

Первый способ заключается в том чтобы сначала сделать резервную копию всей базы данных с помощью утилиты pg_dump или pg_dumpall, затем удалить старую базу данных и вместо старой развернуть новую, и только после теми же утилитами pg_dump или pg_dumpall восстановить резервную копию уже в новую СУБД PostgresSQL. Этот способ отлично подходит в том случаи если у вас размер вашей базы данных не очень велик в размерах, а то если у вас размер базы данных превышает 100 гигабайт то на обновления уйдет очень много времени.

Второй способ заключается в том, чтобы использовать утилиту pg_upgrade. Утилита pg_upgrade позволяет обновлять базу данных без создания резервных копий и восстановления этих копий утилитами pg_dump или pg_dumpall. pg_upgrade в процессе обновления переносит данные со старого кластера в новый путем обычного копирования данных. pg_upgrade перед обновлениями проверяет, чтобы старый и новый кластер были совместимы с бинарными файлами, утилита проверяет совместимые настройки времени компиляции, включая 32/64-битные бинарные файлы. Использования pg_upgrade дает нам большой плюс в том что обновления происходит очень быстро. Мы обновляли базу данных размером в 3 терабайта, и обновления заняло у нас примерно 10 минут.

 

Содержание статьи:

  1. Предварительные требования.
  2. Расположения директорий.
  3. Файлы переменных окружений.
  4. Сборка и инициализация нового кластера.
  5. Проверка совместимости.
  6. Останавливаем старый кластер.
  7. Обновляем кластер простым методом.
  8. Запуск нового кластера.
  9. Итоги.

 

Синтаксис утилиты:

pg_upgrade -b old_pghome_bin -B new_pghome_bin -d old_pgdata -D new_pgdata [--options]

 

1. Предварительные требования.

Чтобы вам было понятно о чем идет речь в данной статье я вам очень рекомендую посмотреть статью о том как мы проводить установку СУБД PostgresSQL на Centos 8.

Скачать и установить Postgresql 14 на Linux CentOS/RHEL 8/7 TAR


 

2. Расположения директорий.

Каждая из СУБД у нас будет храниться в отдельных директориях.

Версия СУБД 13 будет храниться в директории /app/postgresql/13 и хранить в себе еще три директории. Первая директория называется log, она отвечает за то, чтобы хранить в себе все журналы событий связанные с базой данных. Вторая директория называется pgdata, она отвечает за то, чтобы хранить в себе все файлы кластера базы данных. Третья директория называется pghome, она хранит в себе все утилиты по управлению базой данных, все возможные расширения и различные библиотеки.

/app/postgresql/13
/app/postgresql/13/log
/app/postgresql/13/pgdata
/app/postgresql/13/pghome

postgresql upgrade

 

Версия СУБД версии 14 будет храниться в директории /app/postgresql/14 и хранить в себе те же три директории с одинаковыми именами.

/app/postgresql/14
/app/postgresql/14/log
/app/postgresql/14/pgdata
/app/postgresql/14/pghome

postgresql upgrade


 

3. Файлы переменных окружений.

В домашней директории учетной записи postgres у нас должно быть создано два файла переменных окружений. Под каждую базу данных у нас будет отдельный файл с конкретными переменными которые нужны для нормальной работы самой базы данных. Называться файлы будут pgsql_13.env и pgsql_14.env. Файл pgsql_13.env будет относиться в базе данных версии 13, а файл pgsql_14.env будет относиться к версии базы данных 14. Содержимое каждого из файлов будет показано ниже.

postgresql upgrade

Файл pgsql_13.env

export PGUSER=postgres
export PGPORT=5432
export PGPASSWORD='Qwerty123!'
export PGHOME=/app/postgresql/13/pghome
export LD_LIBRARY_PATH=/app/postgresql/13/pghome/lib
export PGDATA=/app/postgresql/13/pgdata
export PATH=$PGHOME/bin:$PGDATA:$PATH

 

Файл pgsql_14.env

export PGUSER=postgres
export PGPORT=5432
export PGPASSWORD='Qwerty123!'
export PGHOME=/app/postgresql/14/pghome
export LD_LIBRARY_PATH=/app/postgresql/14/pghome/lib
export PGDATA=/app/postgresql/14/pgdata
export PATH=$PGHOME/bin:$PGDATA:$PATH

 

Обозначения переменных:

  • PGUSER - Основная учетная запись из под которой происходим авторизация в базе дынных.
  • PGPORT - Порт на котором запущена база данных.
  • PGPASSWORD - Пароль от учетной записи  из под которой происходим авторизация в базе дынных.
  • PGHOME - Путь до директории в которой хранятся все утилиты которые управляют базой данных.
  • LD_LIBRARY_PATH - Путь до библиотек которые использует база данных.
  • PGDATA - Путь до директории где хранятся все файлы кластера базы данных.
  • PATH - Переопределяем основную переменную в Linux путем добавления переменных связанных с СУБД PostgreSQL.

 

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

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

Показывать в этой статье как собирать новый кластер я не буду, потому что вы можете посмотреть это в моей прошлой статье как Скачать и установить Postgresql 14 на Linux CentOS/RHEL 8/7 TAR.

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

Обозначения конфигурационных файлов.

  • pg_hba.conf - Отвечает за авторизацию в базу данных.
  • postgresql.conf - Основной конфигурационный файл который отвечает за всю базу данных.

 

5. Проверка совместимости.

Ну на конец-то мы потихоньку подходим к тому, чтобы использовать утилиту pg_upgrade. Самое важное что нам нужно знать так это то что утилиту нужно запускать из нового кластера, а не со старого. В данному случаи мы будем запускать утилиту с директории где у нас развернут кластер базы данных 14 версии.

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

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

$. /app/postgresql/14/pghome/bin/pg_upgrade -b /app/postgresql/13/pghome/bin -B /app/postgresql/14/pghome/bin -d /app/postgresql/13/pgdata -D /app/postgresql/14/pgdata --check

Описания параметров:

  • -b - Путь до директории с исполняемыми файлами старой версии PostgreSQL.
  • -B - Путь до директории с исполняемыми файлами новой версии PostgreSQL.
  • -d - Путь до директории где хранятся все файлы старого кластера базы данных.
  • -D - Путь до директории где хранятся все файлы нового кластера базы данных.
  • --check - проверить кластеры на совместимость между собой, изменять никакие данные не будет.

 

В результате проверки вы должны получить такой ответ:

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 user-defined encoding conversions              ok
Checking for user-defined postfix operators                 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 upgrade

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


 

6. Останавливаем старый кластер.

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

$. /app/postgresql/13/pghome/bin/pg_ctl stop


 

7. Обновляем кластер простым методом.

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

Для запуска обычного обновления выполните команду:

$. /app/postgresql/14/pghome/bin/pg_upgrade -b /app/postgresql/13/pghome/bin -B /app/postgresql/14/pghome/bin -d /app/postgresql/13/pgdata -D /app/postgresql/14/pgdata

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

Performing Consistency Checks
-----------------------------
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 user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            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

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_xact to new server                           ok
Setting oldest XID for new cluster                          ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
                                                            ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to delete old cluster                       ok
Checking for extension updates                              ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
    /app/postgresql/14/pghome/bin/vacuumdb --all --analyze-in-stages

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

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


 

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

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

$. /app/postgresql/14/pghome/bin/pg_ctl start

postgresql upgrade

Как видим в результате кластер у нам успешно запустился и версия нашего кластера теперь 14.0 вместо 13.0


 

9. Итоги.

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


 

Всем спасибо, я надеюсь что вам моя статья хоть чем-то помогла.

ПОХОЖИЕ СТАТЬИ

PostgreSQL как установить часовый пояс Time Zone
Postgresql - Список пользователей
PostgreSQL изменить порт подключения 5432
Скачать и установить Postgresql 14 на Linux CentOS/RHEL 8/7 TAR