The details on the Sentinel rewrite are very little as it is not strictly part of the 2.8 release, however here is a small summary of changes:
* Gossip is used as previously to detect if an instance is down.
* The Raft algorithm leader election step is performed to get elected to perform the failover.
* The Raft epoch of the election is used as a version of the new configuration.
* New configs are always broadcasted via Pub/Sub in the master and all the known slaves. So every Sentinel is listening for configs with an epoch that is greater than the current config, to update its view of the cluster.
* Now Sentinels try to force the cluster to have the setup of the latest config in memory (but with some delay to try to receive updates). So for instance slaves replicating with a wrong ip/port are reconfigured and so forth.
* Finally Sentinels persist their state on disk at every configuration update, or every time a new slave or sentinel is added to a master, so the system model is much more reasonable. Redis instances when reconfigured are sent a "CONFIG REWRITE" as well. TLDR: process restart friendly.
In general the code is now much simpler. The state, as you understand from the above description, is eventually consistent with a last-config-win semantics (where last means the configuration with the greater epoch).
* Gossip is used as previously to detect if an instance is down.
* The Raft algorithm leader election step is performed to get elected to perform the failover.
* The Raft epoch of the election is used as a version of the new configuration.
* New configs are always broadcasted via Pub/Sub in the master and all the known slaves. So every Sentinel is listening for configs with an epoch that is greater than the current config, to update its view of the cluster.
* Now Sentinels try to force the cluster to have the setup of the latest config in memory (but with some delay to try to receive updates). So for instance slaves replicating with a wrong ip/port are reconfigured and so forth.
* Finally Sentinels persist their state on disk at every configuration update, or every time a new slave or sentinel is added to a master, so the system model is much more reasonable. Redis instances when reconfigured are sent a "CONFIG REWRITE" as well. TLDR: process restart friendly.
In general the code is now much simpler. The state, as you understand from the above description, is eventually consistent with a last-config-win semantics (where last means the configuration with the greater epoch).