Каждые выходные после бекапа мастера приходит лаг логической репликации, не

знаю уже как траблшутить:

...
2021-04-27 02:07:29.919 background worker logical replication worker (PID 5851) exited with exit code 1
2021-04-27 02:07:34.925 logical replication apply worker for subscription db0_db3 has started
2021-04-27 08:09:00.336 terminating logical replication worker due to timeout
2021-04-27 08:09:00.339 logical replication worker (PID 5911) exited with exit code 1
2021-04-27 08:09:00.342 logical replication apply worker for subscription db0_db3 has started
2021-04-27 08:09:01.465 could not start WAL streaming: ERROR: replication slot db0_db3 is active for PID 18265
2021-04-27 08:09:01.468 background worker ogical replication worker (PID 23078) exited with exit code 1
2021-04-27 08:09:06.477 logical replication apply worker for subscription db0_db3 has started
2021-04-27 08:09:06.486 could not start WAL streaming: ERROR: replication slot db0_db3 is active for PID 18265
2021-04-27 08:09:06.489 background worker logical replication worker (PID 23385) exited with exit code 1
2021-04-27 08:09:11.498 logical replication apply worker for subscription db0_db3 has started
2021-04-27 08:09:11.507 could not start WAL streaming: ERROR: replication slot db0_db3 is active for PID 18265
...

Эта лавина продолжается некоторое время и затыкается, чтоб через 6 часов снова выкинуть ошибку

terminating logical replication worker due to timeout

Нужно ли таймаут еще увеличить? Что вообще происходит, может ли воркер на подписчике отвалиться из-за долгой трансакции на мастере например?

а не может быть такого что к слоту подключается два и более инстансов? смущает ошибка что слот уже активен для какого-то пида, но из приведенных логов непонятно кто скрывается под этим пидом

Спасибо, я похоже разобрался! На мастере wal_sender_timeout был отключен, а на подписчике он был 10min. К слоту не должно было больше инстансов подключаться тк у нас один мастер и одна логическая реплика. Агрессивный поллинг сокета на мастере летел потому что сокет помечен как nonblocking, это наверное ожидаемое поведение. На подписчике такой лавины поллов не было, потому что подписчик делает работу в промежутках, а мастер долбит сокет и ждет когда сможет скинуть очредную порцию мяса на NIC. А лаг логической репликации вообще может возникнуть из-за долгой трансакции на мастере? Я читал что мол вообще все оплоги отправляются на логическую реплику, и что старты-стопы трансакций в них тоже содержатся. Если это правда, то получается что может произойти такая ситуация, когда например кто-то на мастере захоботит эксклюзивный лок вообще на все и будет ждать, и тем временем произойдет таймаут подписчика?

> А лаг логической репликации вообще может возникнуть из-за долгой трансакции на мастере? да могут быть разные конфликты в зависимости от того что делалось в транзакции, можно об этом почитать тут

Так это, у меня ж не с конфликтами проблемы а с лагом вызванным таймаутами. После ручного килла walsender на мейне и walreceiver на реплике, проходит 6-8 часов пока реплика не подтвердит последний LSN всего на полшишечки, и только после этого начинает по чуть-чуть продвигать свой прогресс. А там гляди ж и следующие выходные наступают!

И вообще похоже в pg_stat_database_conflicts ничего не пишется на логической реплике

конфликт триггерится через конкретный интервал (см. max_standby_streaming_delay и аналогичный archive_delay), поэтому пока этот таймер не истек, будет копиться лаг. Также возможны более сложные варианты с дедлоками обнаружение которых пофиксили относительно недавно - там репликацияв результате встает колом.

Это же все настройки для hot standby, а логические реплики общаются через слоты и не находятся в recovery mode

да, верное замечание вобщем у меня нет других идей кроме как в моменты лага смотреть через стату что там происходит в бд

Почитал коммиты к 12.6 (мы на 12.5) - сомневаюсь что поможет этот багфикс с незамеченными дедлоками, но обновлюсь в пятницу. Тут еще такая штука что у логического подписчика есть собственная физическая реплика, и сейчас когда смотрю метрики то вижу что у той реплики лаг тоже начал расти в момент когда перестали продвигаться логические confirmed_lst & restart_lsn.