Я к вам пожаловал с вопросом, который может и есть

Question

Я к вам пожаловал с вопросом, который может и есть

в документации, но я пока до него не дошёл.
На сервере-слейве postgresql 13.11, являющимся асинхронным hot_standby по отношению к мастеру, после ночной проблемы со связью восстановили потоковую репликацию и сервер-слейв пошёл долго догоняться; а затем (слейв ещё не догнался) службу postgresql на сервере-слейве перезапустили; и теперь я вижу, что на сервере-слейве pg_last_wal_replay_lsn() постепенно продолжают нагоняться (из чего делаю вывод, что на сервере-слейве ещё полно WAL, которые были приняты с мастера до рестарта слейва, но ещё не успели примениться); но до сих пор не вижу, чтобы он подключился к мастеру и занял на нём слот (select * from pg_replication_slots на мастере показывает, что слот неактивен) — это же нормально? если слейв после рестарта продолжает делать replay WAL'ов, принятых ранее, он не будет пытаться зацепиться к слоту на мастере?

#backend #devops #pgsql #programming #russian

0

22.08.2023

6 ответов

13 просмотров

S B

при выключении standby он не может сделать чекпоинт (так как не пишет WAL, а только читает их с мастера) и соответственно после перезапуска начинает проигрывание с прошлого чекпоинта _мастера_, он может быть на час назад например

0

22.08.2023

S B

https://www.postgresql.org/docs/15/warm-standby.html#STANDBY-SERVER-OPERATION At startup, the standby begins by restoring all WAL available in the archive location, calling restore_command. Once it reaches the end of WAL available there and restore_command fails, it tries to restore any WAL available in the pg_wal directory. If that fails, and streaming replication has been configured, the standby tries to connect to the primary server and start streaming WAL from the last valid record found in archive or pg_wal. If that fails or streaming replication is not configured, or if the connection is later disconnected, the standby goes back to step 1 and tries to restore the file from the archive again. This loop of retries from the archive, pg_wal, and via streaming replication goes on until the server is stopped or failover is triggered by a trigger file.

0

22.08.2023

Phil Chertiev Автор вопроса

S B
при выключении standby он не может сделать чекпоин...

первый раз сталкиваюсь просто с тем, что слейв, сказав в лог 2023-08-22 14:01:44 MSK LOG: consistent recovery state reached at 103F/48BADEB0 2023-08-22 14:01:44 MSK LOG: database system is ready to accept read only connections при этом не коннектится к слоту, а продолжает щёлкать replay_lsn: postgres@localhost:~$ date --rfc-3339=seconds 2023-08-22 15:07:23+03:00 postgres@localhost:~$ psql -Aqtc 'select pg_last_wal_replay_lsn();' 103F/BF1BD9B0 ещё и медленно так...

0

22.08.2023

S B

Phil Chertiev
первый раз сталкиваюсь просто с тем, что слейв, ск...

там цикл по трём источникам (архив, pg_wal, master), пока нужные WAL есть в текущем источнике (pg_wal например) — он не будет переключаться на следующий (на streaming с мастера например)

0

22.08.2023

Phil Chertiev Автор вопроса

S B
там цикл по трём источникам (архив, pg_wal, master...

нагналось наконец, да, слот подцепился. спасибо всем, кто ответил.

0

22.08.2023

Ilya Anfimov · Accepted Answer

Ilya Anfimov

Это довольно логичное поведение (учитывая внутреннюю логику запуска постгреса), но не очень правильное, кажэтся. Т.е. баг.

0

22.08.2023

172 похожих чатов

Я к вам пожаловал с вопросом, который может и есть

6 ответов

Похожие вопросы