-
Notifications
You must be signed in to change notification settings - Fork 125
Description
During Restores and Standalone -> HA setup conversions, Stolon is booted with "existing" and is seeded with a old/fake keeperUID. Stolon notices the keeperUID doesn't exist and will work to generate a new one. Stolon updates the keeperstate file with the new UID that we need to use, but our supervisor will continue to use the original UID until the VM gets rebooted or hits its timeout. The end result is that Stolon won't be able to connect with the backend store until the VM is rebooted and the supervisor process is able to resolve the correct environment.
https://github.com/fly-apps/postgres-ha/blob/main/cmd/start/main.go#L136
While this is a noticeable problem, the problem does auto-resolve after the supervisor process restarts post-timeout.