- 12 May, 2014 2 commits
-
-
antirez authored
Automatic failovers only happen in Redis Cluster if the slave trying to be elected was disconnected from its master for no more than 10 times the node-timeout value. However there should be no such a check for manual failovers, since these are initiated by the sysadmin that, in theory, knows what she is doing when a slave is selected to be promoted.
-
antirez authored
The error when the target key is busy was a generic one, while it makes sense to be able to distinguish between the target key busy error and the others easily.
-
- 09 May, 2014 3 commits
-
-
antirez authored
Fixes issue #1734.
-
antirez authored
The same change was operated for normal client connections. This is important for Cluster as well, since when a node rejoins the cluster, when a partition heals or after a restart, it gets flooded with new connection attempts by all the other nodes trying to form a full mesh again.
-
antirez authored
-
- 29 Apr, 2014 1 commit
-
-
antirez authored
Initially Redis Cluster accepted that after cluster creation all the nodes were at configEpoch 0, evolving from zero as failovers happen. However later the semantic was made more strict in order to make sure a cluster has always all the master nodes with a different configEpoch, which is more robust in some corner case (especially resulting from errors by the system administrator). To assign different configEpochs to different nodes at startup was a task performed naturally by the config conflicts resolution algorithm (see the Cluster specification). However this works well only for small clusters or when there are actually just a few collisions, since it is designed for exceptional cases. When a large cluster is created hundred of nodes can be at epoch 0, so the conflict resolution code is slow to provide an unique config to each node. For this reason this new command was introduced. It can be called only when a node is totally fresh: no other nodes known, and configEpoch set to zero, so it is safe even against misuses. redis-trib will use the new command in order to start the cluster already setting an incremental unique config to every node.
-
- 24 Apr, 2014 2 commits
-
-
antirez authored
We should return REDIS_ERR to signal we can't read the configuration because there is no config file only after checking errno, othewise we risk to rewrite an existing file that was not accessible for some other reason.
-
antirez authored
This was a common source of problems among users. The solution adopted is not bullet-proof as if the user deletes the nodes.conf file manually, and starts a new instance with the same nodes.conf file path, two instances will use the same file. However following this reasoning the user may drop a nuclear bomb into the datacenter as well.
-
- 22 Apr, 2014 1 commit
-
-
kingsumos authored
-
- 07 Apr, 2014 1 commit
-
-
antirez authored
adjustOpenFilesLimit() and clusterUpdateSlotsWithConfig() that were assuming uint64_t is the same as unsigned long long, which is true probably for all the systems out there that we target, but still GCC emitted a warning since technically they are two different types.
-
- 27 Mar, 2014 2 commits
- 26 Mar, 2014 3 commits
-
-
antirez authored
This is not really an error but something that always happens for example when creating a new cluster, or if the sysadmin rejoins manually a node that is already known. Since useless logs don't help, moved to VERBOSE level.
-
antirez authored
New config epochs must always be obtained incrementing the currentEpoch, that is itself guaranteed to be >= the max configEpoch currently known to the node.
-
antirez authored
-
- 25 Mar, 2014 3 commits
-
-
antirez authored
Update the comment since the implementation details changed.
-
antirez authored
The slave election in Redis Cluster guarantees that slaves promoted to masters always end with unique config epochs, however failures during manual reshardings, software bugs and operational errors may in theory cause two nodes to have the same configEpoch. This commit introduces a mechanism to eventually always end with different configEpochs if a collision ever happens. As a (wanted) side effect, this also ensures that after a new cluster is created, all nodes will end with a different configEpoch automatically.
-
antirez authored
-
- 20 Mar, 2014 1 commit
-
-
antirez authored
-
- 11 Mar, 2014 5 commits
-
-
antirez authored
The UPDATE message contains the configEpoch of the node configuration advertised in the packet. Update it if needed.
-
antirez authored
By manually modifying nodes configurations in random ways, it is possible to create the following scenario: A is serving keys for slot 10 B is manually configured to serve keys for slot 10 A receives an update from B (or another node) where it is informed that the slot 10 is now claimed by B with a greater configuration epoch, however A still has keys from slot 10. With this commit A will put the slot in error setting it in IMPORTING state, so that redis-trib can detect the issue.
-
antirez authored
-
antirez authored
-
antirez authored
-
- 10 Mar, 2014 5 commits
-
-
antirez authored
This API originated from the "diskstore" experiment, not for Redis Cluster itself, so there were legacy/useless things trying to differentiate between keys that are going to be overwritten and keys that need to be fetched from disk (preloaded). All useless with Cluster, so removed with the result of code simplification.
-
antirez authored
It also fixes multi-line comment style to be consistent with the rest of the code base. Related to #1555.
-
antirez authored
The code was already correct but it was using that bindaddr[0] is set to NULL as a side effect of current implementation if no bind address is configured. This is not guarnteed to hold true in the future.
-
antirez authored
-
antirez authored
When node-timeout is too small, in the order of a few milliseconds, there is no way the voting process can terminate during that time, so we set a lower limit for the failover timeout of two seconds. The retry time is set to two times the failover timeout time, so it is at least 4 seconds.
-
- 07 Mar, 2014 2 commits
- 06 Mar, 2014 3 commits
-
-
Matt Stancliff authored
REDIS_CLUSTER_IPLEN had the same value as REDIS_IP_STR_LEN. They were both #define'd to the same INET6_ADDRSTRLEN.
-
Matt Stancliff authored
Function nodeIp2String in cluster.c is exactly anetPeerToString with a pre-extracted fd.
-
Matt Stancliff authored
anetTcpAccept returns ANET_ERR, not AE_ERR. This isn't a physical error since both ANET_ERR and AE_ERR are -1, but better to be consistent.
-
- 04 Mar, 2014 1 commit
-
-
Matt Stancliff authored
The first address specified as a bind parameter (server.bindaddr[0]) gets used as the source IP for cluster communication. If no bind address is specified by the user, the behavior is unchanged. This patch allows multiple Redis Cluster instances to communicate when running on the same interface of the same host.
-
- 03 Mar, 2014 1 commit
-
-
antirez authored
This is still code to rework in order to use agreement to obtain a new configEpoch when a slot is migrated, however this commit handles the special case that happens when the nodes are just started and everybody has a configEpoch of 0. In this special condition to have the maximum configEpoch is not enough as the special epoch 0 is not unique (all the others are). This does not fixes the intrinsic race condition of a failover happening while we are resharding, that will be addressed later.
-
- 19 Feb, 2014 1 commit
-
-
Matt Stancliff authored
The default cluster control port is 10,000 ports higher than the base Redis port. If Redis is started on a too-high port, Cluster can't start and everything will exit later anyway.
-
- 11 Feb, 2014 3 commits
-
-
antirez authored
-
antirez authored
Logging them at WARNING level was of little utility and of sure disturb.
-
antirez authored
Avoid to trash a configEpoch for every slot migrated if this node has already the max configEpoch across the cluster. Still work to do in this area but this avoids both ending with a very high configEpoch without any reason and to flood the system with fsyncs.
-