As of today, Redis high availability databases are generally available on Scalingo, adding replication and high availability to our current single node offer based on the leader-follower mechanism and Redis Sentinel.
How is Redis High Availability Implemented?
Redis embeds both redundancy through a leader-follower mechanism and high availability thanks to Sentinel.
The leader-follower mechanism is both easy to use and focused on high performance. It allows followers to be the exact copy of the leader asynchronously. The followers automatically reconnect to the leader in case of trouble. This mechanism ensure redundancy in a multi-nodes setup.
On the high availability side, Redis provides Sentinel, a piece of software to setup a Redis deployment resilient to failures. Sentinel constantly check the healthiness of leader and followers and start the failover process if the leader becomes unreachable. Failover is the process of promoting an instance to leader, and ensuring other followers will follow this new leader.
Using a multi-nodes setup provides redundancy and high availability.
Redis High Availability on Scalingo
When you provision a Redis cluster on Scalingo, we start a couple of data instances and three Sentinel. Thanks to this replication setup, if an instance fails for whatever reason, your database will still be accessible without any downtime.
In order to get that running magically, we took advantage of the work done along with Elasticsearch cluster. Here is the network setup for Redis multi-nodes:
From the client’s point of view (such as your application), there is a single
entry point to the cluster, namely the HAProxy master. Thus the environment
variable injected into the context of your application still contains only one
domain name. This variable takes the form:
When your application queries the Redis database, it enters the private network through the gateway (a HAProxy server), forwarding the requests to the Redis leader instance.
There are two redundancy layers in effect to increase your database availability:
- To prevent the gateway to be a single point of failure, a second one is started as a failover. In case of failing master, the IP address used by the HAProxy master is automatically assigned to the second one. This is achieved using our own virtual IP manager, LinK. Hence you never need to change your environment variable!
- To prevent the Redis leader to be a single point of failure, a follower is started as a failover in case the first one is down. All the queries are directed to the leader. The follower follows the write queries directed to the leader to have the same data as the leader. The follower is always ready to be designated leader. In case the master is down, the sentinels detect it and designate the follower as master. In the meantime, the HAProxy servers also detect it and when the sentinels did their job, HAProxy automatically direct the queries to the newly elected Redis master instance. Thus your application is always able to reach your database master instance!
To increase the security of your Redis deployment, instances are booted in a dedicated private network.
TLS (Almost) Everywhere
Redis does not allow for connection using TLS out-of-the-box. Thanks to this new setup, Scalingo Redis databases now support TLS connection from your client to your Redis database.
TLS encrypted communication between Redis nodes inside Scalingo private network is slightly harder to setup and is not ready yet. We are working hard to bring you this privacy improvement as soon as possible!
Note that Redis drivers for most languages support TLS connections. Prefixing
your Redis connection string with
rediss:// instead of
redis:// might do the
As usual, by default your database is not reachable from outside Scalingo’s network. As announced last year, to make it reachable from anywhere around the world, you can now force TLS communication to connect to your Redis database.
How to Take Advantage of Redis High Availability?
This feature is available as part of new plans for your database. If you start a new database, you will be prompted to choose a plan. All the Business plans include cluster with two nodes holding the data, two gateway nodes, and three Sentinel. The first cluster ready version is 4.0.14-1. It is the 1st Scalingo revision of the version 4.0.14 of Redis.
For an existing database, getting a cluster takes a few steps. First, upgrade to the latest 4.0.14-1 version. It will start your database with a mono-node setup (i.e. a Redis instance in its own private network with a single gateway). Then you can change the plan in the “Addons” section of your application to choose a Business plan. Your database will migrate seamlessly from a mono-node setup to a highly available setup.
After upgrading your plan to a Business plan, your database is highly available and Scalingo ensure a 99.99% availability of your data. Moreover, updating to a more recent version is achieved with zero downtime!
You don’t have to worry about data portability: your Redis database is completely standard (the base Docker images are open source) and you can retrieve all your data by querying it or download a backup.
New Business plans
Former mono-node plans are now available under the new plans category Starter while the old Free tier is now available under the name Sandbox.
Now there are 3 pricing categories:
- Sandbox contains only 1 plan and should only be used for development purposes. No SLA is offered on this plan.
- Starter plans offers mono-node deployment (no high availability) but all of them includes automatic daily backups.
- Business plans are the ones you’re looking for if you’re doing production stuff: redundancy all the way and improved availability.
You’ll find the new pricing grid below:
As of today, all old plans are obsolete and are not available for new add-ons provisioning. As a matter of fact, all Scalingo Redis add-ons running the old free tier plan will be discontinued on June 30th and automatically transformed into the new Sandbox plan (which has the exact same memory capacity).
If you have questions or remarks regarding the new pricing plans or the new cluster feature, don’t hesitate to contact us. We’d love to hear your feedbacks!
What’s coming up next?
In the coming weeks, we will keep walking down the high availability by releasing PostgreSQL clusters. Stay tuned!