- 11 3月, 2014 11 次提交
-
-
由 antirez 提交于
It also fixes multi-line comment style to be consistent with the rest of the code base. Related to #1555.
-
由 antirez 提交于
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 提交于
-
由 antirez 提交于
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.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Matt Stancliff 提交于
REDIS_CLUSTER_IPLEN had the same value as REDIS_IP_STR_LEN. They were both #define'd to the same INET6_ADDRSTRLEN.
-
由 Matt Stancliff 提交于
Function nodeIp2String in cluster.c is exactly anetPeerToString with a pre-extracted fd.
-
由 Matt Stancliff 提交于
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.
-
由 Matt Stancliff 提交于
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.
-
由 Matt Stancliff 提交于
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.
-
- 05 3月, 2014 1 次提交
-
-
由 antirez 提交于
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.
-
- 11 2月, 2014 14 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Logging them at WARNING level was of little utility and of sure disturb.
-
由 antirez 提交于
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.
-
由 antirez 提交于
The actual goal of the function was to get the max configEpoch found in the cluster, so make it general by removing the assignment of the max epoch to currentEpoch that is useful only at startup.
-
由 antirez 提交于
Removed a stale conditional preventing the configEpoch from incrementing after the import in certain conditions. Since the master got a new slot it should always claim a new configuration.
-
由 antirez 提交于
The node receiving the hash slot needs to have a version that wins over the other versions in order to force the ownership of the slot. However the current code is far from perfect since a failover can happen during the manual resharding. The fix is a work in progress but the bottom line is that the new version must either be voted as usually, set by redis-trib manually after it makes sure can't be used by other nodes, or reserved configEpochs could be used for manual operations (for example odd versions could be never used by slaves and are always used by CLUSTER SETSLOT NODE).
-
由 antirez 提交于
During slots migration redis-trib can send a number of SETSLOT commands. Fsyncing every time is a bit too much in production as verified empirically. To make sure configs are fsynced on all nodes after a resharding redis-trib may send something like CLUSTER CONFSYNC. In this case fsyncs were not providing too much value since anyway processes can crash in the middle of the resharding of an hash slot, and redis-trib should be able to recover from this condition anyway.
-
由 antirez 提交于
If the slot is manually assigned to another node, clear the migrating status regardless of the fact it was previously assigned to us or not, as long as we no longer have keys for this slot. This avoid a race during slots migration that may leave the slot in migrating status in the source node, since it received an update message from the destination node that is already claiming the slot. This way we are sure that redis-trib at the end of the slot migration is always able to close the slot correctly.
-
由 antirez 提交于
There is no way we can update the slave's node->slaveof pointer if we don't know the master (no node with such an ID in our tables).
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Masters without slots don't participate to the cluster but just do redirections, no need to take them in FAIL state if they are back reachable.
-
由 antirez 提交于
-
- 10 2月, 2014 4 次提交
- 08 2月, 2014 1 次提交
-
-
由 antirez 提交于
Currently this is marginally useful, only to make sure two keys are in the same hash slot when the cluster is stable (no rehashing in progress). In the future it is possible that support will be added to run mutli-keys operations with keys in the same hash slot.
-
- 05 2月, 2014 5 次提交
-
-
由 antirez 提交于
For manual failover we need a manual failover in progress, and that mf_can_start is true (master offset received and matched).
-
由 antirez 提交于
-
由 antirez 提交于
Otherwise it is always detected as a manual failover timed out.
-
由 antirez 提交于
When a slave requests masters vote for a manual failover, the REQUEST_AUTH message is flagged in a special way in order to force the masters to give the authorization even if the master is not marked as failing.
-
由 antirez 提交于
-
- 31 1月, 2014 3 次提交
-
-
由 antirez 提交于
It is possible to configure the min number of additional working slaves a master should be left with, for a slave to migrate to an orphaned master.
-
由 antirez 提交于
The check was placed in a way that conflicted with the continue statements used by the node hearth beat code later that needs to skip the current node sometimes. Moved at the start of the function so that's always executed.
-
由 antirez 提交于
This feature allows slaves to migrate to orphaned masters (masters without working slaves), as long as a set of conditions are met, including the fact that the migrating slave needs to be in a master-slaves ring with at least another slave working.
-
- 30 1月, 2014 1 次提交
-
-
由 antirez 提交于
-