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?