25.2. Резервное копирование и восстановление в распределённой системе
Пред. НаверхГлава 25. Резервное копирование и восстановлениеНачало След.

25.2. Резервное копирование и восстановление в распределённой системе #

25.2.1. Требования к резервному копированию и восстановлению с помощью pg_probackup
25.2.2. Процесс резервного копирования с использованием pg_probackup
25.2.3. Восстановление кластера из резервной копии с использованием pg_probackup
25.2.4. Объединение резервных копий с помощью pg_probackup
25.2.5. Удаление резервных копий с помощью pg_probackup

В этом разделе обсуждается резервное копирование и восстановление в Postgres Pro Shardman.

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

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

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

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

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

25.2.1. Требования к резервному копированию и восстановлению с помощью pg_probackup #

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

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

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

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

  • Должен быть настроен беспарольный доступ по SSH между узлом резервного копирования и узлами кластера Postgres Pro 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 в инициированный репозиторий.

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

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

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

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

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

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

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

За подробной информацией о команде backup, обратитесь к справочному руководству.

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

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

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

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

Важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пред. Наверх След.
25.1. Непрерывное архивирование и восстановление на момент времени (Point-in-Time Recovery, PITR) Начало Глава 26. Отказоустойчивость, балансировка нагрузки и репликация