Getting Started is Instant and Free!





By creating your account, you agree to our Terms of Service



Forgot your password?

Not Registered?

Forgot your password?

Enter your email address below to have your password reset. We'll send you an email with a link to change your password.

Your IP address will be logged and monitored for this request.


Cancel

Your password has reset!

We have sent you an email with a link to change your password.

OK

Blog

Posted on by Garantia Data

Scaling Out Redis: Read-Only Slaves or Cluster?

Thankfully, no humans are enslaved by Redis.

Instead, it uses asynchronous replicationfor scalability ... or simply for data redundancy.

Also, “a [Redis] master can have multiple slaves … [that] are able to accept other slaves’ connections. Aside from connecting a number of slaves to the same master, slaves can also be connected to other slaves in a graph-like structure.

Setting up Redis replication is trivial and its flexibility provides great power.
Classic use cases for Redis’ replication are:

  1. Scaling performance by using the replicas for intensive read operations.
  2. Making data redundant in multiple locations.
  3. Offloading data persistency costs from the master by delegating it to the slaves.

As a Redis Service provider, we are often asked why we do not provide access to our read-only replicas. It’s a valid question, and our answer relates to each of the use cases:

  1. Scaling


    Our service scales by allocating resources to the databases that we manage. We deploy clusters on which we create database instances. Each database instance is sharded across the cluster’s members and each of the shards is split-able, highly available, relocatable and dynamically (re)sizable. To provide for more reads (or writes, RAM, CPUs, or bandwidth), we just reshard and rebalance as needed. Our cluster immediately and transparently provides access to the new shards, hence there is no need to access read-only replicas.
  2. Redundancy


    We use replication for data redundancy at the shard level. Our redundancy is augmented with monitoring and auto-failover mechanisms that are internal to our service and do not require any user intervention.
  3. Load


    Our replicas are configured to manage data persistency so the master shard is free to process requests.

Since replication is asynchronous, it can introduce inconsistencies when accessing stale data. Sharding, on the other hand, does not exhibit that property and is therefore a preferable approach to addressing read and write scaling challenges. Because our managed service addresses scalability (via sharding), redundancy (with auto-failover) and load management, there are only a handful of scenarios in which having access to the read replicas is of any value.

For example, a replica can be set up to give read-only database access to interested parties (e.g. development).

We are planning to support this functionality in the future, so if you have other use cases for read replicas we’d love to hear about them. Let us know if you are using replication for purposes other than scaling, redundancy or offloading - just drop us a line at info@garantiadata.com or contact our support.

about us

Redis Labs offers enterprise-class Redis and Memcached for developers. Our fully-managed cloud services - Redis Cloud and Memcached Cloud - deliver top performance in a highly-available, infinitely scalable, predictable and stable manner.

We power tens of thousands of customer apps in multiple cloud environments and enhance use cases such as real time analytics, social app functionality, job management, and geo-search.

Redis Labs has more than 2,600 paying customers and has raised $13M in venture funding from Bain Capital Ventures, Carmel Ventures, and others.

Interact with Redis Cloud

Enter your Redis commands,
see how fast it responds!

Redis Cloud > |

See Our Open Source Contributions

Redis Watch

Get the hottest Redis news with our
periodic newsletter!