Як оновити базу даних PostgreSQL - pg_upgrade
Колеги всім привіт.
У сьогоднішній статті ми поговоримо про те, як оновити кластер бази даних PostgreSQL до останньої версії за допомогою утиліти pg_upgrade. Оновлення будемо проводити з 13 версії на 14.
Рано чи пізно ви зіткнетеся з такою проблемою як оновити базу даних PostgreSQL до останньої версії. Оновлювати базу даних є дуже важливим і затребуваним завданням у житті адміністратора баз даних, оскільки розробники СУБД PostgrSQL з кожною новою версією усувають різні проблеми з продуктивністю та безпекою, а також додають нові функції.
Оновити базу даних можна двома способами.
Перший спосіб полягає в тому, щоб спочатку зробити резервну копію всієї бази даних за допомогою утиліти pg_dump або pg_dumpall, потім видалити стару базу даних і замість старої розгорнути нову, і тільки після тими ж утилітами pg_dump або pg_dumpall відновити резервну копію нову СУБД PostgreSQL. Цей спосіб відмінно підходить у тому випадку, якщо у вас розмір вашої бази даних не дуже великий у розмірах, а то якщо у вас розмір бази даних перевищує 100 гігабайт, то на оновлення піде дуже багато часу.
Другий спосіб полягає в тому, щоб використовувати утиліту pg_upgrade. Утиліта pg_upgrade дозволяє оновлювати базу даних без створення резервних копій та відновлення цих копій утилітами pg_dump або pg_dumpall. 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. Попередні вимоги.
Щоб вам було зрозуміло про що йдеться в даній статті, я вам дуже рекомендую подивитися статтю про те, як ми проводити установку СУБД PostgreSQL на 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 - Основний конфігураційний файл, який відповідає за всю базу даних.
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. Підсумки.
Колеги в результаті ми сьогодні успішно розглянули як можна простим способом оновити наш базар даних. Звичайно, крім простого оновлення можна ще використовувати такі методи як оновлення з використанням жорстких посилань і методом клонування, але у цих способів є один недолік. Не достатків полягає в тому, що після оновлення старий кластер бази даних приходить в непридатність, і щоб його назад запустити потрібно вносити зміни в файли даних старого кластера.
Всім дякую, я сподіваюся, що вам моя стаття хоч чимось допомогла.
