- 09 Oct, 2013 2 commits
-
-
antirez authored
All the internal state of cluster involving time is now using mstime_t and mstime() in order to use milliseconds resolution. Also the clusterCron() function is called with a 10 hz frequency instead of 1 hz. The cluster node_timeout must be also configured in milliseconds by the user in redis.conf.
-
antirez authored
-
- 08 Oct, 2013 1 commit
-
-
antirez authored
When a slave requests our vote, the configEpoch he claims for its master and the set of served slots must be greater or equal to the configEpoch of the nodes serving these slots in the current configuraiton of the master granting its vote. In other terms, masters don't vote for slaves having a stale configuration for the slots they want to serve.
-
- 07 Oct, 2013 3 commits
- 03 Oct, 2013 1 commit
-
-
antirez authored
The new API is able to remember operations to perform before returning to the event loop, such as checking if there is the failover quorum for a slave, save and fsync the configuraiton file, and so forth. Because this operations are performed before returning on the event loop we are sure that messages that are sent in the same event loop run will be delivered *after* the configuration is already saved, that is a requirement sometimes. For instance we want to publish a new epoch only when it is already stored in nodes.conf in order to avoid returning back in the logical clock when a node is restarted. This new API provides a big performance advantage compared to saving and possibly fsyncing the configuration file multiple times in the same event loop run, especially in the case of big clusters with tens or hundreds of nodes.
-
- 02 Oct, 2013 3 commits
- 01 Oct, 2013 2 commits
- 30 Sep, 2013 6 commits
-
-
antirez authored
The new algorithm does not check replies time as checking for the currentEpoch in the reply ensures that the reply is about the current election process.
-
antirez authored
-
antirez authored
The old algorithm used a PROMOTED flag and explicitly checks about slave->master convertions. Wit the new cluster meta-data propagation algorithm we just look at the configEpoch to check if we need to reconfigure slots, then: 1) If a node is a master but it reaches zero served slots becuase of reconfiguration. 2) If a node is a slave but the master reaches zero served slots because of a reconfiguration. We switch as a replica of the new slots owner.
-
antirez authored
We need to: 1) Increment the configEpoch. 2) Save it to disk and fsync the file. 3) Broadcast the PONG with the new configuration. If other nodes will receive the updated configuration we need to be sure to restart with this new config in the event of a crash.
-
antirez authored
-
antirez authored
-
- 27 Sep, 2013 1 commit
-
-
antirez authored
-
- 26 Sep, 2013 4 commits
- 25 Sep, 2013 4 commits
- 20 Sep, 2013 2 commits
-
-
antirez authored
First change: now there is no need to be a master in order to detect a failure, however the majority of masters signaling PFAIL or FAIL is needed. This change is important because it allows slaves rejoining the cluster after a partition to sense the FAIL condition so that eventually all the nodes agree on failures.
-
antirez authored
The time is sent in requests, and copied back in reply packets. This way the receiver can compare the time field in a reply with its local clock and check the age of the request associated with this reply. This is an easy way to discard delayed replies. Note that only a clock is used here, that is the one of the node sending the packet. The receiver only copies the field back into the reply, so no synchronization is needed between clocks of different hosts.
-
- 04 Sep, 2013 5 commits
- 03 Sep, 2013 3 commits
- 26 Aug, 2013 1 commit
-
-
antirez authored
This feature was implemented in the initial days of the Redis Cluster implementaiton but is not a good idea at all. 1) It depends on clocks to be synchronized, that is already very bad. 2) Moreover it adds a bug where the pong time is updated via gossip so no new PING is ever sent by the current node, with the effect of no PONG received, no update of tables, no clearing of PFAIL flag. In general to trust other nodes about the reachability of other nodes is a broken distributed programming model.
-
- 22 Aug, 2013 2 commits