pg_probackup и физическая репликация

Здравствуйте!
Есть два кластера СУБД Postgres PRO Ent 11.7. Первый кластер db1 – прод, на котором локально настроен локальный бэкап pg_probackup на другой раздел, на db1 так же находится WAL-архив с помощью pg_receivewal. Db2 – пустой кластер, на который необходимо в удаленном режиме восстановить бэкап с db1, а затем воспользовавшись WAL-архивом с db1 «догнать» db2 до физической репликации.
Восстановить полный и инкрементальный бэкап на db2 получается, но вот с выкачиванием WAL-сегментов проблемы. Я так понимаю, надо сформировать строку restore-command с archive-get, но как это правильно сделать? В моем случае remote-host и archive-host будут одинаковые? Или в этой ситуации вообще remote-host не нужен?

Если вручную запускать archive-get получаю ошибку:
Ошибка:
Пробовал в --wal-file-path написать путь который на db1 --wal-file-path=/data/pgpro/backup/wal, но это не помогло.

В каком направлении копать?

0

--wal-method=stream
--create-slot
--slot=имя_слота

1

fte65, а слот зачем?

0

Вы сам написали в топике физическая репликация - она только через физический слот репликации

Добавлено через 19 минут
И для понимания, бэкап + инкреминтал != репликация - это две разные штуки, бэкап - это возможность восстановить БД (инстанс) с нуля до определённого момента времени и WAL здесь не причём, репликация - это горячий резерв, позволяющий переключится на него единомоментно, а дальше разбираться с проблемами ...

0

Сообщение от fte65 Вы сам написали в топике физическая репликация - она только через физический слот репликации

Почему только? Для физической репликации слот репликации не обязателен же. Особенно когда есть WAL-арихив

Сообщение от fte65 И для понимания, бэкап + инкреминтал != репликация - это две разные штуки, бэкап - это возможность восстановить БД (инстанс) с нуля до определённого момента времени и WAL здесь не причём, репликация - это горячий резерв, позволяющий переключится на него единомоментно, а дальше разбираться с проблемами ...

Понимаю, что не равно. Но можно же восстановить FULL+инкрементал, а потом разницу "докатить" с помощью WAL-файлов, которые содержатся в WAL-архиве, разве нет?

0

--slot=имя_слота
Этот параметр может применяться только вместе с -X stream.
.....
Если этот ключ не указан и сервер поддерживает временные слоты репликации (они появились в версии 10), для трансляции WAL автоматически используется временный слот репликации.

--wal-method=метод
Включает в резервную копию все необходимые файлы журнала предзаписи (файлы WAL). В том числе включаются все файлы журнала, сгенерированные в процессе создания резервной копии. Любой метод, кроме none, позволяет запустить сервер с восстановленным каталогом, не используя архив WAL; таким образом будет получена полностью самодостаточная резервная копия.

Поддерживаются следующие методы получения журналов предзаписи:

n
none
Не включать журналы предзаписи в резервную копию.

f
fetch
Файлы журнала предзаписи собираются в конце процесса копирования. Таким образом необходимо установить достаточно большое значение параметра wal_keep_size, чтобы избежать преждевременного удаления нужных данных журнала. В случае переработки этих данных до завершения процесса копирования возникнет ошибка, а копия будет непригодной к использованию.

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

s
stream
Передавать журнал предзаписи в процессе создания резервной копии. При выборе этого метода открывается второе соединение к серверу, через которое будет передаваться журнал предзаписи параллельно с созданием копии. Таким образом, этот метод требует использования не одного, а двух соединений репликации, но если клиент будет успевать получать данные журнала предзаписи, на исходном сервере не потребуется сохранять дополнительные журналы.

Когда используется формат tar, файлы журнала предзаписи сохраняются в отдельном архиве с именем pg_wal.tar (если версия сервера ниже 10, файл будет называться pg_xlog.tar).

Это значение по умолчанию.

0

fte65, спасибо. Только вопрос в том, что можно ли воспользоваться существующим WAL-архивом, и если да, то какие ключи прописывать в restore-command?
Вы приводите ключи для команды backup скорее всего, а интересует для archive-get

0

Сообщение от bsd9 Только вопрос в том, что можно ли воспользоваться существующим WAL-архивом, и если да, то какие ключи прописывать в restore-command?

Извините, не внимательно посмотрел исходный топик, всё выше мной озвучено относится к ванильной утилитеpg_basebackup, а postgrespro я не использую... по-этому ещё раз извините, помочь не смогу

Добавлено через 9 минут
Видимо нужно углубится в изучение pg_probackup

1

Сообщение от fte65 Видимо нужно углубится в изучение pg_probackup

К сожалению, в документации этот момент не освещен.

0

Сообщение от bsd9 Если вручную запускать archive-get получаю ошибку:

pg_probackup archive-get
__не предназначена__ для запуска вручную со значениями %f и %p.
Эти псведозначения подставляет postgresql, когда запускает заданную команду, заданную через restore_command.
Сам pg_probackup ничего не знает ни про %f, ни про %p.

Сообщение от bsd9 В моем случае remote-host и archive-host будут одинаковые? Или в этой ситуации вообще remote-host не нужен?

Точно плохо помню, но кажется archive-host = remote-host для archive-get, т.е. указать можно либо то, либо другое. Указывать оба параметра - избыточно.

Сообщение от bsd9 В каком направлении копать?

Переводить сервер в режим рековери. Вроде это в 11-ой версии делалось созданием специального файла recovery.signal (поищите по документации здесь https://postgrespro.ru/docs/po... E-RECOVERY).
Тогда сервер начнет использовать restore_command, ну и по логам смотреть, что он действительно запускает и выполняет (поставить log_min_messages=INFO)

1

grgdvo, спасибо буду пробовать.

Сообщение от grgdvo __не предназначена__ для запуска вручную со значениями %f и %p.

Не знал об этом факте, если это прописано в документации, прошу прощения, ускользнуло от моего взора.

0

grgdvo, здравствуйте. Ваша рекомендация очень помогла, спасибо. Действительно, нет необходимости указывать и --archive-host и --archive-user. В связке с archive-get достаточно --remote-host и --remote-user.

Сделал так, создал пользователя backup_user и на db1, и на db2, потом делаем под backup_user на db1:
А на db2 под postgres:
Результирующая команда у меня выглядит так:
grgdvo, только вот WAL-сегменты все равно не выкачиваются, потому что каталог резервных копий принадлежат postgres и pg_receivewal запущен из-под postgres.

У меня наверное не совсем тривиальная задача, мне необходимо делать бэкапы и держать WAL-архив на локально на сервере db1, но периодически восстанавливать их на db2.
Проинициализировать каталог резервных копий под пользователем backup_user я не могу - потеряю возможность делать локальные резервные копии, так как он не сможет прочитать каталог pgdata.
А если оставить под postgres, то backup_user не сможет WAL выкачать, потому что они ему не принадлежат.

Не понимаю пока, как в такой ситуации правильно выставить права на каталоги резервных копий?

Добавлено через 21 минуту
Плюс еще у всех файлов WAL права 600, что исключает добавление в группы.

0

По хорошему надо, чтобы backup_user был владельцем (или имел права на запись) директории резервных копий pg_probackup.
Рассматривайте pg_probackup + backup_user как "сервер" резервных копий.
На db1 локально запускаете от backup_user
На db2 удаленно запускаете также от backup_user.
По идее так будет работать.

По-моему именно эта схема и рекомендовано к эксплуатации в документации
И еще посмотрите, нет ли каких-то настроек по глубине хранения WAL, чтобы не было "случайного" удаления WAL-сегментов.

По схеме у вас получается PITR (Point-In-Time-Recovery) на db2 с db1.
Наверно к этой схеме и стремится по документации и рекомендациям.

0