В архив БД не включены WAL-файлы

В небо, журнал может быть пустой.

Да вроде нет, вон реплика живет спокойно:

СООБЩЕНИЕ:  начало передачи журнала с главного сервера, с позиции 1918/61000000 на линии времени 1

Ты же в курсе, зачем нужен Write Ahead Log? Если да, то подумай, на кой чёрт он тебе нужен при бекапе (и почему его нет). Если нет, погугли, осознай.

ну без них кластер не хочет работать почему-то. Руками переносить тонны wal-ов не хочется. При basebackup он должен хотя бы записать, на какой позиции он остановился, какой сегмент был последний.
а использование dump/dumpall не имеет смысла при использовании WAL

почему не -X stream?

возможно связано с тем, что есть потоковая передача WAL и на другой сервер. wal_keep_segments сейчас в мастере 320, в реплике 0 (default)

А слоты не используете? Почему?

Всмысле, ты тестируешь восстановление из бекапа и у тебя реплики после этого не заводятся?

Не очень понял, слоты же всегда подключены? max_replication_slots? по дефолту 10 всегда есть

ну, я восстанавливаю кластер из бэкапа, он не стартует, при разборе обнаружилось что в таком архиве нет pg wal, вообще ни 1

Вот оно чего. Теперь понял суть проблемы.

[code] pg_basebackup -p ${PORT} -D - -Ft -U user -c fast -X fetch | pigz > $dump_path [/code]

А где проверка ошибок? Вы уверены что у вас битый бекап без WAL создался при успешном завершении?

проверка ошибок

проверка наличия wal?
проверка содержимого/корректности wal?
проверка результата работы pg_basebackup?
проверка наличия файла в каталоге дампов?

проверка результата работы pg_basebackup

this, у вас там pg_basebackup может падает с ошибкой типа «не могу скачать wal, они уже удалены», а вы и не в курсе.

если pg basebackup валится, он же делает об этом запись в логе? в конструкции

.... pg_basebackup ..... | pigz > $dump 

вот в логе есть поиск неактуального wal

2021-08-18 20:44:27.445 MSK [6558] user@[н/д] ОШИБКА:  запрошенный сегмент WAL 000000010000194900000069 уже удалён

а вот в архиве есть wal-ы (в отличии от ситуации, когда их там вообще ни 1)

-rw------- postgres/postgres       8192 2021-08-18 20:37 global/pg_control
-rw------- postgres/postgres          0 2021-08-18 20:40 pg_wal/archive_status/000000010000194900000068.done
-rw------- postgres/postgres   16777216 2021-08-18 20:32 pg_wal/000000010000194900000069
-rw------- postgres/postgres          0 2021-08-18 20:40 pg_wal/archive_status/000000010000194900000069.done

здесь же не проверить код выхода basebackup?

Зависит от shell в котором выполняется этот скрипт, в bash — можно, смотрите -o pipefail

pipefail проверил, классная штука, раньше изголялся как мог, отслеживая коды завершения

А по теме, ощущение что своевременно не запускался pg_archivecleanup,а после того, как это обнаружилось (каталог с валами по 70гб), старые валы затерлись, и теперь их найти уже нельзя. Как-то можно увидеть, какие метки времени wal входят в «историю» для бэкапа?

Понял и исчез в темноте)

Это уже за рамками моей компетенции, я не DBA.

Не понятно причём тут pg_archivecleanup. WAL файлы в каталоге базы в подкаталоге pg_wal/ чистит сам postgres, удалять их там руками или через pg_archivecleanup ни в коем случае нельзя, это всё сломает.

все сломает

Руками конечно чистить нельзя
А archivecleanup нужно запускать для каталога, где они хранятся, иначе никакого места не хватит держать валы за все время жизни базы.

а вот у нас есть подробности с места событий:

pg_basebackup: начинается базовое резервное копирование, ожидается завершение контрольной точки
pg_basebackup: контрольная точка завершена
pg_basebackup: стартовая точка в журнале предзаписи: 198E/BC009E28 на линии времени 1
pg_basebackup: не удалось получить конечную позицию в журнале предзаписи с сервера: ОШИБКА:  запрошенный сегмент WAL 000000010000198E000000BC уже удалён

А файлы есть, права есть

└─ # ls /waldir/000000010000198E000000BC* -lh
-rwxrwxrwx 1 1026 users  252 авг 22 20:47 /waldir/000000010000198E000000BC.00009E28.backup.gz
-rwxrwxrwx 1 1026 users 2,7M авг 22 20:32 /waldir/000000010000198E000000BC.gz

Опять хочется вернуться к списку файлов WAL, которые требуются на текущий момент в бэкапе, как это глянуть?

Достаточно интересная статья про репликацию и способы ее починки: https://habr.com/ru/company/oleg-bunin/blog/414111/

У меня постгрес сам удаляет wal-файлы. Смотрите настройки. Или какие-то долгоживущие транзакции, либо как раз потому-что они не забэкаплены, поэтому postgres не удаляет старые WAL. Включен ли archive_mode, какая команда задана в archive_command? Может она не корректно отрабатывает?

почему не поставить backup tool, которая сделает все за тебя?
pg_probackup, pgbackrest