Postgres Pro Shardman : Документация: 14: 2.6. Резервное копирование и восстановление : Компания Postgres Professional

RU EN RU EN

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

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

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

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

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

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

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

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

Можно использовать команду 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).

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

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

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

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

2.6.1.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.1.2. Процесс резервного копирования с использованием pg_probackup #

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

Устанавливает необходимые блокировки в etcd, чтобы не допустить параллельные операции на уровне кластера.
Подключается к произвольной группой репликации и блокирует метаданные Shardman, чтобы не допустить изменения на сторонних серверах во время резервного копирования.
Выгружает метаданные Shardman, хранящиеся в etcd, в файл JSON в каталоге для резервных копий или в корзине в S3-совместимом объектном хранилище.
Для получения резервных копий из каждой группы репликации, параллельно запускает pg_probackup, используя сконфигурированный archive_command.
Создаёт точку синхронизации и получает значения LSN из структуры данных точки синхронизации для каждой группы репликации. Затем команда pg_probackup arhive-push используется для отправки журналов WAL, созданных после завершения резервного копирования, и файла WAL, в котором для каждой группы репликации присутствуют LSN точки синхронизации.

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

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

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

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

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

Важно

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

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

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

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

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

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

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

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

2.6.3. Объединение резервных копий с помощью 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.4. Удаление резервных копий с помощью 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

2.6. Backup and Recovery
Prev	Up	Chapter 2. Manage	Home	Next

2.6. Backup and Recovery #

2.6.1. Cluster Backup with pg_probackup

2.6.1.1. Requirements
2.6.1.2. pg_probackup Backup Process

2.6.2. Cluster Restore from a Backup with pg_probackup

2.6.3. Merging Backups with pg_probackup

2.6.4. Deleting Backups with pg_probackup

This section describes basics of backup and recovery in Shardman.

You can use the probackup backup command of the shardmanctl tool to perform a full binary consistent backup of a Shardman cluster to the backup repository on the local host or S3-compatible object storage and the probackup restore command to perform a recovery from any backup from the repository.

The PostgreSQL pg_probackup utility for creating consistent full and incremental backups was integrated into shardman-utils. shardman-utils uses the pg_probackup approach to store backups in a pre-created repository. In addition, the pg_probackup commands archive-get and archive-push are used to deliver WAL logs into the backup repository. Backup and restore modes use a passwordless ssh connection between the cluster nodes and the backup node.

Shardman cluster configuration parameter enable_csn_snapshot must be set to on. This parameter is necessary for the cluster backup to be consistent. If this option is disabled, a consistent backup is not possible.

For consistent visibility of distributed transactions, the technique of global snapshots based on physical clocks is used. Similarly, it is possible to get a consistent snapshot for backups, only the time corresponding to the global snapshot must be mapped to the set of LSNs for each node. Such set of consistent LSNs in a cluster is called a syncpoint. By getting the syncpoint and taking the LSN for each node in the cluster from it, it is possible to make a backup of each node, which must necessarily contain that LSN. It is also possible to recover to this LSN using the point in time recovery (PITR) mechanism.

The probackup command uses the pg_probackup utility and its options to create a cluster backup. If using probackup commands for restoration, the node names, defined by hostname or IP-address, must correspond to those that existed at the time of the backup.

2.6.1. Cluster Backup with pg_probackup #

This section describes basics of backup and recovery in Shardman with the probackup command.

You can use the probackup backup command of the shardmanctl tool to perform binary backups of a Shardman cluster into the backup repository on the local (backup) host and the probackup restore command to perform a recovery from the selected backup. Full and partial (delta) backups are supported.

2.6.1.1. Requirements #

To backup and restore a Shardman cluster via the probackup command, the following requirements must be met:

Shardman cluster configuration parameter enable_csn_snapshot must be on. This parameter is necessary for the cluster backup to be consistent. If this parameter is disabled, a consistent backup is not possible.
On the backup host, Shardman utilities must be installed into /opt/pgpro/sdm-14/bin.
On the backup host and on each cluster node, pg_probackup must be installed into /opt/pgpro/sdm-14/bin.
On the backup host, postgres Linux user and group must be created.
Passwordless SSH connection between the backup host and each Shardman cluster node for the postgres Linux user must be configured. To do this, on each node:
- The postgres user must create the .ssh subdirectory in the /var/lib/postgresql directory and place there the keys required for the passwordless SSH connection.
- To perform a backup/restore in a pretty large number of threads, such as 50 (-j=50, see the section called “ backup ” for details), MaxSessions and MaxStartups must be set to 100 for the backup host in the /etc/ssh/sshd_config file.
  Note
  Setting the number of threads (-j option) to a value greater than 10 for shardmanctl probackup may result in the actual number of SSH connections exceeding the maximum allowed number of simultaneous SSH connections on the backup host and consequently lead to an “ERROR: Agent error: kex_exchange_identification: Connection closed by remote host” error. To correct the error, either reduce the number of probackup threads or adjust the value of MaxStartups configuration parameter of the backup host. If SSH is set up as a xinetd service on the backup host, adjust the value of the xinetd per_source configuration parameter rather than MaxStartups.
You can disable SSH for data copying by setting the --storage-type option to the mount or S3 value (but SSH will be required to execute remote commands). Also this value will be automatically used in the restore process.
A backup folder or bucket in the S3-compatible object storage must be created.
Access for the postgres Linux user to the backup folder must be granted.
shardmanctl utility must be run as postgres Linux user.
init subcommand for the backup repository initialization must be successfully executed on the backup host.
archive-command add subcommand for enabling archive_command for each replication group to stream WALs into the initialized repository must be successfully executed on the backup host.

2.6.1.2. pg_probackup Backup Process #

shardmanctl conducts a backup task in several steps. The tool:

Takes necessary locks in etcd to prevent concurrent cluster-wide operations.
Connects to a random replication group and locks Shardman metadata tables to prevent modification of foreign servers during the backup.
Dumps Shardman metadata, stored in etcd, to a JSON file in the backup directory or bucket in the S3-compatible object storage.
To get backups from each replication group, concurrently runs pg_probackup using the configured archive_command.
Creates the syncpoint and gets LSNs for each replication group from the syncpoint data structure. Then uses the pg_probackup archive-push command to push WAL logs generated after finishing backup and the WAL file where syncpoint LSNs are present for each replication group.

2.6.2. Cluster Restore from a Backup with pg_probackup #

You can restore a backup on the same or compatible cluster. By compatible clusters, those that use the same Shardman version and have the same number of replication groups are meant here.

Also, you can restore other clusters from the same backup if these clusters have the same topology.

shardmanctl can perform either full restore, metadata-only or schema-only restore. Metadata-only restore is useful if issues are encountered with the etcd instance, but DBMS data is not corrupted.

During metadata-only restore, shardmanctl restores etcd data from the dump created during the backup.

Important

Restoring metadata to an incompatible cluster can lead to catastrophic consequences, including data loss, since the metadata state can differ from the actual configuration layout. Do not perform metadata-only restore if there were cluster reconfigurations after the backup, such as addition or deletion of nodes, even if the same nodes were added back again.

Schema-only recovery restore only schema information without data. It can be useful if the scale of the data is large and the schema is needed for testing or checking.

During a full restore, shardmanctl checks whether the number of replication groups in the target cluster matches the number of replication groups in the backup. This means that you cannot restore on an empty cluster, but need to add as many replication groups as necessary for the total number of them to match that of the cluster from which the backup was taken.

Also you can perform restoring only on the single shard using --shard parameter.

Also you can perform Point-in-Time Recovery using --recovery-target-time parameter. In this case Shardman finds closest syncpoint to specified timestamp and suggests to restore on found LSN. You can also specify a --wal-limit option to limit the number of WAL segments to be processed.

shardmanctl conducts full restore in several steps. The tool:

Takes the necessary locks in etcd to prevent concurrent cluster-wide operations and tries to assign replication groups in the backup to existing replication groups. If it cannot do this (for example, due to cluster incompatibility), the recovery fails.
Restores part of the etcd metadata: the cluster specification and parts of replication group definitions.
When the correct metadata is in place, runs stolon init in PITR initialization mode with RecoveryTargetName set to the value of the syncpoint LSN from the backup info file. DataRestoreCommand and RestoreCommand are also taken from the backup info file. These commands are generated automatically during the backup phase, it is not recommended to make any corrections to the file containing the Shardman cluster backup description. When restoring a cluster for each replication group, the WAL files containing the final LSN to restore will be requested automatically from the backup repository from the remote backup node via the pg_probackup archive-get command.
Waits for each replication group to recover.
Finally we need to enable archive_command back.

When performing a sequential restoration in PostgreSQL, be cautious of potential timeline conflicts within WAL (Write-Ahead Logging) segments. This issue commonly arises when restoring a database from a backup that was created at a certain point in time. If the database continues to operate and generate WAL segments after this backup, these new WAL segments are associated with a different timeline. During restoration, if the system tries to replay WAL segments from a different timeline - one that diverged from the point of backup - it can lead to inconsistencies and conflicts. Additionally, after completing a restoration in PostgreSQL, it is strongly advised not to restore the database onto the same timeline or onto any timeline that precedes the one from which the backup was made.

2.6.3. Merging Backups with pg_probackup #

The more incremental backups are created, the bigger the total size of the backup catalog grows. To save the disk space, it is possible to merge the incremental backups to their parent full backup by running the merge command, specifying the backup ID of the most recent incremental backup to merge:

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

This command merges the backups that belong to a common incremental backup chain. If a full backup is specified, it is merged with its first incremental backup. If an incremental backup is specified, it is merged to its parent full backup, along with all the incremental backups between them. Once the merge is complete, the full backup covers all the merged data, and the incremental backups are removed as redundant. Thus, the merge operation virtually equals to removing all the outdated backups from a full backup, but a lot faster, especially for the large data volumes. It also saves I/O and network traffic when using pg_probackup in the remote mode.

Before merging, pg_probackup validates all the affected backups to ensure that they are valid. The current backup status can be seen by running the show command:

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

For more information, see reference.

2.6.4. Deleting Backups with pg_probackup #

To delete a backup that is no longer needed, run the following command:

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

This command deletes a backup with a specified backup_id, along with all the incremental backups that descend from this backup_id, if any. It allows to delete some of the recent incremental backups, without affecting the underlying full backup and other incremental backups that follow it.

To delete the obsolete WAL files that are not needed for recovery, use the --delete-wal flag:

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