Как обновить базу данных 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 минут.
Содержание статьи:
- Предварительные требования.
- Расположения директорий.
- Файлы переменных окружений.
- Сборка и инициализация нового кластера.
- Проверка совместимости.
- Останавливаем старый кластер.
- Обновляем кластер простым методом.
- Запуск нового кластера.
- Итоги.
Синтаксис утилиты:
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
Версия СУБД версии 14 будет храниться в директории /app/postgresql/14 и хранить в себе те же три директории с одинаковыми именами.
/app/postgresql/14
/app/postgresql/14/log
/app/postgresql/14/pgdata
/app/postgresql/14/pghome
3. Файлы переменных окружений.
В домашней директории учетной записи postgres у нас должно быть создано два файла переменных окружений. Под каждую базу данных у нас будет отдельный файл с конкретными переменными которые нужны для нормальной работы самой базы данных. Называться файлы будут pgsql_13.env и pgsql_14.env. Файл pgsql_13.env будет относиться в базе данных версии 13, а файл pgsql_14.env будет относиться к версии базы данных 14. Содержимое каждого из файлов будет показано ниже.
Файл 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*
Если у вас в результате будет хоть одна ошибка, то обновить кластер не получится, пока вы эту ошибку не исправите.
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
Как видим в результате кластер у нам успешно запустился и версия нашего кластера теперь 14.0 вместо 13.0
9. Итоги.
Коллеги в итоге мы сегодня успешно рассмотрели как можно простым способом обновить наш кластер базы данных. Конечно помимо простого обновления можно еще использовать такие методы как обновления с использованием жестких ссылок и методом клонирования, но у этих способов есть один не достаток. Не достатков заключается в том что после обновления старый кластер базы данных приходит в негодность, и чтобы его обратно запустить то нужно вносить изменения в файлы данных старого кластера.
Всем спасибо, я надеюсь что вам моя статья хоть чем-то помогла.