-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race Condition With restore_command Breaks Standby Cluster Replication #1747
Comments
Hi @bradnicholson, thank you for the detailed report. This is the Postgres decides which file to restore, not Patroni.
vs
There is also one little issue with the standby cluster configuration, you need to define the The difference between |
Thanks @CyberDem0n - I did suspect a PG problem, but wanted to float it over here in case there was anything overt from the Patroni side happening. The different endpoints are an implementation detail - they are fine and will end up in the same place.
Thanks for this - I'll correct it I'll take this to PG. |
Describe the bug
When performing a clean Patroni switchover on a formation that is using wal archiving and has a a restore_command defined on the standby cluster to use that wal archive, there is a race condition where the standby cluster looks for the .history file in the wal archive before it is generated. It doesn't find it, and looks for the next wal file on the current timeline (which will never exist). At this point, the standby cluster is waiting on that non-existent wal file and replication stops. Restarting the standby cluster picks replication fixes replication.
Here is a summarized timeline of events. m-0 and m-1 are source formation, m-0 is the primary to start. Primary and standby clusters are on Timeline 9.
2020-11-04 14:51:11 m-0 switchover request
2020-11-04 14:51:11 m-0 is shutdown
2020-11-04 14:51:13.015 replication connection terminated on both m-1 and the standby cluster
2020-11-04 14:51:13.015 m-1 and standby cluster look for 0000000A.history in archive, does not find it
2020-11-04 14:51:17,137 m-1 and standby cluster looks for 0000000900000000000000B6 in archive (this file won't exist)
2020-11-04 14:51:17,119 m-1 promotes to primary INFO: promoted self to leader by acquiring session lock
2020-11-04 14:51:17,137 m-1 looks for 0000000900000000000000B6 in the archive again - does not find it
2020-11-04 14:51:17.557 m-1 promotion at the DB: received promote request
2020-11-04 14:51:17.557 m-1 promotion at the DB: redo done at 0/B6000028
2020-11-04 14:51:19.025 m-1 selected new timeline ID: 10
2020-11-04 14:51:19.852 m-1 archive recovery complete
2020-11-04 14:51:20 m-1 gets 00000009.history in the archive
2020-11-04 14:51:20,177 m-1 pushes 0000000A.history to archive
At this point, the standby cluster is not looking for
0000000A.history
anymore, and is stuck on timeline 9 waiting for0000000900000000000000B6
Possibly interesting, we have pgBackRest configured to log on
archive-get
command called by therestore_command
- and the standby cluster is not issuing additionalarchive-gets
to get0000000900000000000000B6
after the initial attempt. It just logsno action. i am the standby leader with the lock
in it's loop with no indication of any errors.To Reproduce
This is happening with no DB activity in testing.
Perform a controlled switchover via Patroni. In my tests, sometimes it works and replication continues on the standby cluster. In other times, the race condition is hit and replication stalls. There standby cluster waits on the next wal file from the old timeline (that will never exist) and does not connect back to the Primary formation.
When I observe this, switchover on the primary is around 6 seconds from the switchover request on the old primary until Postgres on the new secondary promote request is issued to Postgres.
Expected behavior
A clean Patroni switchover should not break replication to the standby cluster
Environment
Patroni configuration file
Source formation relevant bits
Standby Cluster Relevant bits:
Have you checked Patroni logs?
Yes, summarized timeline is above. Details below.
Have you checked PostgreSQL logs?
m-0 logs:
m-1 logs:
Standby Cluster logs:
Have you tried to use GitHub issue search?
Yes, didn't find anything.
The text was updated successfully, but these errors were encountered: