Обсуждение: Why would Postgres 11 suddenly ignore the recovery.conf file?
Hi, I just stopped and restarted a Postgres 11 docker container which so far has happily streamed the WAL from its primary but after the restart it now seems to completely ignore the recovery.conf file and just outputs this: 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv6 address "::", port 5432 2021-10-04 10:14:19.123 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2021-10-04 10:14:19.304 UTC [21] LOG: database system was shut down in recovery at 2021-10-04 10:14:11 UTC 2021-10-04 10:14:19.305 UTC [21] LOG: entering standby mode 2021-10-04 10:14:19.313 UTC [21] LOG: could not signal for checkpoint: checkpointer is not running 2021-10-04 10:14:19.338 UTC [21] LOG: redo starts at 2F01/B9044C30 2021-10-04 10:15:35.889 UTC [21] LOG: consistent recovery state reached at 2F02/A2E1A108 2021-10-04 10:15:35.893 UTC [1] LOG: database system is ready to accept read only connections Notice that there is apparently no attempt being made to connect to the primary any more. The recovery.conf file is still present and correct so I don't understand why Postgres seems to ignore it completely? Regards, Dennis
Isn't this related to merge into postgresql.conf (https://www.postgresql.org/docs/current/recovery-config.html)? po 4. 10. 2021 v 12:35 odesílatel Dennis Jacobfeuerborn <dennisml@conversis.de> napsal: > > Hi, > I just stopped and restarted a Postgres 11 docker container which so far > has happily streamed the WAL from its primary but after the restart it > now seems to completely ignore the recovery.conf file and just outputs this: > > 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv4 address > "0.0.0.0", port 5432 > 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv6 address "::", > port 5432 > 2021-10-04 10:14:19.123 UTC [1] LOG: listening on Unix socket > "/var/run/postgresql/.s.PGSQL.5432" > 2021-10-04 10:14:19.304 UTC [21] LOG: database system was shut down in > recovery at 2021-10-04 10:14:11 UTC > 2021-10-04 10:14:19.305 UTC [21] LOG: entering standby mode > 2021-10-04 10:14:19.313 UTC [21] LOG: could not signal for checkpoint: > checkpointer is not running > 2021-10-04 10:14:19.338 UTC [21] LOG: redo starts at 2F01/B9044C30 > 2021-10-04 10:15:35.889 UTC [21] LOG: consistent recovery state reached > at 2F02/A2E1A108 > 2021-10-04 10:15:35.893 UTC [1] LOG: database system is ready to accept > read only connections > > Notice that there is apparently no attempt being made to connect to the > primary any more. The recovery.conf file is still present and correct so > I don't understand why Postgres seems to ignore it completely? > > Regards, > Dennis > >
That happened with Postgres 12 I think so it shouldn't affect this installation. On 10/4/21 12:40, Josef Šimánek wrote: > Isn't this related to merge into postgresql.conf > (https://www.postgresql.org/docs/current/recovery-config.html)? > > po 4. 10. 2021 v 12:35 odesílatel Dennis Jacobfeuerborn > <dennisml@conversis.de> napsal: >> >> Hi, >> I just stopped and restarted a Postgres 11 docker container which so far >> has happily streamed the WAL from its primary but after the restart it >> now seems to completely ignore the recovery.conf file and just outputs this: >> >> 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv4 address >> "0.0.0.0", port 5432 >> 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv6 address "::", >> port 5432 >> 2021-10-04 10:14:19.123 UTC [1] LOG: listening on Unix socket >> "/var/run/postgresql/.s.PGSQL.5432" >> 2021-10-04 10:14:19.304 UTC [21] LOG: database system was shut down in >> recovery at 2021-10-04 10:14:11 UTC >> 2021-10-04 10:14:19.305 UTC [21] LOG: entering standby mode >> 2021-10-04 10:14:19.313 UTC [21] LOG: could not signal for checkpoint: >> checkpointer is not running >> 2021-10-04 10:14:19.338 UTC [21] LOG: redo starts at 2F01/B9044C30 >> 2021-10-04 10:15:35.889 UTC [21] LOG: consistent recovery state reached >> at 2F02/A2E1A108 >> 2021-10-04 10:15:35.893 UTC [1] LOG: database system is ready to accept >> read only connections >> >> Notice that there is apparently no attempt being made to connect to the >> primary any more. The recovery.conf file is still present and correct so >> I don't understand why Postgres seems to ignore it completely? >> >> Regards, >> Dennis >> >>
Re: Why would Postgres 11 suddenly ignore the recovery.conf file?
От
hubert depesz lubaczewski
Дата:
On Mon, Oct 04, 2021 at 12:35:48PM +0200, Dennis Jacobfeuerborn wrote: > Hi, > I just stopped and restarted a Postgres 11 docker container which so far has > happily streamed the WAL from its primary but after the restart it now seems > to completely ignore the recovery.conf file and just outputs this: If this is 11, then it would mean that at some point in time Pg was told to finish recovery. Using trigger file, pg_ctl promote, some other means. But, perhaps it's pg 12 (or newer)? If so, then recovery.conf no longer is parsed. Best regards, depesz
On 10/4/21 12:35, Dennis Jacobfeuerborn wrote: > Hi, > I just stopped and restarted a Postgres 11 docker container which so far > has happily streamed the WAL from its primary but after the restart it > now seems to completely ignore the recovery.conf file and just outputs > this: > > 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv4 address > "0.0.0.0", port 5432 > 2021-10-04 10:14:19.103 UTC [1] LOG: listening on IPv6 address "::", > port 5432 > 2021-10-04 10:14:19.123 UTC [1] LOG: listening on Unix socket > "/var/run/postgresql/.s.PGSQL.5432" > 2021-10-04 10:14:19.304 UTC [21] LOG: database system was shut down in > recovery at 2021-10-04 10:14:11 UTC > 2021-10-04 10:14:19.305 UTC [21] LOG: entering standby mode > 2021-10-04 10:14:19.313 UTC [21] LOG: could not signal for checkpoint: > checkpointer is not running > 2021-10-04 10:14:19.338 UTC [21] LOG: redo starts at 2F01/B9044C30 > 2021-10-04 10:15:35.889 UTC [21] LOG: consistent recovery state reached > at 2F02/A2E1A108 > 2021-10-04 10:15:35.893 UTC [1] LOG: database system is ready to accept > read only connections > > Notice that there is apparently no attempt being made to connect to the > primary any more. The recovery.conf file is still present and correct so > I don't understand why Postgres seems to ignore it completely? Ok, so just as I sent the mail the log now showed this: 2021-10-04 10:37:53.841 UTC [45] LOG: started streaming WAL from primary at 2F14/13000000 on timeline 1 Notice that it took over 20 minutes for the system to start streaming. Could this be a connection related issue? If so is there a way to see that Postgres is trying to connect to the primary but hasn't succeeded yet? From the looks of it the logs stays silent until is actually has started streaming and there is no "initiating recovery" message before the connection actually succeeds. Regards, Dennis