Как перенести базу данных postgresql на другой компьютер
Перейти к содержимому

Как перенести базу данных postgresql на другой компьютер

  • автор:

Как перенести базу данных postgresql на другой компьютер

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. PostgreSQL предоставляет для этой цели вспомогательную программу pg_dump . Простейшее применение этой программы выглядит так:

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 .)

24.1.1. Восстановление дампа

Текстовые файлы, созданные pg_dump , предназначаются для последующего чтения программой psql . Общий вид команды для восстановления дампа:

psql имя_базы < файл_дампа 

где файл_дампа — это файл, содержащий вывод команды pg_dump . База данных, заданная параметром имя_базы , не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы ). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump . За дополнительными сведениями обратитесь к справке по psql . Дампы, выгруженные не в текстовом формате, восстанавливаются утилитой pg_restore .

Перед восстановлением SQL-дампа все пользователи, которые владели объектами или имели права на объекты в выгруженной базе данных, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с изначальными владельцами и/или правами. (Иногда это желаемый результат, но обычно нет).

По умолчанию, если происходит ошибка SQL, программа psql продолжает выполнение. Если же запустить psql с установленной переменной ON_ERROR_STOP , это поведение поменяется и psql завершится с кодом 3 в случае возникновения ошибки SQL:

psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

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

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно

Дампы, которые выдаёт pg_dump , содержат определения относительно template0 . Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1 , pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1 , вы должны создать пустую базу данных из template0 , как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 23.1.3 и Подразделу 23.1.6. Другие советы по эффективной загрузке больших объёмов данных в PostgreSQL вы можете найти в Разделе 14.4.

24.1.2. Использование pg_dumpall

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

pg_dumpall > файл_дампа 

Полученную копию можно восстановить с помощью psql :

psql -f файл_дампа postgres

(В принципе, здесь в качестве начальной базы данных можно указать имя любой существующей базы, но если вы загружаете дамп в пустой кластер, обычно нужно использовать postgres ). Восстанавливать дамп, который выдала pg_dumpall , всегда необходимо с правами суперпользователя, так как они требуются для восстановления информации о ролях и табличных пространствах. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой среде.

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump . Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

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

24.1.3. Управление большими базами данных

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

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip :

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы
cat имя_файла.gz | gunzip | psql имя_базы

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

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

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

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore , например:

pg_restore -d имя_базы имя_файла

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

Для очень больших баз данных может понадобиться сочетать split с одним из двух других методов.

Используйте возможность параллельной выгрузки в pg_dump . Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump . При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j . Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

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

Пред. Наверх След.
Глава 24. Резервное копирование и восстановление Начало 24.2. Резервное копирование на уровне файлов

Как перенести базу данных PostgreSQL на другой сервер с помощью pgAdmin 4

Всем привет! Сегодня мы рассмотрим процесс переноса базы данных PostgreSQL с одного сервера на другой, например, с компьютера разработчика на production-сервер, при этом мы будем использовать графический инструмент pgAdmin 4.

Перенос базы данных PostgreSQL на другой сервер с помощью pgAdmin 4

Исходные данные. Задача

Допустим, мы разрабатываем базу данных в PostgreSQL, при этом мы используем обычный клиентский компьютер под управлением операционной системы Windows 10, где собственно локально и установлен PostgreSQL.

В качестве инструмента разработки мы используем стандартное графическое приложение pgAdmin 4.

pgAdmin 4 – это стандартный и бесплатный графический инструмент для разработки баз данных в PostgreSQL, который можно использовать для написания SQL запросов, разработки процедур, функций, а также для выполнения базовых задач администрирования баз данных.

В итоге базу данных мы разработали, протестировали ее, внесли в нее необходимые данные, заполнили справочники, в общем, база данных готова.

Теперь у нас возникла необходимость перенести эту базу данных на реальный сервер, который и будет выступать в качестве сервера баз данных. И так как мы используем PostgreSQL, в качестве такого сервера баз данных обычно выступает сервер под управлением операционной системы Linux.

Таким образом, нам необходимо перенести базу данных PostgreSQL, разработанную в Windows, в базу данных PostgreSQL на Linux. В моем случае в качестве операционной системы Linux будет выступать дистрибутив Debian.

Создание дампа базы данных PostgreSQL в pgAdmin 4

Весь процесс переноса базы данных PostgreSQL достаточно простой, суть в следующем.

Нам необходимо создать копию нашей базы данных (дамп), затем создать пустую базу на нужном нам сервере и восстановить все данные, используя созданный ранее дамп.

Все это можно сделать с нашего клиентского компьютера, используя pgAdmin 4, если, конечно же, целевой сервер нам доступен, если недоступен, то придётся каким-то другим образом переносить дамп базы данных на нужный сервер и, используя стандартные консольные утилиты, восстановить базу данных из дампа.

Кстати, стоит отметить, что pgAdmin 4 для экспорта/импорта баз данных использует как раз эти стандартные консольные утилиты, в частности pg_dump, pg_dumpall и pg_restore, которые по умолчанию входят в состав PostgreSQL.

pg_dump – утилита для экспорта баз данных PostgreSQL
pg_dumpall – утилита для экспорта кластера баз данных PostgreSQL (всех данных на сервере)
pg_restore – утилита восстановления баз данных PostgreSQL из файла архива

Таким образом, благодаря pgAdmin 4 нам не нужно писать и выполнять команды в командной строке, за нас все это делает pgAdmin 4, мы всего лишь будем пользоваться мышкой, настраивая все параметры в графическом интерфейсе.

Создать дамп базы данных PostgreSQL можно в нескольких форматах, в частности:

Специальный (Custom) – это пользовательский формат, который использует сжатие. Данный формат по умолчанию предлагается в pgAdmin 4 и рекомендован для средних и больших баз данных. Обычно архивные файлы в таком формате создают с расширением backup, однако можно использовать и другое расширение.

Tar (tar) – база данных выгружается в формат tar. Данный формат не поддерживает сжатие.

Простой (plain) – в данном случае база данных выгружается в обычный текстовый SQL-скрипт, в котором все объекты базы данных и непосредственно сами данные будут в виде соответствующих SQL инструкций. Данный скрипт можно легко отредактировать в любом текстовом редакторе и выполнить, используя Query Tool, как обычные SQL запросы. Данный формат рекомендован для небольших баз данных, а также для тех случаев, когда требуется внести изменения в дамп базы данных перед восстановлением.

Каталог (directory) – этот формат файла создает каталог, в котором для каждой таблицы и большого объекта будут созданы отдельные файлы, а также файл оглавления в машиночитаемом формате, понятном для утилиты pg_restore. Этот формат по умолчанию использует сжатие, а также поддерживает работу в несколько потоков.

В данном материале мы рассмотрим создание дампа в специальном формате, а также в формате обычного SQL скрипта, дело в том, что процесс восстановления базы данных из этих форматов в pgAdmin 4 немного отличается.

Создание дампа базы данных в сжатом формате

Чтобы создать дамп базы данных PostgreSQL в pgAdmin 4, необходимо в обозревателе выбрать нужную базу данных, я выбираю базу данных shop, далее необходимо вызвать контекстное меню правой кнопкой мыши и нажать на пункт «Резервная копия».

Затем всего лишь нужно указать имя архивного файла и путь к каталогу, где его сохранить, для этого можно использовать кнопку с тремя точками.

Формат «Специальный», как было отмечено ранее, предлагается по умолчанию, поэтому выбирать его не требуется.

Как я уже отмечал, обычно архив в таком формате создают с расширением backup, я так и поступаю, т.е. архив назову shop.backup и сохраню его в каталоге D:\PostgreSQL_Backup\.

В случае необходимости задать определенный уровень сжатия можно с помощью параметра «Коэффициент сжатия», поддерживаются значения от 0 до 9, где 0 – вообще не использовать сжатие, а 9 самый высокий уровень сжатия, по умолчанию используется умеренное сжатие.

В нашем случае база данных небольшая, поэтому мы можем оставить все по умолчанию.

Больше никаких настроек в нашем случае делать нет необходимости, и мы можем нажать на кнопку «Резервная копия», чтобы запустить процесс создания дампа базы данных.

Когда появится сообщение «Успешно завершено», значит, процесс создания дампа базы данных PostgreSQL завершен успешно, в противном случае Вы будете получать сообщения о неуспешном завершении.

Скриншот 2

Создание дампа базы данных в простом формате SQL

В данном случае нам необходимо сделать практически все то же самое, только нужно выбрать формат «Простой» и дополнительно включить пару параметров, чтобы добавление данных осуществлялось с помощью обычных инструкций INSERT, а не с помощью команды COPY, которая используется по умолчанию.

Для этого переходим на вкладку «Параметры выгрузки» и включаем два параметра «Использовать команды INSERT» и «INSERT с указанием столбцов», хотя данный параметр можно и не указывать.

Заметка! Начинающим программистам рекомендую почитать мою книгу «SQL код», которая поможет Вам изучить язык SQL как стандарт, в ней рассматриваются все базовые конструкции языка SQL, приводится много примеров и скриншотов.

Импорт дампа базы данных PostgreSQL в pgAdmin 4

Дамп готов, теперь можно переходить к восстановлению базы данных из этого дампа. Однако перед тем как приступать к импорту, необходимо создать пустую базу данных, в которую собственно и импортировать все данные, как это делается, я подробно рассказывал в отдельном материале.

Все действия по созданию базы данных и восстановлению данных этой базы из архивной копии мы будем делать все на том же компьютере с помощью того же pgAdmin 4, только для этого необходимо подключиться к нужному нам серверу (пункт контекстного меню «Создать сервер» и ввести настройки для подключения, подробнее, как это делается, я рассказывал в той же статье, которая посвящена установке PostgreSQL на Debian).

Импорт сжатого дампа базы данных

Чтобы импортировать базу данных, дамп который был создан в «специальном» формате, необходимо на целевом сервере выбрать базу данных, которую требуется восстановить из дампа (мы ее предварительно создали), в контекстном меню выбрать пункт «Восстановить», затем в пункте «Имя файла», используя кнопку с тремя точками, указать файл дампа, который мы создали чуть ранее с расширением backup.

Больше никаких настроек вводить не требуется, нужный формат выбран по умолчанию, мы можем сразу нажимать кнопку «Восстановить».

Когда появится сообщение «Успешно завершено», процесс будет завершен.

Скриншот 5

В результате все данные будут восстановлены из дампа, и таким образом мы перенесли базу данных PostgreSQL на новый сервер.

Импорт дампа базы данных в формате SQL

В случае с простым форматом, т.е. с обычными SQL инструкциями, использовать отдельный функционал для восстановления не получится, поэтому мы можем просто выполнить SQL скрипт, который содержится в этом файле.

Для этого открываем Query Tool (запросник) в контексте нужной нам базы данных, затем используя кнопку «Открыть файл» выбираем наш дамп в формате SQL и нажимаем кнопку «Выполнить».

Если инструкция выполнится без ошибок, значит, все хорошо.

Примечание! Если Вы уже восстановили базу данных предыдущим способом, то, чтобы использовать этот способ, необходимо пересоздать базу данных, иначе возникнет конфликт и, соответственно, ошибка, так как все объекты в базе уже будут существовать.

В итоге мы перенесли базу данных PostgreSQL с одного сервера, который управляется операционной системой Windows, на другой, который управляется Linux, хотя это, как Вы понимаете, в нашем случае было не так принципиально.

Стоит отметить, что если требуется перенести базу данных, размер которой достаточно большой, например, несколько десятков или сотен гигабайт, то лучше напрямую использовать консольные утилиты pg_dump или pg_dumpall, т.е. без графического интерфейса pgAdmin 4.

Видео – Перенос базы данных PostgreSQL на другой сервер с помощью pgAdmin 4

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Перемещение базы данных postgresql в Ubuntu 18.04 LTS

postgresql ubuntu

При установке на Ubuntu zabbix-server база данных по умолчанию пишется в папку /var/lib/postgresql. Со временем база растёт и поднимается вопрос переноса её на другой раздел диска. Перенесём базу данных в /opt/postgresql.

Требования

  • ОС Ubuntu 18.04 LTS. Или Ubuntu 16.04.
  • Работаем из-под root.
  • Сервер PostgreSQL
  • Сервер zabbix. Не обязательно.

Подготовка

Проверим где находится текущая БД postgresql.

sudo -u postgres psql psql (9.5.14) Type "help" for help. postgres=# SHOW data_directory; data_directory ------------------------------ /var/lib/postgresql/9.5/main (1 row)

БД находится в папке /var/lib/postgresql/9.5/main.

Для переноса БД нам понадобится rsync:

apt-get install rsync

Убедимся что существует директория /opt.

Остановка сервисов

service zabbix-server stop systemctl stop postgresql

Проверка статуса postgresql.

systemctl status postgresql

Ищем строку «Stopped PostgreSQL RDBMS.»

Перенос файлов базы данных

rsync -av /var/lib/postgresql /opt

После переноса переименуем старую папку, на всякий случай:

mv /var/lib/postgresql/9.5/main /var/lib/postgresql/9.5/main.bak

Настройка конфигурации postgresql

Правим файл postgresql.conf:

vim /etc/postgresql/9.5/main/postgresql.conf

Изменяем значение data_directory:

data_directory = '/opt/postgresql/9.5/main'

Запуск сервисов

systemctl start postgresql

Проверяем где находится текущая БД postgresql.

sudo -u postgres psql psql (9.5.14) Type "help" for help. postgres=# SHOW data_directory; data_directory ------------------------------ /opt/postgresql/9.5/main (1 row)

БД находится в папке /opt/postgresql/9.5/main.

service zabbix-server start

Удаление ненужных файлов

rm -Rf /var/lib/postgresql/9.5/main.bak

Порядок действий при переходе на PostgreSQL

Данная инструкция описывает необходимые действия для начала использования ПАУ с PostgreSQL в качестве основной базы данных.

Для обеспечения правильного перехода с базы данных MS Access на систему управления базами данных PostgreSQL вам потребуется системный администратор, который обеспечит выполнение условий, содержащихся в инструкциях.

На текущий момент, переход на другую базу данных доступен для версий ПАУ начиная с 3.12.0.1 . В том случае, если сейчас используется ПАУ версии ниже чем 3.12.0.1 , то необходимо обновить ПАУ и рабочую БД до требуемой версии.

Порядок действий при переходе на PostgreSQL

  1. Скачать по ссылкеPostgreSQL 12 версии и установить на сервер или ПК, который будет выполнять роль сервера (перейти к инструкции)
  2. Скачать по ссылке и установить pgAdmin (перейти к инструкции)
  3. Подключиться к серверу СУБД PostgreSQL через pgAdmin (перейти к инструкции)
  4. Создать пустую базу данных ama (перейти к инструкции)
  5. Создать пользователя ama_user (перейти к инструкции)
  6. Установить утилиту переноса данных (перейти к инструкции)
  7. Настроить утилиту переноса данных (перейти к инструкции)
  8. Перенести данные в базу данных PostgreSQL с помощью утилиты переноса данных (перейти к инструкции)
  9. Настроить права пользователей, для работы с существующими таблицами и др. объектами (перейти к инструкции)
  10. Настроить удалённый доступ к СУБД PostgreSQL (перейти к инструкции)
  11. Скачать и установить ПАУ с поддержкой работы с СУБД PostgreSQL по ссылке
  12. Убедиться, что на каждом рабочем месте стоит версия утилиты резервного копирования СУБД PostgreSQL такая же или выше, чем версия базы PostgreSQL, к которой вы будете подключаться. Если нет, то надо обновить утилиты.
    • как проверить версию утилиты резервного копирования базы данных (перейти к инструкции);
    • как проверить версию используемой базы данных PostgreSQL (перейти к инструкции);
    • как обновить утилиты резервного копирования базы данных (перейти к инструкции);
  13. Запустить ПАУ и подключиться к базе данных PostgreSQL (перейти к инструкции)

Вопросы и ответы

Вопрос: Мы используем несколько БД при работе, как их объединить в одну?

Ответ: На данный момент такой возможности нет, в одном из ближайших релизов добавим.

Вопрос: Мы используем несколько БД при работе, как сделать так же с PostgreSQL?

Ответ: При переносе данных из базы данных MS Access в базу данных PostgreSQL необходимо в файле конфигурации в параметре pg_dbname указать наименование название БД, отличное от ama и при подключении указать его

Вопрос: Можем ли мы перейти обратно с PostgreSQL на MS Access?

Ответ: Да, для этого нужно воспользоваться утилитой переноса данных

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *