Пошук уроків, статей та іншого контенту
Створюватимете логічні копії через pg_dump і відновлюватимете їх за допомогою pg_restore з потрібними параметрами.
pg_dump і pg_restorepg_dump створює логічну копію однієї бази даних PostgreSQL. Така копія містить SQL-команди або спеціальний архів із визначеннями об’єктів і даними:
таблиці та їхні дані;
схеми;
індекси;
обмеження;
послідовності;
функції та тригери;
права доступу до об’єктів.
pg_restore відновлює базу даних зі спеціальних форматів архіву, створених pg_dump.
Логічна копія не є побайтовою копією файлів PostgreSQL. Вона переносить структуру та дані, тому може використовуватися для:
перенесення бази між серверами;
створення тестової копії;
резервного копіювання;
відновлення окремих схем або таблиць.
pg_dump підтримує кілька форматів.
Формат за замовчуванням — звичайний SQL-файл:
pg_dump -U app_user -h localhost -d app_db > app_db.sqlТакий файл можна переглянути текстовим редактором і виконати через psql:
psql -U app_user -h localhost -d app_db_test -f app_db.sqlДля plain SQL не використовується pg_restore. Відновлення виконується командою psql.
Custom-формат створюється параметром -Fc:
pg_dump -U app_user -h localhost -d app_db \
--format=custom \
--file=app_db.dumpЦей формат зручний, коли потрібно:
відновити лише окремі таблиці;
відновити тільки схему або тільки дані;
змінити порядок відновлення;
використовувати паралельне відновлення.
Для custom-архіву використовується pg_restore.
Directory-формат зберігається в каталозі:
pg_dump -U app_user -h localhost -d app_db \
--format=directory \
--file=app_db_backupЦей формат особливо корисний для паралельного створення дампу:
pg_dump -U app_user -h localhost -d app_db \
--format=directory \
--jobs=4 \
--file=app_db_backupПараметр --jobs=4 запускає до чотирьох паралельних процесів. Паралельний дамп підтримується для directory-формату.
Загальний синтаксис:
pg_dump [параметри] --dbname=назва_базиПідключення можна описати окремими параметрами:
pg_dump \
--host=localhost \
--port=5432 \
--username=app_user \
--dbname=app_db \
--format=custom \
--file=app_db.dumpАбо використати рядок підключення:
pg_dump \
"postgresql://app_user@localhost:5432/app_db" \
--format=custom \
--file=app_db.dumpЯкщо PostgreSQL вимагає пароль, утиліта запитає його в інтерактивному режимі. Для автоматизованих процесів пароль зазвичай налаштовують через файл .pgpass або інший безпечний механізм секретів.
Можна створити дамп лише певної схеми:
pg_dump \
--username=app_user \
--dbname=app_db \
--format=custom \
--schema=public \
--file=public.dumpДамп окремої таблиці:
pg_dump \
--username=app_user \
--dbname=app_db \
--format=custom \
--table=public.orders \
--file=orders.dumpЯкщо таблиця має іншу схему, її потрібно вказати явно. Наприклад, orders і sales.orders — це різні об’єкти.
Лише структура:
pg_dump \
--username=app_user \
--dbname=app_db \
--schema-only \
--format=custom \
--file=app_db_schema.dumpЛише дані:
pg_dump \
--username=app_user \
--dbname=app_db \
--data-only \
--format=custom \
--file=app_db_data.dumpЦе може бути корисно, коли структуру цільової бази вже створено, а потрібно перенести тільки записи.
pg_restoreПеред відновленням у базі даних уже мають існувати ролі, які згадуються в дампі, якщо не використовуються параметри для пропуску власників і прав.
Найпростіше відновлення custom-архіву:
pg_restore \
--username=app_user \
--host=localhost \
--dbname=app_db_test \
app_db.dumpТут pg_restore підключається до app_db_test і створює в ній об’єкти з архіву.
Цільова база даних повинна існувати заздалегідь, якщо не використовується параметр
--create.
Спочатку створіть базу даних:
createdb \
--username=postgres \
--host=localhost \
app_db_testПотім виконайте відновлення:
pg_restore \
--username=postgres \
--host=localhost \
--dbname=app_db_test \
app_db.dumpКористувач, який виконує відновлення, повинен мати достатні права для створення об’єктів у цільовій базі.
Параметр --create наказує pg_restore створити базу даних, назва якої збережена в архіві:
pg_restore \
--username=postgres \
--host=localhost \
--dbname=postgres \
--create \
app_db.dumpПараметр --dbname=postgres тут означає базу для початкового підключення. Це не обов’язково база, у яку будуть відновлені дані.
Якщо база з такою назвою вже існує, --create сам по собі не замінює її. Для видалення наявних об’єктів перед відновленням можна використати --clean:
pg_restore \
--username=postgres \
--host=localhost \
--dbname=postgres \
--create \
--clean \
--if-exists \
app_db.dumpОбережно використовуйте --clean: він видаляє об’єкти, які відновлюються, і може призвести до втрати наявних даних.
Дамп може містити команди для встановлення власника об’єктів і прав доступу. Якщо відповідних ролей на новому сервері немає, відновлення може завершитися помилками.
Для пропуску команд зміни власника використовується --no-owner:
pg_restore \
--username=app_user \
--dbname=app_db_test \
--no-owner \
app_db.dumpДля пропуску команд надання та відкликання прав використовується --no-privileges або коротка форма -x:
pg_restore \
--username=app_user \
--dbname=app_db_test \
--no-owner \
--no-privileges \
app_db.dumpЦей варіант часто підходить для локального або тестового середовища, де структура ролей відрізняється від продуктивного сервера.
Паралельне відновлення доступне для custom- і directory-архівів:
pg_restore \
--username=postgres \
--dbname=app_db_test \
--jobs=4 \
app_db.dumpПараметр --jobs=4 може прискорити відновлення великих баз даних. Кількість процесів потрібно підбирати з урахуванням процесора, диска та навантаження на сервер.
Plain SQL-файл не можна відновити через pg_restore і не можна відновлювати його цим способом паралельно:
psql \
--username=postgres \
--dbname=app_db_test \
--file=app_db.sqlЗа допомогою --list можна переглянути вміст архіву:
pg_restore --list app_db.dumpУ списку будуть об’єкти, які можна вибирати для відновлення.
pg_restore \
--username=postgres \
--dbname=app_db_test \
--table=orders \
app_db.dumpЯкщо є таблиці з однаковими назвами в різних схемах, краще вказувати схему:
pg_restore \
--username=postgres \
--dbname=app_db_test \
--table=public.orders \
app_db.dumppg_restore \
--username=postgres \
--dbname=app_db_test \
--schema=reporting \
app_db.dumpЛише структура:
pg_restore \
--username=postgres \
--dbname=app_db_test \
--schema-only \
app_db.dumpЛише дані:
pg_restore \
--username=postgres \
--dbname=app_db_test \
--data-only \
app_db.dumpЯкщо відновлюються лише дані, цільова структура таблиць уже повинна відповідати дампу.
Нижче наведено типовий сценарій: створення custom-дампу, створення тестової бази та її відновлення.
#!/usr/bin/env bash
set -euo pipefail
SOURCE_DB="app_db"
TARGET_DB="app_db_test"
DUMP_FILE="app_db.dump"
PGHOST="localhost"
PGPORT="5432"
PGUSER="postgres"
export PGHOST PGPORT PGUSER
# Створюємо логічну копію бази у custom-форматі
pg_dump \
--dbname="$SOURCE_DB" \
--format=custom \
--file="$DUMP_FILE"
# Видаляємо тестову базу, якщо вона вже існує
dropdb \
--if-exists \
"$TARGET_DB"
# Створюємо чисту тестову базу
createdb \
"$TARGET_DB"
# Відновлюємо структуру та дані без прив’язки до власників
pg_restore \
--dbname="$TARGET_DB" \
--no-owner \
--no-privileges \
"$DUMP_FILE"
# Перевіряємо кількість таблиць у тестовій базі
psql \
--dbname="$TARGET_DB" \
--command="SELECT count(*) FROM information_schema.tables WHERE table_schema NOT IN ('pg_catalog', 'information_schema');"Змінні PGHOST, PGPORT і PGUSER використовуються клієнтськими утилітами PostgreSQL для параметрів підключення. Пароль у цей сценарій не записується.
pg_restore аналізує залежності між об’єктами та намагається відновити їх у правильному порядку. Типовий процес має такі етапи:
створення схем;
створення таблиць;
завантаження даних;
створення індексів;
створення обмежень;
створення тригерів і додаткових об’єктів;
застосування прав доступу.
Для великих баз це одна з причин використовувати custom- або directory-формат замість plain SQL.
pg_dump копіює об’єкти конкретної бази даних, але не створює ролі сервера та інші глобальні об’єкти кластера.
Якщо дамп використовує власника app_owner, роль app_owner має існувати на цільовому сервері. Глобальні об’єкти можна окремо зберегти за допомогою pg_dumpall:
pg_dumpall \
--username=postgres \
--globals-only \
> globals.sqlПісля створення ролей цей файл можна виконати через psql:
psql \
--username=postgres \
--dbname=postgres \
--file=globals.sqlНе передавайте файл із ролями неперевіреним користувачам: він може містити конфіденційні дані, зокрема хеші паролів.
Успішне завершення команди не замінює перевірку відновленої бази. Після відновлення варто:
перевірити наявність потрібних схем і таблиць;
порівняти кількість записів у ключових таблицях;
перевірити індекси та обмеження;
виконати критичні запити застосунку;
перевірити доступ користувачів;
переглянути повідомлення про помилки під час відновлення.
Для перевірки кількості рядків у таблиці:
psql \
--username=postgres \
--dbname=app_db_test \
--command="SELECT count(*) FROM public.orders;"pg_restore для SQL-файлуЯкщо дамп створено без --format=custom, це plain SQL. Його потрібно відновлювати через psql:
psql --dbname=app_db_test --file=app_db.sqlБез --create база даних для відновлення повинна існувати:
createdb app_db_test
pg_restore --dbname=app_db_test app_db.dumpЯкщо в дампі є власник, якого немає на цільовому сервері, використайте --no-owner або спочатку створіть необхідні ролі.
Користувач для відновлення може не мати прав на створення схем, таблиць, функцій або розширень. Для адміністративного відновлення часто використовують роль із відповідними привілеями, але не слід без потреби надавати надмірні права прикладному користувачу.
Якщо цільова база вже містить таблиці, можуть виникнути помилки на кшталт already exists. Для контрольованого очищення використовуйте --clean --if-exists або відновлюйте в нову базу.
Дамп із --data-only не створює таблиці. Перед його використанням структура бази повинна бути підготовлена.
Перевіряйте хост, порт, користувача та назву бази:
pg_restore \
--host=localhost \
--port=5432 \
--username=postgres \
--dbname=app_db_test \
app_db.dumpДля створення дампу бажано використовувати pg_dump тієї самої або новішої основної версії, ніж версія сервера призначення. Перед перенесенням між різними версіями PostgreSQL перевіряйте сумісність і тестуйте відновлення окремо.
pg_dump створює логічну копію однієї бази даних.
Plain SQL відновлюється через psql.
Custom- і directory-архіви відновлюються через pg_restore.
--schema-only зберігає структуру, а --data-only — лише дані.
--clean видаляє наявні об’єкти перед відновленням, тому його потрібно використовувати обережно.
--no-owner і --no-privileges допомагають відновлювати базу в середовищі з іншими ролями та правами.
Параметр --jobs дає змогу виконувати паралельне створення або відновлення архівів у відповідних форматах.
Ролі та інші глобальні об’єкти не входять до звичайного дампу бази й за потреби зберігаються окремо.