README.md in redis_failover-0.5.4 vs README.md in redis_failover-0.6.0

- old
+ new

@@ -20,11 +20,12 @@ If so, the newly available nodes will be configured as slaves and brought back into the list of available nodes. Note that detection of a node going down should be nearly instantaneous, since the mechanism used to keep tabs on a node is via a blocking Redis BLPOP call (no polling). This call fails nearly immediately when the node actually goes offline. To avoid false positives (i.e., intermittent flaky network interruption), the Node Manager will only mark a node as unavailable if it fails to communicate with -it 3 times (this is configurable via --max-failures, see configuration options below). +it 3 times (this is configurable via --max-failures, see configuration options below). Note that you can +deploy multiple Node Manager daemons for added redundancy. This gem provides a RedisFailover::Client wrapper that is master/slave aware. The client is configured with a list of ZooKeeper servers. The client will automatically contact the ZooKeeper cluster to find out the current state of the world (i.e., who is the current master and who are the current slaves). The client also sets up a ZooKeeper watcher for the set of redis nodes controlled by the Node Manager daemon. When the daemon @@ -54,25 +55,29 @@ The Node Manager is a simple process that should be run as a background daemon. The daemon supports the following options: Usage: redis_node_manager [OPTIONS] - -p, --password password Redis password (optional) - -n, --nodes redis nodes Comma-separated redis host:port pairs (required) - -z zookeeper servers, Comma-separated ZooKeeper host:port pairs (required) - --zkservers - --znode-path path Znode path override for storing redis server list (optional) - --max-failures count Max failures before manager marks node unavailable (default 3) + + Specific options: + -n, --nodes NODES Comma-separated redis host:port pairs + -z, --zkservers SERVERS Comma-separated ZooKeeper host:port pairs + -p, --password [PASSWORD] Redis password + --znode-path [PATH] Znode path override for storing redis server list + --max-failures [COUNT] Max failures before manager marks node unavailable -h, --help Display all options To start the daemon for a simple master/slave configuration, use the following: redis_node_manager -n localhost:6379,localhost:6380 -z localhost:2181,localhost:2182,localhost:2183 The Node Manager will automatically discover the master/slaves upon startup. Note that it is -a good idea to monitor the redis Node Manager daemon process with a tool like Monit to ensure that it is restarted -in the case of a failure. +a good idea to run more than one instance of the Node Manager daemon in your environment. At +any moment, a single Node Manager process will be designated to monitor the redis servers. If +this Node Manager process dies or becomes partitioned from the network, another Node Manager +will be promoted as the primary monitor of redis servers. You can run as many Node Manager +processes as you'd like for added redundancy. ## Client Usage The redis failover client must be used in conjunction with a running Node Manager daemon. The client supports various configuration options, however the only mandatory option is the list of @@ -86,29 +91,25 @@ The full set of options that can be passed to RedisFailover::Client are: :zkservers - comma-separated ZooKeeper host:port pairs (required) :znode_path - the Znode path override for redis server list (optional) :password - password for redis nodes (optional) + :db - db to use for redis nodes (optional) :namespace - namespace for redis nodes (optional) :logger - logger override (optional) :retry_failure - indicate if failures should be retried (default true) :max_retries - max retries for a failure (default 3) ## Requirements -- redis_failover is actively tested against MRI 1.9.2/1.9.3. Other rubies may work, although I don't actively test against them. 1.8 is not supported. +- redis_failover is actively tested against MRI 1.9.2/1.9.3 and JRuby 1.6.7 (1.9 mode only). Other rubies may work, although I don't actively test against them. 1.8 is not supported. - redis_failover requires a ZooKeeper service cluster to ensure reliability and data consistency. ZooKeeper is very simple and easy to get up and running. Please refer to this [Quick ZooKeeper Guide](https://github.com/ryanlecompte/redis_failover/wiki/Quick-ZooKeeper-Guide) to get up and running quickly if you don't already have ZooKeeper as a part of your environment. ## Considerations - Note that by default the Node Manager will mark slaves that are currently syncing with their master as "available" based on the configuration value set for "slave-serve-stale-data" in redis.conf. By default this value is set to "yes" in the configuration, which means that slaves still syncing with their master will be available for servicing read requests. If you don't want this behavior, just set "slave-serve-stale-data" to "no" in your redis.conf file. - Note that it's still possible for the RedisFailover::Client instances to see a stale list of servers for a very small window. In most cases this will not be the case due to how ZooKeeper handles distributed communication, but you should be aware that in the worst case the client could write to a "stale" master for a small period of time until the next watch event is received by the client via ZooKeeper. - -## TODO - -- Rework specs to work against a set of real Redis/ZooKeeper nodes as opposed to stubs. -- Add support for running more than one Node Manager. ## Resources - To learn more about Redis master/slave replication, see the [Redis documentation](http://redis.io/topics/replication). - To learn more about ZooKeeper, see the official [ZooKeeper](http://zookeeper.apache.org/) site.