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
{{ message }}
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
Hello:
For graceful switchover, we noticed in some cases, even if the candidate host is lagging, the orchestrator still goes ahead and set read_only=1 on the old primary before lag is noticed. This left the old primary with read_only =1 but switchover didn't happen, human intervention is needed to set read_only=0 on the old primary again. Is there a way to detect the lag and exit the switch-over process "before" setting read_only=1 on the old primary?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello:
For graceful switchover, we noticed in some cases, even if the candidate host is lagging, the orchestrator still goes ahead and set read_only=1 on the old primary before lag is noticed. This left the old primary with read_only =1 but switchover didn't happen, human intervention is needed to set read_only=0 on the old primary again. Is there a way to detect the lag and exit the switch-over process "before" setting read_only=1 on the old primary?
The text was updated successfully, but these errors were encountered: