- 25 10月, 2013 4 次提交
-
-
由 antirez 提交于
-
由 Pieter Noordhuis 提交于
The irrelevant bits shouldn't be masked to 1. This can result in slots being skipped when the hash table is resized between calls to the iterator.
-
由 Pieter Noordhuis 提交于
-
由 Pieter Noordhuis 提交于
-
- 11 10月, 2013 2 次提交
- 09 10月, 2013 5 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
After the change in clusterCron() frequency of call, we still want to ping just one random node every second.
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
-
- 08 10月, 2013 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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 10月, 2013 3 次提交
- 04 10月, 2013 7 次提交
-
-
由 antirez 提交于
Sometimes when we resurrect a cached master after a successful partial resynchronization attempt, there is pending data in the output buffers of the client structure representing the master (likely REPLCONF ACK commands). If we don't reinstall the write handler, it will never be installed again by addReply*() family functions as they'll assume that if there is already data pending, the write handler is already installed. This bug caused some slaves after a successful partial sync to never send REPLCONF ACK, and continuously being detected as timing out by the master, with a disconnection / reconnection loop.
-
由 antirez 提交于
Sometimes when we resurrect a cached master after a successful partial resynchronization attempt, there is pending data in the output buffers of the client structure representing the master (likely REPLCONF ACK commands). If we don't reinstall the write handler, it will never be installed again by addReply*() family functions as they'll assume that if there is already data pending, the write handler is already installed. This bug caused some slaves after a successful partial sync to never send REPLCONF ACK, and continuously being detected as timing out by the master, with a disconnection / reconnection loop.
-
由 antirez 提交于
Since we started sending REPLCONF ACK from slaves to masters, the lastinteraction field of the client structure is always refreshed as soon as there is room in the socket output buffer, so masters in timeout are detected with too much delay (the socket buffer takes a lot of time to be filled by small REPLCONF ACK <number> entries). This commit only counts data received as interactions with a master, solving the issue.
-
由 antirez 提交于
Since we started sending REPLCONF ACK from slaves to masters, the lastinteraction field of the client structure is always refreshed as soon as there is room in the socket output buffer, so masters in timeout are detected with too much delay (the socket buffer takes a lot of time to be filled by small REPLCONF ACK <number> entries). This commit only counts data received as interactions with a master, solving the issue.
-
由 antirez 提交于
There was a bug that over-esteemed the amount of backlog available, however this could only happen when a slave was asking for an offset that was in the "future" compared to the master replication backlog. Now this case is handled well and logged as an incident in the master log file.
-
由 antirez 提交于
-
由 antirez 提交于
There was a bug that over-esteemed the amount of backlog available, however this could only happen when a slave was asking for an offset that was in the "future" compared to the master replication backlog. Now this case is handled well and logged as an incident in the master log file.
-
- 03 10月, 2013 1 次提交
-
-
由 antirez 提交于
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 10月, 2013 3 次提交
- 01 10月, 2013 2 次提交
- 30 9月, 2013 8 次提交
-
-
由 antirez 提交于
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 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
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 提交于
-
由 antirez 提交于
-
- 27 9月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 26 9月, 2013 2 次提交