NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Achieving Zero-Downtime Redis Upgrades

☞ A simple notice about a short scheduled GitHub downtime resulted in a great dialog about how to perform zero downtime Redis upgrades. The following approaches were suggested:

  1. using Redis replication (i.e. SLAVE OF) to move existing data from the old Redis to the new Redis and haproxy to transparently pass client requests to the Redis instance (initially to the existing version and once replication completed to the new one)
    1. Leave the old redis version running on, say, redis:6379.
    2. Install and start a new redis on redis:6380 with a different dump file location.
    3. Execute SLAVE OF redis 6379 against redis:6380. Wait for first SYNC to complete.
    4. echo "enable server redis/redis-6380" | socat stdio unix-connect:/var/run/haproxy/admin.sock
    5. echo "disable server redis/redis-6379" | socat stdio unix-connect:/var/run/haproxy/admin.sock
    6. Execute SLAVE OF no one on redis:6380.
    7. Execute SHUTDOWN on redis:6379.
  2. using virtual IPs instead of haproxy

A more generic idea shared in the comment thread was to architect the solution so that the overall system would continue to work even if some subsystems are temporarily down. If you think in terms of the CAP theorem, this idea could be translated as a system that is AP at all times.

While writing this post I remembered reading about a ☞ solution based on node.js. node.js would be used to proxy requests until it is notified that the back system goes down. It would temporarily hold incoming connections until it would be notified again that the back system is resuming.

Any other ideas?