Redis Labs Enterprise Cluster (RLEC) powers production Redis deployments in multiple business scenarios, delivering blazing fast performance in a highly available and scalable manner.
We are excited to announce that we just released RLEC version 4.3, which features several enhancements and improvements that will increase your database’s performance, high availability and security, while reducing your Total Cost of Ownership (TCO).
RLEC v4.3 delivers the following major enhancements:
- Support for Redis on Flash (Flash memory used as an extension of RAM)
- Diskless replication in both master and slave
- SSL encryption for database connections
There are many more features, enhancements and bug fixes included in this release, such as: rladmin CLI enhancements, rlcheck installation verification utility, multi-IP configuration through the UI, cluster failure recovery instructions, and support for additional operating systems, such as RHEL/CentOS 6.6, 7.1, 7.2, RHEL 6.7 and Oracle Linux 6.5.
Below is an overview of our key updates. You can read full details in the release notes.
Support of Redis on Flash
RLEC is now available on Flash with the same blazing fast sub-millisecond latencies attained when running Redis on RAM. The breakthrough technology behind this product uses Flash as a RAM extension, rather than as persistent storage.
The global key list and all ‘hot’ values are kept in RAM, while all ‘cold’ values (which typically account for the larger part of the dataset) are kept in Flash. A multi-threaded, asynchronous Redis is used when accessing objects on Flash, utilizing multi-core and Flash concurrency architectures. The product is fully compatible with all Redis clients, data types and commands.
In many cases, RLEC Flash can save up to 70% in resource costs when compared to an all-RAM deployment. RLEC Flash characteristics and features are identical to those of standard RLEC.
Database replication provides a mechanism to ensure high availability. When replication is enabled, your dataset is replicated to a slave copy, which is constantly synchronized with the master. If the master fails, an automatic failover occurs and the slave is promoted to be the new master. When the old master recovers, it becomes the slave of the new master. This auto-failover mechanism guarantees data is served with minimal to no interruption.
By default a full master-slave replication (or a full sync) uses the file-on-disk mechanism, which saves the data from the master to the disk, and then reads the data from the disk to populate the slave. A similar process happens on the slave, when the slave first writes the received RDB file to disk and then loads it to its memory.
In RLEC 4.3, major improvements were made to database replication performance by using diskless replication between master and slave. The data between the master and slave is streamed directly from the master to the slave memory, instead of using the default file-on-disk mechanism — significantly accelerating the replication process. This behavior can be configured for the cluster as a whole or per database. With this new mechanism, the replication process is much faster and consumes fewer resources. As a result, it frees up capacity and improves overall system performance.
Please note – RLEC also supports Redis partial sync replication, which means that if the master and slave lose synchronization, the backlog of requests not at the slave are still in the master’s memory and will be re-transmitted, thus avoiding a full replication cycle.
Securing database connections using SSL
Many of our enterprise customers would like to apply the same security standards to Redis that are used elsewhere in their organization. To address this need we’ve added the option of using SSL to encrypt traffic between the client and the Redis endpoint. Furthermore, we’ve added client-based SSL authentication, which significantly strengthens the default authentication mechanism supported by Redis.
To connect to a database configured with SSL encryption, you can either use one of the Redis clients that inherently support SSL encryption or create a secured tunnel between any Redis client machine and the RLEC nodes.
We are already working on our next release which will include many more useful features — stay tuned.
If you have any questions or feedback don’t hesitate to reach out to me at: email@example.com