2.6. Резервное копирование и восстановление
Пред. НаверхГлава 2. УправлениеНачало След.

2.6. Резервное копирование и восстановление

2.6.1. Резервное копирование кластера с использованием pg_basebackup
2.6.2. Восстановление кластера из резервной копии с использованием pg_basebackup
2.6.3. Резервное копирование кластера с использованием pg_probackup
2.6.4. Восстановление кластера из резервной копии с использованием pg_probackup
2.6.5. Объединение резервных копий с помощью pg_probackup
2.6.6. Удаление резервных копий с помощью pg_probackup

В данном разделе рассматриваются основы резервного копирования и восстановления Shardman.

Для выполнения полного двоичного согласованного резервного копирования кластера Shardman в общий каталог или локальный каталог (при указании параметра --use-ssh) можно использовать команду backup инструмента shardmanctl, а для выполнения восстановления из этой резервной копии команду recover.

Также можно использовать команду probackup backup инструмента shardmanctl для выполнения полного согласованного двоичного резервного копирования кластера Shardman в репозиторий резервных копий на локальном узле или в S3-совместимом объектном хранилище и probackup restore для выполнения восстановления из любой резервной копии в репозитории.

Утилита PostgreSQL pg_probackup для создания согласованных полных и инкрементальных резервных копий была интегрирована в shardman-utils. Утилита shardman-utils использует подход pg_probackup для хранения резервных копий в предварительно созданном репозитории. Команды pg_probackup archive-get и archive-push используются для доставки журналов WAL в репозиторий резервных копий. В режимах резервного копирования и восстановления используется подключение по SSH без пароля между узлами кластера и узлом резервных копий.

Параметр конфигурации кластера Shardman enable_csn_snapshot должен иметь значение on. Этот параметр необходим для согласованности резервной копии кластера. Если этот параметр отключён, согласованное резервное копирование невозможно.

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

Команды backup и probackup используют разные механизмы создания резервных копий. Команда backup использует стандартные утилиты pg_basebackup и pg_receivewal. Команда probackup использует утилиту pg_probackup и её параметры для создания резервной копии кластера. При любом использовании команд backup или probackup для восстановления имён узлов, заданных по имени хоста или IP-адресу, эти имена должны соответствовать тем, которые существовали на момент создания резервной копии.

2.6.1. Резервное копирование кластера с использованием pg_basebackup

В данном разделе рассматриваются основы резервного копирования и восстановления Shardman с использованием команды basebackup.

2.6.1.1. Требования

Для резервного копирования и восстановления кластера Shardman командой basebackup должны быть выполнены следующие требования:

  • Параметр конфигурации кластера Shardman enable_csn_snapshot должен иметь значение on. Этот параметр необходим для согласованности резервной копии кластера. Если этот параметр отключён, согласованное резервное копирование невозможно.

  • На каждом узле кластера Shardman утилиты Shardman должны быть установлены в каталог /opt/pgpro/sdm-14/bin.

  • На каждом узле кластера Shardman утилита pg_basebackup должна быть установлена в каталог /opt/pgpro/sdm-14/bin.

  • На каждом узле кластера Shardman должны быть созданы пользователь и группа пользователей операционной системы с именем postgres.

  • Должен быть настроен беспарольный доступ по SSH между узлами кластера Shardman для пользователя postgres операционной системы.

  • Если не указан флаг --use-ssh, все узлы кластера Shardman должны быть подключены к общему сетевому хранилищу, в котором должен быть создан каталог для резервных копий.

  • Если флаг --use-ssh указан, каталог для резервных копий можно создать в локальном хранилище на узле, где будет вызываться команда recover.

  • Пользователю postgres должен быть предоставлен доступ к каталогу с резервными копиями.

  • Утилита shardmanctl должна запускаться пользователем postgres операционной системы.

2.6.1.2. Резервное копирование с использованием pg_basebackup

shardmanctl выполняет задачу резервного копирования в несколько этапов.

  1. Устанавливает необходимые блокировки в etcd, чтобы не допустить параллельные операции на уровне кластера.

  2. Подключается к произвольной группой репликации и блокирует метаданные Shardman, чтобы не допустить изменения на сторонних серверах во время резервного копирования.

  3. Создаёт слоты репликации в каждой группе репликации, чтобы гарантировать сохранение WAL-записей.

  4. Выгружает метаданные Shardman, хранящиеся в etcd, в файл JSON в каталоге для резервных копий.

  5. Для получения резервных копий из каждой группы репликации, параллельно запускает pg_basebackup, используя созданные слоты репликации.

  6. Создаёт точку синхронизации и использует pg_receivewal для получения журналов WAL, созданных после завершения каждого выполнения базового резервного копирования (basebackup), до тех пор, пока не будут достигнуты LSN, извлечённые из точки синхронизации.

  7. Исправляет неполные файлы WAL, созданные pg_receivewal, и создаёт файл описания резервной копии.

2.6.2. Восстановление кластера из резервной копии с использованием pg_basebackup

Можно восстановить резервную копию в том же кластере, где она находится, или в совместимом кластере. В данном случае совместимыми называются кластеры, которые используют одинаковые версии Shardman и имеют одинаковое количество групп репликации.

shardmanctl может выполнять либо полное восстановление, либо восстановление только метаданных. Восстановление только метаданных полезно, если возникают проблемы с экземпляром etcd, но данные СУБД не повреждены.

Во время восстановления только метаданных shardmanctl восстанавливает данные etcd из дампа, созданного во время резервного копирования.

Важно

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

При восстановлении только схемы восстанавливает только информацию о схеме без данных. Это может быть полезно при большом объёме данных, и если схема нужна для тестирования или проверки.

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

shardmanctl probackup restore может восстановить полностью или частично работающий кластер из резервной копии, созданной на полностью или частично работающем кластере.

Также можно восстановить только один сегмент, используя параметр --shard.

shardmanctl выполняет полное восстановление в несколько этапов.

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

  2. Восстанавливает часть метаданных etcd: конфигурацию кластера и части определений групп репликации.

  3. Когда корректные метаданные восстановлены, выполняет stolon init в режиме инициализации PITR с RecoveryTargetName, для которого задано значение LSN точки синхронизации из файла резервной копии. DataRestoreCommand и RestoreCommand также берутся из файла с информацией о резервной копии.

  4. Ожидает восстановления каждой группы репликации.

2.6.3. Резервное копирование кластера с использованием pg_probackup

В данном разделе рассматриваются основы резервного копирования и восстановления Shardman с использованием команды probackup.

Можно использовать команду probackup backup инструмента shardmanctl для выполнения двоичного резервного копирования кластера Shardman в репозиторий резервных копий на локальном (резервном) узле и probackup restore для выполнения восстановления из выбранной резервной копии. Поддерживаются полные и частичные (дельта) резервные копии.

2.6.3.1. Требования

Для резервного копирования и восстановления кластера Shardman командой probackup должны быть выполнены следующие требования:

  • Параметр конфигурации кластера Shardman enable_csn_snapshot должен иметь значение on. Этот параметр необходим для согласованности резервной копии кластера. Если этот параметр отключён, согласованное резервное копирование невозможно.

  • На узле резервного копирования утилиты Shardman должны быть установлены в каталог /opt/pgpro/sdm-14/bin.

  • На узле резервного копирования и на каждом узле кластера утилита pg_probackup должна быть установлена в каталог /opt/pgpro/sdm-14/bin.

  • На узле резервного копирования должны быть созданы пользователь и группа пользователей операционной системы с именем postgres.

  • Должен быть настроен беспарольный доступ по SSH между резервными узлами и узлами кластера Shardman для пользователя postgres операционной системы. Чтобы сделать это, на каждом узле:

    • Пользователь postgres должен создать подкаталог .ssh в каталоге /var/lib/postgresql и поместить туда ключи, необходимые для беспарольного подключения по SSH.

    • Для резервного копирования/восстановления довольно большого числа потоков, например 50 (-j=50, подробнее в « backup »), для MaxSessions и MaxStartups необходимо задать значение 100 на резервном узле в файле /etc/ssh/sshd_config.

      Примечание

      Если для команды shardmanctl probackup задать число потоков больше 10 (параметр -j), то фактическое число SSH-соединений может превысить максимально допустимое число одновременных SSH-соединений на резервном узле и, следовательно, приведёт к ошибке «ERROR: Agent error: kex_exchange_identification: Connection closed by remote host» (ОШИБКА: Ошибка агента: kex_exchange_identification: Соединение закрыто удалённым сервером). Чтобы исправить ошибку, либо уменьшите количество потоков probackup, либо измените значение параметра конфигурации MaxStartups резервного узла. Если SSH настроен как служба xinetd на резервном узле, измените значение параметра конфигурации xinetd per_source, а не MaxStartups.

    Можно отключить SSH для копирования данных, задав для параметра --storage-type значение mount или S3 (но для выполнения удалённых команд всё равно потребуется SSH). Это значение также будет автоматически использоваться в процессе восстановления.

  • Должен быть создан каталог для резервного копирования или корзина в S3-совместимом объектном хранилище.

  • Пользователю postgres должен быть предоставлен доступ к каталогу с резервными копиями.

  • Утилита shardmanctl должна запускаться пользователем postgres операционной системы.

  • На узле резервного копирования должна быть успешно выполнена подкоманда init для инициализации репозитория резервных копий.

  • На узле резервного копирования должна быть успешно выполнена подкоманда archive-command add для включения archive_command в каждой группе репликации для потоковой передачи WAL в инициированный репозиторий.

2.6.3.2. Процесс резервного копирования с использованием pg_probackup

shardmanctl выполняет задачу резервного копирования в несколько этапов.

  1. Устанавливает необходимые блокировки в etcd, чтобы не допустить параллельные операции на уровне кластера.

  2. Подключается к произвольной группой репликации и блокирует метаданные Shardman, чтобы не допустить изменения на сторонних серверах во время резервного копирования.

  3. Выгружает метаданные Shardman, хранящиеся в etcd, в файл JSON в каталоге для резервных копий или в корзине в S3-совместимом объектном хранилище.

  4. Для получения резервных копий из каждой группы репликации, параллельно запускает pg_probackup, используя сконфигурированный archive_command.

  5. Создаёт точку синхронизации и получает значения LSN из структуры данных точки синхронизации для каждой группы репликации. Затем команда pg_probackup arhive-push используется для отправки журналов WAL, созданных после завершения резервного копирования, и файла WAL, в котором для каждой группы репликации присутствуют LSN точки синхронизации.

2.6.4. Восстановление кластера из резервной копии с использованием pg_probackup

Можно восстановить резервную копию в том же кластере, где она находится, или в совместимом кластере. В данном случае совместимыми называются кластеры, которые используют одинаковые версии Shardman и имеют одинаковое количество групп репликации.

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

shardmanctl может выполнять либо полное восстановление, либо восстановление только метаданных, либо только схемы. Восстановление только метаданных полезно, если возникают проблемы с экземпляром etcd, но данные СУБД не повреждены.

Во время восстановления только метаданных shardmanctl восстанавливает данные etcd из дампа, созданного во время резервного копирования.

Важно

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

При восстановлении только схемы восстанавливает только информацию о схеме без данных. Это может быть полезно при большом объёме данных, и если схема нужна для тестирования или проверки.

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

Также можно выполнить восстановление только одного сегмента, используя параметр --shard.

Также можно выполнить восстановление на определённый момент времени, используя параметр --recovery-target-time. В этом случае Shardman находит ближайшую точку синхронизации к указанной временной метке и предлагает выполнить восстановление по найденному значению LSN. Можно также указать параметр --wal-limit, чтобы ограничить количество обрабатываемых сегментов WAL.

shardmanctl выполняет полное восстановление в несколько этапов.

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

  2. Восстанавливает часть метаданных etcd: конфигурацию кластера и части определений групп репликации.

  3. Когда корректные метаданные будут на месте, выполняет stolon init в режиме инициализации PITR с RecoveryTargetName, имеющем значение LSN точки синхронизации из файла с информацией о резервной копии. DataRestoreCommand и RestoreCommand также берутся из этого файла. Эти команды генерируются автоматически на этапе резервного копирования, не рекомендуется вносить какие-либо изменения в файл, содержащий описание резервной копии кластера Shardman. При восстановлении кластера для каждой группы репликации файлы WAL, содержащие окончательное значение LSN для восстановления, будут автоматически запрашиваться из репозитория резервных копий с удалённого узла командой pg_probackup archive-get.

  4. Ожидает восстановления каждой группы репликации.

  5. Наконец, нужно снова включить archive_command.

При выполнении последовательного восстановления в PostgreSQL следует учитывать потенциальные конфликты линии времени в сегментах WAL (журнала предзаписи). Эта проблема обычно возникает при восстановлении базы данных из резервной копии, созданной в определённый момент времени. Если база данных продолжает работать и генерировать сегменты WAL после резервного копирования, эти новые сегменты WAL будут связаны с другой линией времени. Если во время восстановления система попытается воспроизвести сегменты WAL из другой линии времени — той, которая разошлась с точкой резервного копирования, — это может привести к несогласованности и конфликтам. Кроме того, после завершения восстановления в PostgreSQL настоятельно не рекомендуется восстанавливать базу данных на той же линии времени или на любой линии времени, предшествующей той, в которой была создана резервная копия.

2.6.5. Объединение резервных копий с помощью pg_probackup

При увеличении количества инкрементальных копий также увеличивается общий размер каталога резервных копий. Чтобы сэкономить дисковое пространство, можно объединить инкрементальные копии с их родительской полной резервной копией, выполнив команду объединения и указав идентификатор последней инкрементальной копии для объединения: 

$ shardmanctl --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 probackup merge --backup-path backup_dir --backup-id backup_id

Эта команда объединяет резервные копии, принадлежащие к общей цепочке инкрементальных копий. Если указана полная копия, она объединяется с первой инкрементальной копией. Если указана инкрементальная копия, она объединяется с родительской полной копией вместе со всеми промежуточными инкрементальными копиями. После выполнения команды полная копия содержит все объединённые данные, а инкрементальные копии удаляются как ненужные. Таким образом, операция объединения по сути равнозначна удалению всех устаревших резервных копий из полной копии, но выполняется намного быстрее, особенно для больших объёмов данных. Это также позволяет сократить количество операций ввода-вывода и объём сетевого трафика при использовании pg_probackup в удалённом режиме.

Перед объединением pg_probackup проверяет все задействуемые резервные копии, чтобы удостовериться в их целостности. Можно посмотреть на текущее состояние резервной копии, выполнив команду show: 

$ shardmanctl --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 probackup show --backup-path backup_dir

За дополнительной информацией обратитесь к этой главе.

2.6.6. Удаление резервных копий с помощью pg_probackup

Для удаления резервной копии, ставшей ненужной, выполните команду: 

$ shardmanctl --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 probackup delete --backup-path backup_dir --backup-id backup_id

Эта команда удаляет резервную копию с указанным идентификатором backup_id вместе со всеми инкрементальными копиями, происходящими от этого backup_id, если они есть. Это позволяет удалить некоторые из последних инкрементальных резервных копий, не затрагивая базовую полную резервную копию и другие инкрементальные резервные копии, следующие за ней.

Для удаления старых файлов WAL, которые не нужны для восстановления резервных копий, воспользуйтесь ключом --delete-wal: 

$ shardmanctl --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 probackup delete --backup-path backup_dir --backup-id backup_id --delete-wal

За дополнительной информацией обратитесь к этой главе.

Пред. Наверх След.
2.5. Управление доступом Начало 2.7. Настройка безопасных подключений с помощью etcd