pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedCascaded Replication question
2+ messages / 1 participants
[nested] [flat]
* Cascaded Replication question
@ 2023-01-09 15:24 Alexander Pogodin <alex_pogodin@yahoo.com>
0 siblings, 1 reply; 2+ messages in thread
From: Alexander Pogodin @ 2023-01-09 15:24 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Hello, guys!
I have a setup with 3 PgSQL instances connected with streaming replication as such:
+---+ +---+ +---+
| A | <-- | B | <-- | C |
+---+ +---+ +---+
When the link to A is broken, I manually promote server B and expect server C to follow new timeline: I have recovery_target_timeline set to latest. But that's not the case. To follow new timeline I have to restart server C. Is it the designed behavior or am I missing something?
I am using the latest 10.x version.
Could you, please, advise?
Best regards, Alex Pogodin.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Cascaded Replication question
@ 2023-01-11 09:02 Alexander Pogodin <alex_pogodin@yahoo.com>
parent: Alexander Pogodin <alex_pogodin@yahoo.com>
0 siblings, 0 replies; 2+ messages in thread
From: Alexander Pogodin @ 2023-01-11 09:02 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
So here are the results of my experiments done yesterday. On absolutely identical configs, the scheme given by me *does not* work on versions 10 and 11, but it works fine from version 12 to 15. Important lines from the C server log:
- for version 10-11:
postgresql-postgres-3-1 | 2023-01-10 15:42:15.922 GMT [32] LOG: restarted WAL streaming at 0/3000000 on timeline 1
postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] LOG: replication terminated by primary server
postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] DETAIL: End of WAL reached on timeline 1 at 0/3000060.
- for versions starting from 12th:
postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] DETAIL: End of WAL reached on timeline 1 at 0/3000060.
postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] LOG: fetching timeline history file for timeline 2 from primary server
postgresql-postgres-3-1 | 2023-01-10 15:47:29.032 GMT [28] LOG: new target timeline is 2
postgresql-postgres-3-1 | 2023-01-10 15:47:29.034 GMT [32] LOG: restarted WAL streaming at 0/3000000 on timeline 2
Experiments were held in Docker Compose environment, hence such logs.
Probably earlier versions require some additional setting adjusted, but at the moment I don't have any idea.
Best regards, Alex Pogodin.
On Monday, January 9, 2023 at 05:24:27 PM GMT+2, Alexander Pogodin <alex_pogodin@yahoo.com> wrote:
Hello, guys!
I have a setup with 3 PgSQL instances connected with streaming replication as such:
+---+ +---+ +---+
| A | <-- | B | <-- | C |
+---+ +---+ +---+
When the link to A is broken, I manually promote server B and expect server C to follow new timeline: I have recovery_target_timeline set to latest. But that's not the case. To follow new timeline I have to restart server C. Is it the designed behavior or am I missing something?
I am using the latest 10.x version.
Could you, please, advise?
Best regards, Alex Pogodin.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-01-11 09:02 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-01-09 15:24 Cascaded Replication question Alexander Pogodin <alex_pogodin@yahoo.com>
2023-01-11 09:02 ` Alexander Pogodin <alex_pogodin@yahoo.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox