You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered: