Postgresql документація 9

Ідея, що стоїть за цим методом, полягає в генерації текстового файлу з командами SQL, які при виконанні на сервері пересоздадут базу даних в тому ж самому стані, в якому вона була на момент вивантаження. PostgreSQL надає для цієї мети допоміжну програму pg_dump. Найпростіше застосування цієї програми виглядає так:

Як бачите, pg_dump записує результати своєї роботи в пристрій стандартного виведення. Далі буде розглянуто, ніж це може бути корисно. У той час як вищезгадана команда створює текстовий файл, pg_dump може створити файли і в інших форматах, які допускають паралельну обробку і більш гнучке управління відновленням об'єктів.

Програма pg_dump є для PostgreSQL звичайним клієнтським додатком (хоча і вельми розумною). Це означає, що ви можете виконувати процедуру резервного копіювання з будь-якого віддаленого комп'ютера, якщо маєте доступ до потрібної базі даних. Але пам'ятайте, що pg_dump не використовує для своєї роботи якісь спеціальні привілеї. Зокрема, їй зазвичай потрібен доступ на читання всіх таблиць, які ви хочете вивантажити, так що для копіювання всієї бази даних практично завжди її потрібно запускати з правами суперкористувача СУБД. (Якщо у вас немає достатніх прав для резервного копіювання всієї бази даних, ви, тим не менш, можете зробити резервну копію тієї частини бази, доступ до якої у вас є, використовуючи такі параметри, як -n схема або -t таблиця.)

Вказати, до якого сервера повинна підключатися програма pg_dump. можна за допомогою аргументів командного рядка -h сервер і -p порт. За замовчуванням в якості сервера вибирається localhost або значення, вказане в змінної оточення PGHOST. Подібним чином, за замовчуванням використовується порт, заданий у змінній оточення PGPORT. а коли її не вказано, то порт, зазначений за замовчуванням при компіляції. (Для зручності при компіляції сервера зазвичай встановлюється те ж значення за замовчуванням.)

Як і будь-яке інше клієнтське додаток PostgreSQL. pg_dump за замовчуванням буде підключатися до бази даних з ім'ям користувача, що збігається з ім'ям поточного користувача операційної системи. Щоб перевизначити ім'я, або додайте параметр -U. або встановіть змінну середовища PGUSER. Пам'ятайте, що pg_dump підключається до сервера через звичайні механізми перевірки автентичності клієнта (які описуються в Главі 19).

Важлива перевага pg_dump в порівнянні з іншими методами резервного копіювання, описаними далі, полягає в тому, що висновок pg_dump зазвичай можна завантажити в більш нові версії PostgreSQL. в той час як резервна копія на рівні файлової системи і безперервне архівування жорстко залежать від версії сервера. Також, тільки метод із застосуванням pg_dump буде працювати при перенесенні бази даних на іншу машинну архітектуру, наприклад, при перенесенні з 32-бітної на 64-бітну версію сервера.

Дампи, створювані pg_dump. є внутрішньо узгодженими, тобто, дамп являє собою знімок бази даних на момент початку запуску pg_dump. pg_dump не блокує інші операції з базою даних під час своєї роботи. (Виняток становлять операції, яким потрібна виняткова блокування, як наприклад, більшість форм команди ALTER TABLE.)

Текстові файли, створені pg_dump призначаються для подальшого читання програмою psql. Загальний вигляд команди для відновлення дампа:

де вхідний_файл - це файл, який містить висновок команди pg_dump. База даних, задана параметром імя_бази. не буде створена даною командою, так що ви повинні створити її самі з бази template0 перед запуском psql (наприклад, за допомогою команди createdb -T template0 імя_бази). Програма psql приймає параметри, що вказують сервер, до якого здійснюється підключення, і ім'я користувача, подібно pg_dump. За додатковими відомостями зверніться до довідки по pg_restore. Копія не текстові відновлюються утилітою pg_restore.

Перед відновленням SQL-дампа всі користувачі, які володіли об'єктами або мали права на об'єкти в вивантажених базі даних, повинні вже існувати. Якщо їх немає, при відновленні будуть помилки пересозданія об'єктів з початковими власниками та / або правами. (Іноді це бажаний результат, але зазвичай немає).

За замовчуванням, якщо відбувається помилка SQL, програма psql продовжує виконання. Якщо ж запустити psql з встановленої змінної ON_ERROR_STOP. це поведінка зміниться і psql завершиться з кодом 3 в разі виникнення помилки SQL:

У будь-якому випадку, ви отримаєте тільки частково відновлену базу даних. В якості альтернативи можна вказати, що весь дамп повинен бути відновлений в одній транзакції, так що відновлення або повністю виконається, або повністю скасується. Включити даний режим можна, передавши psql аргумент -1 або --single-transaction. Вибираючи цей режим, врахуйте, що навіть незначна помилка може призвести до відкату відновлення, яке могло тривати кілька годин. Однак, це все ж може бути краще, ніж вручну вичищати складну базу даних після частково відновленого дампа.

Важливо: Дампи, які видає pg_dump. містять визначення щодо template0. Це означає, що будь-які мови, процедури і т. П. Додані в базу через template1. pg_dump також вивантажить в дамп. Як наслідок, якщо при відновленні ви використовуєте модифікований template1. ви повинні створити порожню базу даних з template0. як показано в прикладі вище.

Після відновлення резервної копії має сенс запустити ANALYZE для кожної бази даних, щоб оптимізатор запитів отримав корисну статистику; за подробицями зверніться до Підрозділу 23.1.3 і Підрозділу 23.1.6. Інші поради щодо ефективної завантаженні великих обсягів даних в PostgreSQL ви можете знайти в Розділі 14.4.

Програма pg_dump вивантажує тільки одну базу даних в один момент часу і не включає в дамп інформацію про ролі та табличних просторах (так як це інформація рівня кластера, а не самої бази даних). Для зручності створення дампа всього вмісту кластера баз даних надається програма pg_dumpall. яка робить резервну копію всіх баз даних кластера, а також зберігає дані рівня кластера, такі як ролі і визначення табличних просторів. Просте використання цієї команди:

Отриману копію можна відновити за допомогою psql.

(В принципі, тут в якості початкової бази даних можна вказати ім'я будь-якої існуючої бази, але якщо ви завантажуєте копію в порожній кластер, зазвичай потрібно використовувати postgres). Відновлювати дамп, який видала pg_dumpall. завжди необхідно з правами суперкористувача, так як вони потрібні для відновлення інформації про ролях і табличних просторах. Якщо ви використовуєте табличні простору, переконайтеся, що шляхи до табличних просторів в дампі відповідають новому середовищі.

pg_dumpall видає команди, які заново створюють ролі, табличні простору і порожні бази даних, а потім викликає для кожної бази pg_dump. Таким чином, хоча кожна база даних буде внутрішньо узгодженої, стан різних баз не буде синхронним.

Тільки глобальні дані кластера можна вивантажити, передавши pg_dumpall ключ --globals-only. Це необхідно, щоб повністю скопіювати кластер, коли pg_dump виконується для окремих баз даних.

Деякі операційні системи накладають обмеження на максимальний розмір файлу, що призводить до проблем при створенні великих файлів за допомогою pg_dump. На щастя, pg_dump може писати в стандартний висновок, так що ви можете використовувати стандартні інструменти Unix для того, щоб уникнути потенційних проблем. Ось кілька можливих методів:

Використовуйте стислі дампи. Ви можете використовувати бажану програму стиснення, наприклад gzip.

Потім завантажити стиснений дамп можна командою:

Використовуйте split. Команда split може розбивати виведені дані на невеликі файли, розмір яких задовольняє обмеження нижележащей файлової системи. Наприклад, щоб отримати частини по 1 мегабайту:

Відновити їх можна так:

Використовуйте спеціальний формат дампа pg_dump. Якщо при складанні PostgreSQL була підключена бібліотека zlib. дамп в спеціальному форматі буде записуватися в файл в стислому вигляді. В такому форматі розмір файлу дампа буде близький до розміру, отриманого з застосуванням gzip. але він краще тим, що дозволяє відновлювати таблиці вибірково. Наступна команда вивантажує базу даних в спеціальному форматі:

Дамп в спеціальному форматі не є скриптом для psql і повинен відновлюватися за допомогою команди pg_restore. наприклад:

За подробицями зверніться до довідки по командам pg_dump і pg_restore.

Для дуже великих баз даних може знадобитися поєднувати split з одним з двох інших методів.

Використовуйте можливість паралельної вивантаження в pg_dump. Щоб прискорити вивантаження великий БД, ви можете використовувати режим паралельної вивантаження в pg_dump. При цьому одночасно будуть розвантажуватися кілька таблиць. Управляти числом паралельних завдань дозволяє параметр -j. Паралельна вивантаження підтримується лише для формату архіву в каталозі.

Ви також можете відновити копію в паралельному режимі з допомогою pg_restore -j. Це підтримується для будь-якого архіву в форматі каталогу або спеціальному форматі, навіть якщо архів створювався не командує pg_dump -j.