Резервное копирование и восстановление
В этом разделе приведен обзор способов резервного копирования и восстановления данных, хранящихся в кластере Greengage DB (на основе Greenplum).
Обзор
Резервное копирование и восстановление — важная функциональность любой СУБД. Она обеспечивает возможность восстановления данных в случае отказа оборудования, проблем с ПО или случайного удаления данных. Кроме того, бэкапы базы данных необходимы для таких эксплуатационных сценариев, как:
-
сохранение исторических данных;
-
восстановление на определенный момент времени или воссоздание кластера из снимка;
-
реализация стратегии отката при обновлениях компонентов или изменениях схемы.
Бэкапы также используются для миграции данных, например:
-
между двумя кластерами Greengage DB: из тестовой среды в производственную или при переносе баз на новое оборудование;
-
между разными системами: загрузка данных из Greengage DB в другую PostgreSQL-совместимую систему или наоборот.
Логические и физические бэкапы
Способы резервного копирования, описанные в этом разделе, создают логические бэкапы баз данных Greengage DB. В отличие от физических бэкапов — прямых копий файлов, в которых хранятся данные — логические бэкапы не сохраняют физический формат хранения и представляют базу данных в переносимой форме. Обычно это набор SQL-команд и файлов метаданных, позволяющих воссоздать структуру и данные таблиц при восстановлении.
Хотя оба вида бэкапов по сути являются снепшотами базы данных, их различия определяют разные сценарии использования:
-
Физические бэкапы создаются и восстанавливаются быстрее, поскольку по сути представляют собой копии файлов базы данных. В сложных многокомпонентных системах это ограничивает их применение аналогичной аппаратной конфигурацией и системным окружением. В результате такие бэкапы обычно используются для быстрого восстановления на момент времени (Point-in-Time Recovery, PITR) в той же среде после сбоев.
-
Логические бэкапы более гибкие и переносимые. Их можно восстанавливать в других кластерах или даже в других СУБД. Однако создание и восстановление логических бэкапов, как правило, занимает больше времени.
Для создания физических бэкапов баз данных Greengage DB доступна модифицированная версия утилиты PostgreSQL pgbackrest.
Ее исходный код и инструкции по использованию доступны в репозитории pgbackrest.
Подробнее об использовании этой утилиты для резервирования кластера Greengage DB рассказывается в статьях в блоге Greengage DB:
Резервирование кластера Greengage DB и Резервирование кластера Greengage DB. Часть 2.
Способы создания логических бэкапов
Greengage DB поддерживает два основных подхода к созданию и восстановлению логических бэкапов:
-
Параллельное резервное копирование с использованием утилит
gpbackupиgprestore. Каждый сегмент-хост выполняет выгрузку своей части данных, что обеспечивает равномерное распределение нагрузки и параллельную обработку. В результате значительно сокращается время создания бэкапа и восстановления из него. -
Непараллельное резервное копирование с использованием утилит PostgreSQL
pg_dumpилиpg_dumpall. Все данные передаются на мастер-хост и записываются в его файловую систему или стандартный вывод. Этот подход проще и более переносимый, но создает повышенную нагрузку на мастер.
В таблице ниже приведено высокоуровневое сравнение этих двух способов.
| Способ | Инструменты | Нагрузка на кластер | Структура бэкапа | Комментарий |
|---|---|---|---|---|
Параллельный |
gpbackup, gprestore |
Умеренная и равномерно распределенная по сегментам |
Распределенная |
|
Непараллельный |
pg_dump, pg_dumpall |
Высокая нагрузка на ресурсы и сеть мастера; может требовать большого локального хранилища |
Один файл |
|
Следующие разделы описывают оба подхода подробнее и дают рекомендации по выбору между ними.
Параллельное резервное копирование утилитами gpbackup и gprestore
Greengage DB предоставляет утилиты gpbackup и gprestore для создания логических бэкапов баз данных и восстановления из них.
Эти утилиты распространяются отдельно от ядра Greengage DB, что позволяет управлять их установкой независимо.
Инструкции по установке и использованию gpbackup и gprestore приведены в документации gpbackup и gprestore.
gpbackup и gprestore работают распределенно, что позволяет использовать преимущества архитектуры Greengage DB.
При создании бэкапа мастер координирует процесс, а основная работа — сохранение данных — выполняется на сегментах.
Каждый сегмент сохраняет свои данные и создает собственные файлы бэкапа в локальной файловой системе.
В результате полный бэкап базы данных состоит из множества файлов на всех хостах кластера: метаданные на мастер-хосте и данные на каждом сегмент-хосте.
Такое параллельное выполнение минимизирует время создания бэкапа и обеспечивает равномерное распределение нагрузки по кластеру.
Благодаря своей производительности и гибкости gpbackup и gprestore рекомендуются для большинства сценариев резервного копирования и восстановления.
Эти преимущества особенно заметны в больших базах данных и кластерах с большим количеством сегментов.
Утилиты поддерживают широкий набор параметров конфигурации, позволяющих администраторам определять охват, структуру и расположение бэкапа. Например, это выбор конкретных схем или таблиц, включение или исключение метаданных, запись в локальное или внешнее хранилище, а также режим инкрементального резервного копирования. Утилиты также поддерживают плагины, позволяющие сохранять бэкапы напрямую в S3-совместимые объектные хранилища или другие внешние системы хранения.
Ниже приведены несколько типичных примеров использования gpbackup и gprestore.
Они предназначены для иллюстрации; полный справочник команд и подробные инструкции доступны в документации gpbackup и gprestore.
Создать бэкап всей базы данных с настройками по умолчанию:
$ gpbackup --dbname marketplaceСоздать бэкап только выбранной схемы:
$ gpbackup --dbname marketplace --include-schema salesСоздать инкрементальный бэкап на основе предыдущего полного бэкапа:
$ gpbackup --dbname marketplace --leaf-partition-data --incrementalВосстановить ранее созданный бэкап в новую базу данных:
$ gprestore --timestamp 20251006063113 --create-dbСохранить файлы бэкапа во внешнее S3-совместимое хранилище с использованием плагина S3:
$ gpbackup --dbname marketplace --plugin-config /home/gpadmin/s3-config.yamlНепараллельное резервное копирование утилитами pg_dump или pg_dumpall
В поставку Greengage DB включаются модифицированные версии стандартных утилит PostgreSQL для резервного копирования: pg_dump и pg_dumpall.
Эти версии адаптированы к работе с распределенной моделью данных Greengage DB и могут читать данные со всего кластера.
При этом процесс создания бэкапов не является распределенным и не использует сегмент-хосты для обработки данных.
Отличие между двумя утилитами в том, что pg_dump создает бэкап одной базы данных, а pg_dumpall — всех баз данных в кластере.
Подробная информация о pg_dump и pg_dumpall приведена на страницах pg_dump и pg_dumpall документации PostgreSQL.
Поскольку эти утилиты созданы для PostgreSQL, они не используют возможности распределенной архитектуры Greengage DB.
Они считывают все данные с сегментов через мастер и записывают их в файл или отправляют в стандартный вывод.
На самих сегментах резервное копирование не выполняется.
Как следствие, создание бэкапа с помощью pg_dump обычно требует значительно больше времени, чем с помощью gpbackup.
Кроме того, на мастере должно быть достаточно дискового пространства для хранения полного бэкапа.
Работа pg_dump и pg_dumpall не блокирует большинство операций, кроме DDL-операций, которым требуется блокировка ACCESS EXCLUSIVE.
Утилиты поддерживают различные форматы вывода.
Формат по умолчанию — одиночный SQL-скрипт, из которого можно воссоздать базу данных с помощью консоли psql.
Такие однофайловые бэкапы проще в управлении, чем распределенные бэкапы, созданные с помощью gpbackup.
Кроме того, они более переносимы: при создании с параметром --no-gp-syntax они совместимы с PostgreSQL и большинством систем, основанных на PostgreSQL.
Другие доступные форматы вывода — каталог, tar-архив и архив специального формата (custom archive).
При более сложной структуре эти форматы предоставляют дополнительные возможности, такие как сжатие или параллельное восстановление.
Для восстановления баз данных из таких бэкапов требуется утилита PostgreSQL pg_restore.
Ниже приведены несколько примеров использования pg_dump и pg_dumpall.
Создать бэкап одной базы данных в виде SQL-скрипта:
$ pg_dump marketplace > marketplace.sqlСоздать бэкап только указанной схемы:
$ pg_dump --schema=sales marketplace > sales.sqlСоздать бэкап только указанной таблицы:
$ pg_dump --table=sales.orders marketplace > orders.sqlСоздать бэкап всех баз данных в кластере с помощью pg_dumpall:
$ pg_dumpall > full_cluster.sqlСоздать бэкап в специальном архивном формате:
$ pg_dump -Fc --dbname=marketplace > marketplace.dumpВосстановить базу данных из архива специального формата, используя pg_restore с 8 параллельными потоками:
$ pg_restore -j 8 --dbname=restored_db marketplace.dumpВыбор способа резервного копирования
Выбор между параллельным (gpbackup/gprestore) и непараллельным (pg_dump/pg_dumpall) подходами к созданию бэкапов зависит от требований к производительности, потребностей в совместимости и других ограничений.
Параллельное резервное копирование быстрее и лучше масштабируется, так как данные читаются и записываются всеми сегментами кластера.
При использовании этого способа большие объемы данных не передаются по сети, что делает его подходящим для крупных аналитических баз данных.
Таким образом, параллельный способ является рекомендуемым для большинства регулярных операций резервного копирования и восстановления.
Используйте резервное копирование утилитами gpbackup и gprestore, когда:
-
бэкапы создаются регулярно для восстановления на том же кластере;
-
создается бэкап большой базы данных или кластера с большим числом сегментов;
-
важна быстрая и предсказуемая скорость создания бэкапа и восстановления;
-
нужны инкрементальные бэкапы или сохранение бэкапов в удаленные хранилища, такие как AWS S3;
-
необходимо равномерное распределение нагрузки по сегментам.
Непараллельное резервное копирование, хотя и значительно медленнее, обеспечивает лучшую переносимость бэкапов за счет совместимости с PostgreSQL.
Этот способ предпочтителен для некоторых сценариев миграции, например, экспорта базы данных для загрузки в другую СУБД или создания полного снимка базы данных в формате SQL.
Используйте непараллельный способ с pg_dump/pg_dumpall, когда:
-
нужен переносимый SQL-дамп, который можно загрузить в стандартный PostgreSQL (с опцией
--no-gp-syntax); -
выполняются миграции между разными версиями или платформами;
-
размер бэкапа достаточно мал, чтобы его можно было передать на мастер и записать в его файловую систему;
-
требуется простая однофайловая структура бэкапа.
На практике организации часто используют оба подхода:
gpbackup и gprestore для регулярного создания бэкапов и восстановления, и pg_dump/pg_dumpall для миграций, экспорта или задач, где требуется совместимость между системами.