From c0374cc0fbcf0b55794c2975bfe3030b8b84aa96 Mon Sep 17 00:00:00 2001 From: "zhaozhao.zz" Date: Wed, 14 Aug 2024 19:23:25 +0800 Subject: [PATCH] Update commands/failover.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Viktor Söderqvist Signed-off-by: zhaozhao.zz <276441700@qq.com> --- commands/failover.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/commands/failover.md b/commands/failover.md index c6ab1bd5..0824ba67 100644 --- a/commands/failover.md +++ b/commands/failover.md @@ -17,7 +17,11 @@ 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. +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.