Часто задаваемые вопросы

Введение

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

Что делать при ошибке «could not find WAL segment»?

У этой ошибки может быть множество причин, в том числе:

• неверно настроенная команда archive_command
• ошибки в файлах конфигурации pgBackRest
• проблемы с сетью или правами доступа
• ошибки в настройке стороннего продукта (например, S3, Swift или Minio)
• большая очередь WAL, ожидающих архивирования

Рекомендуется:

• проверить archive_command в PostgreSQL
• проверить настройки pgBackRest на каждом сервере (например, параметры pg* задаются на сервере репозитория, а параметры repo* — на сервере PostgreSQL)
• выполнить команду check, задав для --archive-timeout значение больше указанного в файле конфигурации pgBackRest (или значения по умолчанию), чтобы проверить, не требуется ли больше времени для обработки очереди WAL. Если система генерирует большой объём WAL, стоит настроить асинхронное архивирование

Как вручную удалить набор резервной копии?

Полный набор резервной копии можно удалить с помощью параметра --set, как описано в разделе Справочник команд: Expire .

Как задать отдельные настройки для каждой команды?

pgBackRest позволяет задавать параметры в файле конфигурации отдельно для каждой команды. Эта возможность и приоритет параметров описаны в разделе Настройка stanza кластера .

Например, параметр process-max можно настроить для каждой команды:

[global]
# used where not overridden
process-max=2

[global:backup]
# more cores for backup
process-max=4

[global:restore]
# all the cores for restore
process-max=8

[global:archive-push]
# more cores for archive-push
process-max=3

[global:archive-get]
# fewer cores for archive-get
process-max=1

Можно ли использовать точки в имени бакета S3?

RFC-2818 не допускает, чтобы подстановочные знаки соответствовали точке (.), поэтому имена бакетов S3 не должны содержать точек. Если в имени бакета S3 есть точки, возникает ошибка вида «unable to find hostname ‘my.backup.bucket.s3.amazonaws.com’ in certificate common name or subject alternative names».

Исключение — repo-s3-uri-style=path: при такой настройке имя бакета добавляется в начало URI, а не имени узла. Поскольку бакет не является частью имени узла, сертификат проверяется только по имени конечной точки, и точки в имени бакета не создают проблем. Следует учитывать, что не все объектные хранилища, совместимые с S3, поддерживают URI в стиле path.

Где найти пакеты старых версий pgBackRest?

Репозиторий apt.postgresql.org содержит архив старых версий . Debian также хранит снимки всех тестовых сборок.

Почему резервное копирование завершается ошибкой, если задано backup-standby=y, а резервная база данных недоступна?

Резервное копирование с резервного сервера обычно настраивают для снижения нагрузки на первичный сервер, поэтому перенос копирования на первичный сервер при недоступности резервного часто противоречит этой цели. Увеличивать нагрузку на первичный сервер, когда в системе уже есть сбои, не рекомендуется. Если уже имеется достаточно свежая резервная копия, создание новой не критично: главное — своевременно архивировать WAL. После стабилизации системы времени для создания резервной копии будет достаточно.

Если резервная копия всё же необходима, можно добавить резервные серверы или убрать backup-standby. Этот параметр можно переопределить в командной строке с помощью --no-backup-standby, поэтому для разового резервного копирования менять конфигурацию не требуется.

Следует ли размещать репозиторий на резервном сервере?

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

Подробности приведены в разделе Выделенный сервер репозитория руководства пользователя.

Почему не работает восстановление на заданный момент времени?

Самая распространённая ошибка при восстановлении на заданный момент времени — выбор резервной копии, завершённой после целевого времени. При --type=time, если параметр --set не указан, pgBackRest ищет в настроенных репозиториях копию, завершённую до времени, заданного через --target=. Если подходящая копия не найдена, pgBackRest выдаёт ошибку, а не восстанавливает последнюю резервную копию. Копия, завершённая после целевого времени, не позволяет вернуться к этому более раннему моменту путём воспроизведения WAL.

Чтобы воспользоваться параметром --set, выполните команду info и выберите набор резервной копии, время завершения которой предшествует целевому времени. Затем при восстановлении укажите --set=BACKUP_LABEL, где BACKUP_LABEL — выбранный набор резервной копии.

Подробности приведены в разделе Восстановление на заданный момент времени руководства пользователя.

Что означает суффикс файла в архиве WAL?

Суффикс — это контрольная сумма SHA1, используемая для проверки целостности файла. Убрать её нельзя.

Занимает ли восстановление отдельных типов резервных копий (полных, дифференциальных, инкрементных) больше времени?

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

Как экспортировать резервную копию для использования в среде, изолированной от сети?

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

Однако есть обходной способ, если нужно получить самодостаточную копию базы данных для переноса, например, на USB-накопителе. Можно создать резервную копию с включённым параметром --archive-copy , чтобы необходимые сегменты WAL сохранялись вместе с ней. Затем следует восстановить её с параметрами --type=none --pg1-path=/your/target/path. В результате получится восстановленный каталог данных PostgreSQL со всеми необходимыми файлами WAL уже в pg_wal, аналогичный создаваемому командой pg_basebackup.

Этот каталог затем можно скопировать в другую систему; ожидается, что PostgreSQL сможет восстановиться из него без доступа к репозиторию pgBackRest.

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