- 23 5月, 2014 5 次提交
-
-
由 antirez 提交于
The bug was triggered by running the test with Valgrind (which is a lot slower and more sensible to timing issues) after the recent changes that made Redis more promptly able to reply with the -LOADING error.
-
由 antirez 提交于
-
由 antirez 提交于
While iterating the list of nodes we want to set the slot as stable in the current node, not always in the first node of the list.
-
由 antirez 提交于
-
由 antirez 提交于
This fixes issue #1765.
-
- 20 5月, 2014 21 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 michael-grunder 提交于
When scanning the argument list inside of a redis.call() invocation for pre-cached values, there was no check being done that the argument we were on was in fact within the bounds of the cache size. So if a redis.call() command was ever executed with more than 32 arguments (current cache size #define setting) redis-server could segfault.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
clusterHandleSlaveFailover() was reimplementing what clusterSetNodeAsMaster() without any good reason.
-
由 antirez 提交于
Thanks to this change, when there is some code like: clusterDoBeforeSleep(CLUSTER_TODO_UPDATE_STATE|...); ... and later before returning to the event loop ... clusterUpdateState(); The clusterUpdateState() function will clar the flag and will not be repeated in the clusterBeforeSleep() function. This especially important for config save/fsync flags which are slow to execute and not a good idea to repeat without a good reason. This is implemented for all the CLUSTER_TODO flags.
-
由 antirez 提交于
-
由 antirez 提交于
The new command is able to reset a cluster node so that it starts again as a fresh node. By default the command performs a soft reset (the same as calling it as CLUSTER RESET SOFT), and the following steps are performed: 1) All slots are set as unassigned. 2) The list of known nodes is flushed. 3) Node is set as master if it is a slave. When an hard reset is performed with CLUSTER RESET HARD the following additional operations are performed: 4) A new Node ID is created at random. 5) Epochs are set to 0. CLUSTER RESET is useful both when the sysadmin wants to reconfigure a node with a different role (for example turning a slave into a master) and for testing purposes. It also may play a role in automatically provisioned Redis Clusters, since it allows to reset a node back to the initial state in order to be reconfigured.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
The previous code handling a lost slot (by another master with an higher configuration for the slot) was defensive, considering it an error and putting the cluster in an odd state requiring redis-cli fix. This was changed, because actually this only happens either in a legitimate way, with failovers, or when the admin messed with the config in order to reconfigure the cluster. So the new code instead will try to make sure that the keys stored match the new slots map, by removing all the keys in the slots we lost ownership from. The function that deletes the keys from the lost slots is called only if the node does not lose all its slots (resulting in a reconfiguration as a slave of the node that got ownership). This is an optimization since the replication code will anyway flush all the instance data in a faster way.
-
由 antirez 提交于
-
由 antirez 提交于
Better handling of connection errors in order to update the table and recovery, populate the startup nodes table after fetching the list of nodes. More work to do about it, it is still not as reliable as redis-rb-cluster implementation which is the minimal reference implementation for Redis Cluster clients.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Using CLUSTER FAILOVER FORCE it is now possible to failover a master in a forced way, which means: 1) No check to understand if the master is up is performed. 2) No data age of the slave is checked. Evan a slave with very old data can manually failover a master in this way. 3) No chat with the master is attempted to reach its replication offset: the master can just be down.
-
由 antirez 提交于
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.
-
- 19 5月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 Mike Trinkala 提交于
Set the MSB as documented.
-
- 12 5月, 2014 10 次提交
-
-
由 Akos Vandra 提交于
(Note: commit message modified by @antirez for clarity).
-
由 Akos Vandra 提交于
-
由 antirez 提交于
This way there is no need for the conflict resolution algo to be used in order to start with a cluster where each node has a different configEpoch.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Will be configurable / adaptive at some point but let's start with a saner value compared to 1 sec which is not a good idea for big data structures stored into a single key.
-
由 antirez 提交于
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.
-
由 antirez 提交于
-
由 antirez 提交于
Fixes issue #1734.
-
由 antirez 提交于
-
- 09 5月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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.
-