собственно по первой маленькой базе выглядит так, что причина проблемы именно в малой активности и объёме. Нет WAL в архиве, перед которым нужно остановиться для достижения заданного recovery_target_time. А пока нет wal - recovery не может понять, то ли можно завершать работу уже т..к. изменений и не будет или это проблема и невозможно достичь заданного pitr т.к. отсутствуют требуемые wal.
Для продакшена это можно решить используя archive_timeout - база будет по меньшей мере раз в этот интервал переключать сегмент wal и архивировать. Но на неактивной базе это соответственно даст много пустых WAL по объёму.
по requested timeline 12 is not a child of this server's history - соответственно разбираться с таймлайнами. Каждый таймлайн - это promote (а так же успешный выход из point in time recovery при recovery_target_action = promote), то есть разветвление истории изменений. recovery_target_timeline можно использовать для восстановления на нужный timeline, но для этого, конечно, надо понимать, где какой таймлайн.
попробую угадать, что id у вас был сделан типа serial, затем вставили какие-то строки с константными id, не дав сиквенсу выделить значения. Теперь сиквенс генерирует значения, по его мнению свободные, но которые уже записаны в таблицу вручную. Нужно выставить setval сиквенсу на следующее значение относительно реально существующих.
%f , %p и ещё пару замен делает в этой строке сам postgresql перед запуском этой команды на выполнение. Для запущенной команды на этих местах будут действительные строки с конкретным именем сегмента WAL и куда именно его надо положить для продолжения восстановления.
Подход простой, хотя и архаичный. Закончили redo сегмента - дёрнули restore_command для получения следующего сегмента.
restore_command = 'wal-g wal-fetch "%f" "%p"'
раз архив есть всё равно.
wal_keep_size (wal_keep_segments) константного размера хранение избыточных WAL как раз для реплик
или слоты репликации. Если будете делать слоты - то желательно выставить какой-то max_slot_wal_keep_size чтобы забытый слот не уронил собственно базу, тем более если с мастера реплицируете
нет, никак не ограничивает. Размер одного сегмента WAL - это wal_segment_size. Задаётся только при initdb и меняется только чёрной магией которую я описывать не буду потому что часто приводит к необратимой потере всей базы.
Если мне условно нужно хранить wal для последние 12 часов то это
То это странная постановка задачи, уточните настоящую цель.
pool size = сколько коннектов базы может использовать баунсер для комбинации имя_пользователя + имя_бд.
Может быть равен количеству бекенд серверов разве что по случайному совпадению.
при pool mode=transaction коннект базы предоставляется подключённому к баунсеру клиенту на время этой транзакции (запрос вне транзакции так же есть транзакция). Пришло условно одновременно 30 запросов от разных клиентов - при pool size 20, 20 клиентов получили по коннекту с базой и начали выполняться, остальные начинают ждать пока освободится коннект базы. После завершения транзакции освободившийся коннект передаётся следующему желающему что-то сделать с базой.
Один процесс базы не может выполнять одновременно два запроса, а значит получаем, что если запрос выполняется за 10мс, то при pool size 10 будет теоретический предел пропускной способности 1000rps.
При том, что очень важно, это не значит что на всего 8-ядерном CPU при pool size 20 будет возможно удвоить результат. Результат может стать даже хуже, потому что конкурентные процессы будут драться между собой за CPU и активно мешать друг другу работать.
Размер пула подбирается по действительной ситуации и по мониторингу.
contrib - это не про контрибьюторов, это contrib, набор всяких расширений в репозитории postgresql. Теоретически их можно не ставить, но фактически нужны буквально на каждой продовой базе, потому что именно там расположен pg_stat_statements. Даже если приложению не требуются какие-нибудь pgcrypto/ltree/pg_trgm или ещё чего полезное.
лет 5 назад в deb репу даже прекратили собирать contrib в отдельный пакет, а перенесли в пакет сервера базы. Dervim пока что продолжает собирать отдельно для rpm.
смотря на сколько корректно атомарный снэпшот при этом получается (и не выключали ли fsync, как 1с-ники обожают себе отстреливать ноги). В идеальном случае получается crash recovery, аналогичный сбою по питанию. С точки зрения СУБД ситуация ожидаемая, но тестировать бекап на возможность восстановиться из него всё равно нужно будет.
Снимать файловый бекап при запущенной базе можно. Это делают все серьёзные утилиты бекапа postgresql: pgbackrest, wal-g, barman и прочие. Но для этого нужно соблюдать правила, которые требует сама база. К внимательному прочтению. Вот если у базы не попросить потребные данные для файлового бекапа - то это к приключениям и бекап выполнен неверно.
Только в случае постгреса эти файлы не переносимы, развернуть их на другом сервере не выйдет.
Ограниченно переносимы.
Развернуть на подходящем сервере выйдет. Это просто частный случай настройки потоковой репликации. Копируется именно физический PGDATA, а не логический дамп.
Основные ограничения: совпадение критичных для бинарной совместимости флагов компиляции. Сюрприз, даже другая аппаратная архитектура может не быть препятствием. Мы однажды с amd64 на arm64 перевозили базу физической репликацией даже.
я бы предложил сперва в MPTCP потыкаться, чем с агрегированием туннелей. Всё равно нужен гейт в обычную сеть, но по крайней мере MPTCP проектировался под такое использование.
В интерфейсе админа домена должен быть включен IMAP.
У каждого имени пользователя должен быть включен IMAP в своих настройках.
Пароль для IMAP - не пароль учётки в яндексе, а отдельный пароль приложения (на вкладке безопасности каждого пользователя)
По крайней мере так для меня с mbsync в новое место. Я не организация на сотню сотрудников, а одно физическое лицо со своим личным доменом.
Для продакшена это можно решить используя archive_timeout - база будет по меньшей мере раз в этот интервал переключать сегмент wal и архивировать. Но на неактивной базе это соответственно даст много пустых WAL по объёму.
по requested timeline 12 is not a child of this server's history - соответственно разбираться с таймлайнами. Каждый таймлайн - это promote (а так же успешный выход из point in time recovery при recovery_target_action = promote), то есть разветвление истории изменений. recovery_target_timeline можно использовать для восстановления на нужный timeline, но для этого, конечно, надо понимать, где какой таймлайн.