- 18 Aug, 2014 1 commit
-
-
Matt Stancliff authored
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 08 Aug, 2014 3 commits
-
-
antirez authored
The funciton was also modified in order to be more standalone and produce an output without trailing spaces, making the reuse simpler. The global variable was renamed in cammel case as most other Redis globals, except the main ones we refer too many times, like 'server'.
-
charsyam authored
Less copy/paste code duplication. Closes #952
-
SungBin_Hong authored
Closes #1327
-
- 25 Jul, 2014 1 commit
-
-
antirez authored
Replica migration algorithm modified so that slaves never try to migrate to masters that were never configured to have slaves in the past. We want the algorithm to take care of masters that remained without *working* slaves, but that used to have slaves according to the cluster configuration.
-
- 22 Jul, 2014 1 commit
-
-
antirez authored
For non-empty masters, CLUSTER RESET is denied, and the user requires to start to reset a node by explicitly clearing it with FLUSHALL. However CLUSTER RESET when executed with slaves don't have this restrictions since data is just a replica of the master, and with read-only slaves it is also not possible to remove the data set. However the node was turned from slave to master after a reset, without touching the old slave data. This is 99.99% of times not appropriate and forces full resets to follow this path to work with both slave and master nodes: FLUSHALL CLUSTER RESET HARD FLUSHALL Since we need the first flushall for masters, and the second for slaves. This commit changes the behavior so that CLUSTER RESET removes the data set of a slave node during a reset, in the moment it gets turned into a master, so the new pattern is simply: FLUSHALL (that may fail for slaves) CLUSTER RESET
-
- 26 Jun, 2014 1 commit
-
-
antirez authored
-
- 25 Jun, 2014 4 commits
-
-
antirez authored
While we have to output failing masters in order to provide an accurate map (that may be the one of a Redis Cluster in down state because not all slots are served by a working master), to provide slaves in FAIL state is not a good idea since those are not necesarely needed, and the client will likely incur into a latency penalty trying to connect with a slave which is down. Note that this means that CLUSTER SLOTS does not provide a *complete* map of slaves, however this would not be of any help since slaves may be added later, and a client that needs to scale reads and requires to stay updated with the list of slaves, need to do a refresh of the map from time to time, anyway.
-
antirez authored
-
Matt Stancliff authored
CLUSTER SLOTS returns a Redis-formatted mapping from slot ranges to IP/Port pairs serving that slot range. The outer return elements group return values by slot ranges. The first two entires in each result are the min and max slots for the range. The third entry in each result is guaranteed to be either an IP/Port of the master for that slot range - OR - null if that slot range, for some reason, has no master The 4th and higher entries in each result are replica instances for the slot range. Output comparison: 127.0.0.1:7001> cluster nodes f853501ec8ae1618df0e0f0e86fd7abcfca36207 127.0.0.1:7001 myself,master - 0 0 2 connected 4096-8191 5a2caa782042187277647661ffc5da739b3e0805 127.0.0.1:7005 slave f853501ec8ae1618df0e0f0e86fd7abcfca36207 0 1402622415859 6 connected 6c70b49813e2ffc9dd4b8ec1e108276566fcf59f 127.0.0.1:7007 slave 26f4729ca0a5a992822667fc16b5220b13368f32 0 1402622415357 8 connected 2bd5a0e3bb7afb2b56a2120d3fef2f2e4333de1d 127.0.0.1:7006 slave 32adf4b8474fdc938189dba00dc8ed60ce635b0f 0 1402622419373 7 connected 5a9450e8279df36ff8e6bb1c139ce4d5268d1390 127.0.0.1:7000 master - 0 1402622418872 1 connected 0-4095 32adf4b8474fdc938189dba00dc8ed60ce635b0f 127.0.0.1:7002 master - 0 1402622419874 3 connected 8192-12287 5db7d05c245267afdfe48c83e7de899348d2bdb6 127.0.0.1:7004 slave 5a9450e8279df36ff8e6bb1c139ce4d5268d1390 0 1402622417867 5 connected 26f4729ca0a5a992822667fc16b5220b13368f32 127.0.0.1:7003 master - 0 1402622420877 4 connected 12288-16383 127.0.0.1:7001> cluster slots 1) 1) (integer) 0 2) (integer) 4095 3) 1) "127.0.0.1" 2) (integer) 7000 4) 1) "127.0.0.1" 2) (integer) 7004 2) 1) (integer) 12288 2) (integer) 16383 3) 1) "127.0.0.1" 2) (integer) 7003 4) 1) "127.0.0.1" 2) (integer) 7007 3) 1) (integer) 4096 2) (integer) 8191 3) 1) "127.0.0.1" 2) (integer) 7001 4) 1) "127.0.0.1" 2) (integer) 7005 4) 1) (integer) 8192 2) (integer) 12287 3) 1) "127.0.0.1" 2) (integer) 7002 4) 1) "127.0.0.1" 2) (integer) 7006
-
antirez authored
Instead of having an hardcoded IP address in the node configuration, we autodiscover it via MEET messages for automatic update when the node is restarted with a different IP address. This mechanism was discussed in the context of PR #1782.
-
- 23 Jun, 2014 1 commit
-
-
Matt Stancliff authored
We need to access (bindaddr[0] || NULL) in a few places, so centralize access with a nice macro.
-
- 20 Jun, 2014 1 commit
-
-
antirez authored
-
- 10 Jun, 2014 6 commits
- 07 Jun, 2014 2 commits
-
-
antirez authored
Since there are ways to alter the configEpoch outside of the failover procedure (for exampel CLUSTER SET-CONFIG-EPOCH and via the configEpoch collision resolution algorithm), make always sure, before replacing our configEpoch with a new one, that it is greater than the current one.
-
antirez authored
SET-CONFIG-EPOCH, used by redis-trib at cluster creation time, failed to update the currentEpoch, making it possible after a failover for a server to set its configEpoch to a value smaller than the current one (since configEpochs are obtained using currentEpoch). The bug totally break the Redis Cluster algorithms and protocols allowing for permanent split brain conditions about the slots configuration as shown in issue #1799.
-
- 26 May, 2014 1 commit
-
-
antirez authored
There is a time defined by REDIS_CLUSTER_WRITABLE_DELAY where fail -> ok switch is not possible after startup as a master for some time, however the contrary (ok -> fail) should always be possible.
-
- 22 May, 2014 1 commit
-
-
antirez authored
Check the commit changes in the example redis.conf for more information.
-
- 15 May, 2014 5 commits
-
-
antirez authored
clusterHandleSlaveFailover() was reimplementing what clusterSetNodeAsMaster() without any good reason.
-
antirez authored
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 authored
-
antirez authored
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 authored
-
- 14 May, 2014 2 commits
-
-
antirez authored
-
antirez authored
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.
-
- 12 May, 2014 4 commits
-
-
antirez authored
-
antirez authored
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 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 1 commit
-
-
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.
-