Skip to content

Commit

Permalink
Explain the special handling of redirection in failover
Browse files Browse the repository at this point in the history
Signed-off-by: zhaozhao.zz <zhaozhao.zz@alibaba-inc.com>
  • Loading branch information
soloestoy committed Aug 14, 2024
1 parent c8983c4 commit 2bcb973
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions commands/failover.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,8 @@ 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

0 comments on commit 2bcb973

Please sign in to comment.