Обсуждение: Cascaded Replication question
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.
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
- 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.