Cleaned up redis root directory and changed links for redis.io and github issues and pull requests

This commit is contained in:
Jan Oberst 2011-10-18 14:14:16 -04:00
parent d0dc3d8204
commit e491a1a1a8
4 changed files with 5 additions and 194 deletions

View File

@ -1,15 +0,0 @@
This is Redis 2.3.x.
It was forked from 2.2 branch a few weeks ago, and is going to be the playground
for many new developments, especially related to replacing the VM with something
better.
VM is already completely removed from this release, and instead diskstore was
implemented. You can read more about it here:
http://groups.google.com/group/redis-db/browse_thread/thread/d444bc786689bde9
This Redis version is not intended for production environments.
Cheers,
Salvatore

156
CLUSTER
View File

@ -1,156 +0,0 @@
CLUSTER README
==============
Redis Cluster is currently a work in progress, however there are a few things
that you can do already with it to see how it works.
The following guide show you how to setup a three nodes cluster and issue some
basic command against it.
... WORK IN PROGRESS ...
1) Show MIGRATE
2) Show CLUSTER MEET
3) Show link status detection with CLUSTER NODES
4) Show how to add slots with CLUSTER ADDSLOTS
5) Show redirection
6) Show cluster down
... WORK IN PROGRESS ...
TODO
====
*** WARNING: all the following probably has some meaning only for
*** me (antirez), most info are not updated, so please consider this file
*** as a private TODO list / brainstorming.
- disconnect FAIL clients after some pong idle time.
---------------------------------
* Majority rule: the cluster con continue when there are all the hash slots covered AND when there are the majority of masters.
* Shutdown on request rule: when a node sees many connections closed or even a timeout longer than usual on almost all the other nodes, it will usually wait for the normal timeout before to change the state, unless it receives a query from a client: in such a case it will put itself into error status.
--------------------------------
* When asked for a key that is not in a node's business it will reply:
-ASK 1.2.3.4:6379 (in case we want the client to ask just one time)
-MOVED <slotid> 1.2.3.4:6379 (in case the hash slot is permanently moved)
So with -ASK a client should just retry the query against this new node, a single time.
With -MOVED the client should update its hash slots table to reflect the fact that now the specified node is the one to contact for the specified hash slot.
* Nodes communicate using a binary protocol.
* Node failure detection.
1) Every node contains information about all the other nodes:
- If this node is believed to work ok or not
- The hash slots for which this node is responsible
- If the node is a master or a slave
- If it is a slave, the slave of which node
- if it is a master, the list of slave nodes
- The slaves are ordered for "<ip>:<port>" string from lower to higher
ordered lexicographically. When a master is down, the cluster will
try to elect the first slave in the list.
2) Every node also contains the unix time where every other node was
reported to work properly (that is, it replied to a ping or any other
protocol request correctly). For every node we also store the timestamp
at which we sent the latest ping, so we can easily compute the current
lag.
3) From time to time a node pings a random node, selected among the nodes
with the least recent "alive" time stamp. Three random nodes are selected
and the one with lower alive time stamp is pinged.
4) The ping packet contains also information about a few random nodes
alive time stamp. So that the receiver of the ping will update the
alive table if the received alive timestamp is more recent the
one present in the node local table.
In the ping packet every node "gossip" information is something like
this:
<ip>:<port>:<status>:<pingsent_timestamp>:<pongreceived_timestamp>
status is OK, POSSIBLE_FAILURE, FAILURE.
5) The node replies to ping with a pong packet, that also contains a random
selections of nodes timestamps.
A given node thinks another node may be in a failure state once there is a
ping timeout bigger than 30 seconds (configurable).
When a possible failure is detected the node performs the following action:
1) Is the average between all the other nodes big? For instance bigger
than 30 seconds / 2 = 15 seconds? Probably *we* are disconnected.
In such a case we don't trust our lag data, and reset all the
timestamps of sent ping to zero. This way when we'll reconnect there
is no risk that we'll claim many nodes are down, taking inappropriate
actions.
2) Messages from nodes marked as failed are *always* ignored by the other
nodes. A new node needs to be "introduced" by a good online node.
3) If we are well connected (that is, condition "1" is not true) and a
node timeout is > 30 seconds, we mark the node as POSSIBLE_FAILURE
(a flat in the cluster node structure). Every time we sent a ping
to another node we inform this other nodes that we detected this
condition, as already stated.
4) Once a node receives a POSSIBLE_FAILURE status for a node that is
already marked as POSSIBLE_FAILURE locally, it sends a message
to all the other nodes of type NODE_FAILURE_DETECTED, communicating the
ip/port of the specified node.
All the nodes need to update the status of this node setting it into
FAILURE.
5) If the computer in FAILURE state is a master node, what is needed is
to perform a Slave Election.
SLAVE ELECTION
1) The slave election is performed by the first slave (with slaves ordered
lexicographically). Actually it is the first functioning slave, so if
the first slave is marked as failing the next slave will perform the
election and so forth. Such a slave is called the "Successor".
2) The Successor starts checking that all the nodes in the cluster already
marked the master in FAILURE state. If at least one node does not agree
no action is performed.
3) If all the nodes agree that the master is failing, the Successor does
the following:
a) It will send a SUCCESSION message to all the other nodes, that will
upgrade the hash slot tables accordingly. It will make sure that all
the nodes are updated and if some node did not received the message
it will keep trying.
b) Once all nodes not marked as FAILURE accepted the SUCCESSION message
it will update his own table and will start acting as a master
accepting write queries.
c) Every node receiving the succession message, if not already informed
of the change will broadcast the same message to other three random
nodes. No action is performed if the specified host was already marked
as the master node.
d) A node that was a slave of the original master that failed will
switch master to the new one once the SUCCESSION message is received.
RANDOM
1) When selecting a slave, the system will try to pick one with an IP different than the master and other slaves, if possible.
2) The PING packet also contains information about the local configuration checksum. This is the SHA1 of the current configuration, without the bits that normally change form one node to another (like latest ping reply, failure status of nodes, and so forth). From time to time the local config SHA1 is checked against the list of the other nodes, and if there is a mismatch between our configuration and the most common one that lasts for more than N seconds, the most common configuration is asked and retrieved from another node. The event is logged.
3) Every time a node updates its internal cluster configuration, it dumps such a config in the cluster.conf file. On startup the configuration is reloaded.
Nodes can share the cluster configuration when needed (for instance if SHA1 does not match) using this exact same format.
CLIENTS
- Clients may be configured to use slaves to perform reads, when read-after-write consistency is not required.

View File

@ -4,10 +4,10 @@
3. If steps 1 and 2 are ok, use the following procedure to submit a patch:
a. Fork Redis on github
a. Fork Redis on github ( http://help.github.com/fork-a-repo/ )
b. Create a topic branch (git checkout -b my_branch)
c. Push to your branch (git push origin my_branch)
d. Create an issue in the Redis google code site with a link to your patch
d. Initiate a pull request on github ( http://help.github.com/send-pull-requests/ )
e. Done :)
Thanks!

24
README
View File

@ -2,10 +2,8 @@ Where to find complete Redis documentation?
-------------------------------------------
This README is just a fast "quick start" document. You can find more detailed
documentation here:
documentation here: http://redis.io/documentation
1) http://code.google.com/p/redis
2) Check the 'doc' directory. doc/README.html is a good starting point :)
Building Redis
--------------
@ -27,22 +25,6 @@ After you build Redis is a good idea to test it (which require Tcl), using:
% make test
Buliding using tcmalloc
-----------------------
tcmalloc is a fast and space efficient implementation (for little objects)
of malloc(). Compiling Redis with it can improve performance and memory
usage. You can read more about it here:
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
In order to compile Redis with tcmalloc support, install tcmalloc on your system
and then use:
% make USE_TCMALLOC=yes
Note that you can pass any other target to make, as long as you append
USE_TCMALLOC=yes at the end.
Running Redis
-------------
@ -58,6 +40,7 @@ parameter (the path of the configuration file):
% cd src
% ./redis-server /path/to/redis.conf
Playing with Redis
------------------
@ -80,7 +63,6 @@ then in another terminal try the following:
You can find the list of all the available commands here:
http://code.google.com/p/redis/wiki/CommandReference
http://redis.io/commands
Enjoy!