Створення резервної копії бази PostgreSQL
Ідея, що стоїть за методом дампа, полягає в генерації текстового файлу з командами SQL, які при виконанні на сервері, пересоздадут базу даних в тому ж самому стані, в якому вона була на момент створення дампа. PostgreSQL надає для цієї мети службову програму pg_dump. Базовий форма команди виглядає так:
тобто, pg_dump записує результати своєї роботи на стандартний висновок. Далі буде розглянуто як з цього можна отримати користь.
pg_dump є для PostgreSQL звичайним клієнтським додатком. Процедура резервного копіювання може виконуватися з будь-якого віддаленого комп'ютера, який має доступ до потрібної базі даних. Ця утиліта повинна мати доступ на читання всіх таблиць бази даних, резервну копію яких ви хочете зробити, так що на практиці її майже завжди потрібно запускати з правами суперкористувача СУБД.
Щоб вказати, до якого сервера повинен підключатися pg_dump, необхідно використовувати опцію командного рядка -h сервер і -p порт. За замовчуванням, як сервер вибирається localhost або той сервер, що зазначений в змінної оточення PGHOST. Схожим чином, за замовчуванням використовується порт, зазначений в змінної оточення PGPORT або, якщо змінна не задана, то порт, зазначений за замовчуванням при компіляції.
Як і будь-яке інше клієнтське додаток PostgreSQL, pg_dump за замовчуванням буде підключатися до бази даних, під користувачем, ім'я якого збігається з ім'ям поточного користувача в операційній системі. Щоб змінити користувача необхідно використовувати опцію -U, або встановити потрібне значення змінної оточення PGUSER.
Також, тільки pg_dump є методом, який буде працювати при перенесенні бази даних на іншу машинну архітектуру, наприклад, при перенесенні з 32-бітної на 64-бітну версію сервера.
Дампи, створювані pg_dump є внутрішньо цілісними, що означає, що дамп являє собою знімок бази даних на момент початку запуску pg_dump. pg_dump не блокує інші операції з базою даних під час своєї роботи.
Якщо схема бази даних покладається на OID (наприклад, як зовнішні ключі), ви повинні сказати pg_dump, щоб в дамп були також включені OID. Щоб зробити це, використовуйте опцію командного рядка -o.
Команда pg_dump може зберігати резервну копію бази в двох форматах: в форматі текстових файлів, що містять набір команд SQL і спеціальний формат дампа. Якщо PostgreSQL була скомпільована в системі зі встановленою бібліотекою zlib, то спеціальний формат дампа буде стискати дані, які видаються в файл виводу. Це призведе до створення файлу дампа, який за розміром буде схожий на дамп, стиснений gzip, але такий формат буде мати перевагу, тому що дозволяє вибіркове відновлення таблиць. Наступна команда робить дамп бази даних, використовуючи спеціальний формат дампа:
В принципі можна стиснути і текстовий формат резервної копії використовуючи стандартні інструменти Linux - ипользовать програму стиснення, наприклад gzip:
розпаковуючи згодом стислий дамп командою:
При великих базах даних і небажанні використовувати стиснення можна використовувати команду split. Команда split дозволяє розбивати текстові файли на файли меншого розміру, які не потрапляють під обмеження на максимальний розмір файлу в файлової системі. Наприклад, щоб нарізати дамп на шматочки по 1 мегабайту:
Завантажуючи згодом отримані файли командою:
Відновлення резервних копій баз PostgreSQL
Текстові файли резервних копій баз даних PostgreSQL, що містять команди sql, призначаються для подальшого читання програмою psql, тобто виконання згенерувала скриптів. Загальний вигляд команди для відновлення дампа:
де файл_дампа - це файл, який містить висновок команди pg_dump. База даних, задана параметром імя_БД не буде створена даною командою, так що її необхідно попередньо створити з шаблону бази template0 перед запуском psql, наприклад, за допомогою команди:
psql підтримує опції для вказівки сервера, до якого здійснюється підключення і імені користувача, схожі на pg_dump.
Перед відновленням SQL дампа, всі користувачі, які володіють об'єктами або мають права на об'єкти в базі даних, вивантажених в дамп, повинні вже існувати. Якщо їх немає, при відновленні будуть помилки пересозданія об'єктів з оригінальними власниками та / або правами.
За замовчуванням, якщо станеться помилка SQL, програма psql продовжить своє виконання. Можна запустити psql з встановленої змінної ON_ERROR_STOP, щоб змусити psql в разі виникнення помилки SQL завершити роботу з кодом 3:
У будь-якому випадку база даних буде тільки частково відновлена. В якості альтернативи можна задати, що-б весь дамп повинен бути відновлений в одній транзаціі, так що відновлення або буде повністю виконане або повністю не виконано. Даний режим може бути заданий, за допомогою опцій командного рядка -1 або -single-transaction для psql.
Дампи, які робить pg_dump є відносними template0. Це означає, що будь-які мови, процедури і т.д. додані через template1, також потраплять в дамп при виконанні pg_dump. У підсумку, при відновленні, якщо ви використовували спеціально змінений template1, ви повинні створити порожню базу даних з template0, як показано в прикладі вище.
Після відновлення резервної копії, дуже рекомендується запустити ANALYZE на кожну базу даних для того, щоб оптимізатор запитів отримав потрібну статистику.
Спеціальний формат дампа не є скриптом для psql і повинен відновлюватися за допомогою команди pg_restore, наприклад:
Для дуже великих баз даних, вам може знадобитися поєднувати split з одним з двох інших методів.
pg_dump робить дамп тільки однієї бази даних і не включає в дамп інформацію про ролі або табличних просторах (бо ці дані відносяться скоріше до рівня кластера, ніж до самої бази даних). Для створення резервної копії всього вмісту кластера баз даних, існує програма pg_dumpall. pg_dumpall робить резервну копію кожної бази даних кластера, а також службові дані рівня кластера, такі як ролі і визначення табличних просторів. Базова форма використання цієї команди:
Результуючий дамп може бути відновлений за допомогою psql:
При відновленні дампа, зробленого pg_dumpall, завжди необхідно, виконувати відновлення з правами суперкористувача баз даних, тому що вони потрібні для відновлення ролей та інформації про таблиць.
Ще по темі PostgreSQL