With the command CLUSTER REPLICATE, a node can't replicate a replica. But in some situations the replication could be like A->B->C, which is forbidden by CLUSTER REPLICATE. So I wanna know whether it's a legal or illegal behavior.
6b2e8b397b0e1511f963beb2e2d88700ff33a6ed 127.0.0.1:7001@17001 master - 0 1657802154102 4 connected 0-16383
c93d8121811d72f4cc04ab7b3b9217fc3beee134 127.0.0.1:6379@16379 myself,slave cd96aeeaa3cdd326f3d527195aeb62d2d00a2f3d 0 1657802153000 4 connected
cd96aeeaa3cdd326f3d527195aeb62d2d00a2f3d 127.0.0.1:7000@17000 slave 6b2e8b397b0e1511f963beb2e2d88700ff33a6ed 0 1657802155104 4 connected
How I simulate it: First let node B and C replicate A, then shutdown B, and manual failover C, so C is promoted to the primary, after that reboot B. Now the replication relation would be like B->A->C.
Comment From: madolson
In cluster mode chained replicas are not considered valid, and should only exist transitively. Looks like you found a case where that invariant isn't being upheld.
Comment From: uvletter
Yes we encountered a data center accident, after the recovery, we found there're many unexpected chained replicas, the above simulation is one of some cases we thought may result in the chained replicas. After looking into the code I find there seems no explicit judgement whether the master is the real master or just another replica. I think I can submit a pr to solve it, my primitive idea is adding a check whether my master is the owner of the slots in the cluster cron, it's a little crude but working I guess. @madolson what do you think, do you have any better idea.
Comment From: madolson
I think the cron job seems like an okay mitigation for the time being. @PingXie Do you have any thoughts?