Как сделать резервную копию и восстановить базы данных PostgreSQL

1. Дамп Использование pg_dump и pg_dumpall
2. Восстановление из файла дампа SQL
3. Резервное копирование с помощью pg_basebackup
4. Восстановление из файлов pg_basebackup
5. Инкрементное и непрерывное резервное копирование
6. Восстановление на момент времени (PITR)
7. Мониторинг резервных копий
8. Новенький тут?

Наша взаимовыгодная связь https://banwar.org/

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

Давайте посмотрим на общие параметры резервного копирования и восстановления.

Дамп Использование pg_dump и pg_dumpall

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

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

Это, однако, мощно в других аспектах:

• Вы можете подключиться как обычный пользователь с правами только для чтения для всех соответствующих объектов.
• Вы можете выборочно восстановить объекты из дампа (используя пользовательский формат)
• Вы можете вручную редактировать и настраивать SQL перед восстановлением (используя формат SQL)

pg_dump может создавать дампы как простые файлы SQL, как архив tar, как каталог с набором файлов или как отдельный файл, называемый файлом нестандартного формата. Из них наиболее интересными являются файл SQL и файл пользовательского формата.

pg_dump вызывается так:

# дамп в один файл SQL $ pg_dump -d mydb -n public -f mydb.sql # дамп в файл пользовательского формата $ pg_dump -d mydb -n public --format = custom -f mydb.pgdmp

Обратите внимание, что мы выгружаем только объекты из публичной схемы. Как правило, это то, что вы хотите.

Файл mydb.sql представляет собой простой текстовый файл с командами PostgreSQL, а файл mydb.pgdmp - это файл пользовательского формата. Обратите внимание, что файл нестандартного формата сжат gzip, и его не нужно снова сжимать.

Документы PostgreSQL имеют больше информации обо всех опциях для pg_dump а также pg_dumpall ,

Восстановление из файла дампа SQL

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

# восстановление из файла дампа SQL, простая версия $ psql -d mydb_new <mydb.sql # восстановление из файла дампа SQL, рекомендуемая версия $ PGOPTIONS = '--client-min-messages = warning' psql -X -q -1 -v ON_ERROR_STOP = 1 --pset pager = off -d mydb_new -f mydb.sql -L restore.log

Читайте обо всех опциях psql Вот ,

Допустим, кто-то случайно уронил стол, и вы хотите восстановить только этот стол. Восстановление из файла pg_dump пользовательского формата - самый простой способ сделать это.

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

# восстановление из дампа, записанного в файл пользовательского формата $ pg_restore -d mydb_new -v -1 mydb.pgdmp # восстановление одной таблицы из дампа $ pg_restore -d mydb_new --table = mytable -v -1 mydb.pgdmp # restore единственная функция из дампа $ pg_restore -d mydb_new --function = myfunc -v -1 mydb.pgdmp

Вы можете прочитать больше о pg_restore Вот ,

Резервное копирование с помощью pg_basebackup

Инструмент pg_basebackup - это стандартный способ создания полной резервной копии на уровне файловой системы кластера баз данных PostgreSQL. (Здесь кластер относится к использованию термина Postgres, то есть всех баз данных, управляемых одним серверным процессом.)

Pg_basebackup устанавливает соединение по протоколу репликации (как и клиент репликации) с сервером PostgreSQL и создает двоичную копию файлов данных, которые находятся в каталоге $ PGDATA сервера. Копия, которую он создает, является непротиворечивой - файлы точно соответствуют состоянию в конце определенной транзакции.

Это также подразумевает, что pg_basebackup должен подключаться как пользователь, которому явно разрешено использовать протокол репликации. Вы можете сделать это, добавив строки в pg_hba.conf, похожие на:

# ТИП БАЗЫ ДАННЫХ МЕТОД АДРЕСА ПОЛЬЗОВАТЕЛЯ локальная репликация myuser peer host репликация myuser 10.0.0.1/32 md5

Если вас беспокоит отсутствие транзакций, происходящих во время резервного копирования, вы можете попросить pg_basebackup извлечь и включить эти файлы журнала транзакций (файлы WAL), используя опции -x или -X.

# создать резервную копию в виде стандартных файлов Postgres в / path / to / datadir $ pg_basebackup -D / path / to / datadir # создать резервную копию файла tar.gz для каждого табличного пространства в / path / to / dir $ pg_basebackup --format = tar -z -D / path / to / dir -P # также включает транзакции, поскольку резервное копирование началось $ pg_basebackup -x -D / path / to / datadir

pg_basebackup docs имеет больше деталей.

Восстановление из файлов pg_basebackup

Файлы, созданные pg_basebackup, являются точным, непротиворечивым зеркалом файлов в $ PGDATA (обычно это похоже на /var/lib/postgresql/9.6/main). Восстановление включает в себя только перемещение этих файлов в подходящее место, например так:

$ sudo systemctl stop postgresql $ sudo rm -rf /var/lib/postgresql/9.6/main/ * $ sudo -u postgres tar -xvC /var/lib/postgresql/9.6/main -f / path / to / dumpdir / base .tar.gz $ sudo systemctl start postgresql

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

Узнайте, как вы можете использовать функцию потоковой репликации, чтобы сделать это в нашем Все о PostgreSQL Потоковая Репликация сообщение в блоге ,

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

Инкрементное и непрерывное резервное копирование

Сервер PostgreSQL генерирует поток файлов журнала изменений, называемых файлами WAL (Write Ahead Log). Архивируя эти файлы по мере их создания, вы можете создать систему инкрементного непрерывного резервного копирования.

Вы можете прочитать больше об архивации WAL в этом Все об архивации WAL в посте PostgreSQL ,

Как правило, полное резервное копирование выполняется периодически вместе с непрерывным архивированием WAL. Вместе они позволяют восстановить данные на определенный момент времени.

Восстановление на момент времени (PITR)

PITR означает восстановление кластера PostgreSQL до состояния, в котором он находился в определенный момент времени.

Например, скажем, что-то радикальное произошло в 11:20, и вы хотели бы восстановить базы данных до состояния, которое было незадолго до 11:20. Предположим, вы делаете ежедневные резервные копии каждый день в 01:00 и используете непрерывное архивирование WAL. Вы можете выполнить следующие действия:

• остановить постгрес
• восстановить последнюю полную резервную копию, сделанную в 01:00
• смонтировать файловую систему с архивными файлами WAL
• создайте файл $ PGDATA / recovery.conf, содержащий содержимое:

restore_command = 'cp / path / to / archive /% f "% p"' recovery_target_time = '2017-02-08 11:20:00 UTC' recovery_target_inclusive = false

Затем запустите сервер Postgres. При запуске он будет неоднократно вызывать сценарий restore_command для извлечения файлов WAL с 01:00, но не включая 11:20. В этот момент он завершает фазу восстановления и начинает нормальную работу.

Вы можете прочитать больше о PITR в PostgreSQL документы ,

Мониторинг резервных копий

Недостаточно просто добавлять задания cron для резервного копирования, вам также нужно следить за ними!

Обязательно следите за:

• успешно ли завершаются задания резервного копирования
• время, затрачиваемое на каждую резервную копию, и следите за тем, как это происходит

Кроме того, у вас также должно быть другое задание cron, которое берет последнюю резервную копию и пытается восстановить ее в пустую базу данных, а затем удаляет базу данных. Это гарантирует, что ваши резервные копии доступны и пригодны для использования. Убедитесь, что вы пытаетесь восстановить правильные версии вашего сервера PostgreSQL.

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

С OpsDash вы можете быстро начать мониторинг ваших серверов PostgreSQL и мгновенно получить представление о ключевых показателях производительности и работоспособности, включая архивирование WAL и потоковую репликацию.

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

На панели инструментов ниже показана задержка потоковой репликации и состояние архивации WAL для сервера:

Новенький тут?

OpsDash - это решение для мониторинга серверов, сервисов и баз данных для мониторинга MySQL, PostgreSQL, MongoDB, memcache, Redis, Apache, Nginx, HTTP URL, Elasticsearch и многих других. Он предоставляет интеллектуальные настраиваемые панели мониторинга и оповещения без спама по электронной почте, HipChat, Slack, PagerDuty и PushBullet.