fluencelabs/redis
1
0
Fork 0
mirror of https://github.com/fluencelabs/redis synced 2025-03-18 08:30:51 +00:00
Code Issues Projects Releases Wiki Activity

Fix typos & grammar in clusterBumpConfigEpochWithoutConsensus() comment.

Browse Source
This commit is contained in:
antirez 2016-01-08 12:07:52 +01:00
parent 7c1a5ff3ce
commit 36704d653b
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/cluster.c
View File

@ -948,7 +948,7 @@ uint64_t clusterGetMaxEpoch(void) {
/* If this node epoch is zero or is not already the greatest across the
* cluster (from the POV of the local configuration), this function will:
*
* 1) Generate a new config epoch increment the current epoch.
* 1) Generate a new config epoch, incrementing the current epoch.
* 2) Assign the new epoch to this node, WITHOUT any consensus.
* 3) Persist the configuration on disk before sending packets with the
* new configuration.
@ -963,16 +963,16 @@ uint64_t clusterGetMaxEpoch(void) {
* cases:
*
* 1) When slots are closed after importing. Otherwise resharding would be
* too exansive.
* too expansive.
* 2) When CLUSTER FAILOVER is called with options that force a slave to
* failover its master even if there is not master majority able to
* create a new configuration epoch.
*
* Redis Cluster does not explode using this function, even in the case of
* Redis Cluster will not explode using this function, even in the case of
* a collision between this node and another node, generating the same
* configuration epoch unilaterally, because the config epoch conflict
* resolution algorithm will eventually move colliding nodes to different
* config epochs. However usign this function may violate the "last failover
* config epochs. However using this function may violate the "last failover
* wins" rule, so should only be used with care. */
int clusterBumpConfigEpochWithoutConsensus(void) {
uint64_t maxEpoch = clusterGetMaxEpoch();