У меня есть основной сервер, который архивирует (и gzip) файлы WAL в /wal/archive/. На данный момент я пытаюсь настроить горячий резерв с потоковой репликацией из базовой резервной копии.
При запуске режима ожидания я заметил такие ошибки, как:
could not receive data from WAL stream: ERROR: requested WAL segment 000000010000142400000014 has already been removed
Это имеет смысл, поскольку с момента создания base_backup прошел около дня, а файлы WAL уже были заархивированы. Я предоставил restore_command в резервном сервере recovery.conf чтобы скопировать файл с первичного и разархивировать его:
restore_command = '(set -o pipefail; scp primary_ip:/wal/archive/%f.gz /dev/stdout | pigz -d > "%p")'
Как ни странно, повторялись одни и те же ошибки. Имейте в виду, что я проверил, что указанная выше команда работает, когда я запускаю ее и предоставляю файл. Я хотел посмотреть, действительно ли выполняется команда, поэтому добавил эхо:
restore_command = '(set -o pipefail; echo "%f" >> /data/test.txt && scp primary_ip:/wal/archive/%f.gz /dev/stdout | pigz -d > "%p")'
Я ясно вижу, что он не выполняет команду, поскольку /data/test.txt не создается. В postgres у пользователя есть разрешение на запись в /data/. Есть ли что-то, что нужно указать на резервном сервере, чтобы проинструктировать его использовать restore_command когда первичный уже заархивировал файл WAL?
Мой файл recovery.conf был настроен в соответствии с разделом 25.2.4 документы.