Skip to content

Commit

Permalink
Documentation updates and version bump
Browse files Browse the repository at this point in the history
  • Loading branch information
sreeix committed Mar 13, 2013
1 parent 8cc79ec commit d15af5c
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 16 deletions.
29 changes: 14 additions & 15 deletions Readme.md
Expand Up @@ -8,7 +8,11 @@ Why RedisProxy?

Typically for every redis server we setup, we have a backup server setup as a slave of the main server.

If the Active Redis crashes or goes down for maintenance, we want the application to seamlessly use(read/write) data from the backup server. But the problem is once the backup takes over as active it will be out of sync with the original(master) and should become the slave of the current active. This is solved by redis-proxy, which proxies the active redis. It is also smart enough to issue slave of commands to machines that start up and make masters slave of no one.
If the Active Redis crashes or goes down for maintenance, we want the application to seamlessly use (read/write) data from the backup server. This can easily be done by making the backup server 'slaveof no one'
But the problem is once the backup takes over as active new writes will go there. Now if the "original master" comes back up it will be out of sync with the "current master", so it has to be slaved to the "current master" before it is ready to start take requests.

This is solved by redis-proxy, which proxies the active redis.
It is also smart enough to issue slave of commands to machines that start up and make masters slave of no one. It also can optionally provide for reads-write splitting. i.e. Reads going to slaves, and Writes only going to master.

This reduces the common redis slave master replication dance that needs to be done when bad stuff happens or maintenance of the servers are needed

Expand All @@ -25,25 +29,24 @@ Features
* If there are multiple slaves, a round robin strategy is used.
* It lets standard non mutating commands go to the slaves( instead of the master). This will almost always improve the throughput of the cluster of Redis servers.
* Mutating commands always go to Master.
* Unknown commands(Renamed via the redis config) will go to the Master.
* Unknown commands (Renamed via the redis config) will go to the Master.


![Typical setup!](http://github.com/sreeix/redis-proxy/raw/master/docs/Typical_Setup.jpg)

Image courtesy Marlon Li([Marlon Li](https://github.com/atrun)) represents how it is being or can be used.


Configuration
==============
[Config settings](https://github.com/sreeix/redis-proxy/blob/master/config/configuration.md)

The redis-proxy uses the config file to figure out the details of the redis cluster, The configurations are documented in the [Config settings](https://github.com/sreeix/redis-proxy/blob/master/config/configuration.md)

Disclaimer
=============

We are in the process of testing it, it works for simple commands, but i have not tested and validated it against the whole set of redis commands. It is likely that commands like Pub sub don't work correctly(or at all).

Please consider this alpha software. All help and pull requests/ ideas are appreciated.


Install
=========

Expand Down Expand Up @@ -89,9 +92,7 @@ The standard scenario is each redis has a backup redis.

If Both of them go down together, We just return errors and wait for one of them to come back on.

If no redis is available at startup we raise an exception and stop. (This will change for sure.)

There can be only one master in the system.
There can be only one master in the system. This is true even if multiple redis-proxies are monitoring the cluster.

There can be multiple slaves. Each will become slave of the master, and on master doing down, one of the slave it randomly picked as master.

Expand All @@ -103,12 +104,12 @@ Redis proxy can become a single point of failure, If it goes down your redis ser

* Using Nodemon/Forever to keep the redis proxy up all the time

* Have a backup redis-proxy on Elastic IP or Virtual IP and switch manually or using keepalived.

* Have a backup redis-proxy on Elastic IP or Virtual IP and switch manually or using keepalived.
Note, however, that this is not a distributed system (like redis-sentinel). The choice of the redis server to be used is consistent. i.e if a proxy picks up the fact that master is down, then it would promote the highest slave (by runid) to master consistently.


Limitations /TODOS
============
Limitations / TODOS
===================

* Benchmarks show about 3x drop in performance(Investigating it and will post a fix soon)

Expand All @@ -118,8 +119,6 @@ Limitations /TODOS

* It currently only works as master/slave mode. And it's highly unlikely that there could be a switch to sharded mode.

* Support for Read Write Splits

* No downtime adding and removing slaves


2 changes: 1 addition & 1 deletion package.json
Expand Up @@ -2,7 +2,7 @@
"author": "Sreekanth <gabbar@activesphere.com>"
, "name": "redis-proxy"
, "description": "Proxy for redis servers, to manage redis clusters. Now supports read write splits"
, "version": "0.0.6"
, "version": "0.0.7"
, "repository": {
"type": "git"
, "url": "git@github.com:sreeix/redis-proxy.git"
Expand Down

0 comments on commit d15af5c

Please sign in to comment.