Skip to content
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.

Sign up for GitHub

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

Explain the special handling of redirection in failover #162

Merged
merged 2 commits into from
Aug 14, 2024
Merged

Explain the special handling of redirection in failover #162

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2bcb973
Explain the special handling of redirection in failover
soloestoy Aug 14, 2024
d812ee1
Update commands/failover.md
soloestoy Aug 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions commands/failover.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,12 @@ The field `master_failover_state` in `INFO replication` can be used to track the
* `waiting-for-sync`: The master is waiting for the replica to catch up to its replication offset.
* `failover-in-progress`: The master has demoted itself, and is attempting to hand off ownership to a target replica.

NOTE:
During the `failover-in-progress` phase, the master first demotes itself to a replica and then notifies the replica to promote itself to master.
These two steps are an asynchronous process, which may result in the simultaneous existence of two nodes as replicas.
In this scenario, for clients that support REDIRECT (explicitly execute [CLIENT CAPA REDIRECT](client-capa.md)), the redirection result may bounce back and forth between the two replicas until the target replica completes the process of promoting itself to master.
To avoid this situation, during the `failover-in-progress` phase, we temporarily suspend the clients that need to be redirected until the replica truly becomes the primary, and then resume the execution.

If the previous master had additional replicas attached to it, they will continue replicating from it as chained replicas. You will need to manually execute a `REPLICAOF` on these replicas to start replicating directly from the new master.

## Optional arguments
Expand Down