We just released a new version of Redis Enterprise – v5.4.2 and are happy to announce that we’ve added a much requested feature. One of the big highlights of this release is improved compatibility for active-active Redis (through CRDBs, or conflict-free replicated databases) COUNTER operations with open source Redis.
Redis Enterprise 5.4.2 also contains other new features and capabilities, such as:
Prior to version 5.4.2, we treated COUNTERs as a different data type in Redis. In some scenarios, this created conflicts with the way users were used to working with Redis. For instance, unlike SETting a value and then incrementing it using the INCR command in open source Redis, with CRDBs, once you SET a value you couldn’t increment it because it was not treated as a COUNTER.
Since one of the main ideas behind CRDBs is to allow applications to smoothly migrate from a standard Redis deployment to an active-active deployment, we realized that this design must be changed. From now on, any CRDB COUNTER operations will be treated in the exact same manner they are treated in Redis. For example, Redis will check the encoding of the data before applying an operation, so an INCR operation will only succeed if the value is encoded as an integer. CRDBs will now follow this same algorithm.
The above CRDB improvement also applies to other Redis data types, such as Redis Hashes that contain and use Strings.
In order to update String data type behavior for CRDBs, we made changes to its internal structure and the communication protocol between CRDB instances. To enjoy these improvements, you’ll need to install Redis Enterprise version 5.4.2 and then upgrade your existing CRDB deployment. This will automatically execute the required Redis server restart. Newly created CRDBs will benefit from active-active compatibility.
The CRDB protocol is backward-compatible, which means that Redis Enterprise 5.4.2 CRDB instances that use the new protocol can understand write operations from instances on versions below 5.4.2. However, it is not forward-compatible, so CRDB instances with the old protocol cannot understand write operations of instances with the newer protocol version. As a result, after you upgrade the CRDB protocol on one instance, other instances that are not yet upgraded may not be able to sync from the upgraded instance, although the upgraded instance will receive updates from both upgraded and non-upgraded instances.
Therefore, we highly recommend that you upgrade all instances of a specific CRDB within a reasonable time frame to avoid temporary inconsistencies between them.
In order to upgrade the protocol of your CRDBs, follow these upgrade instructions.
For any questions, don’t hesitate to drop us a line at firstname.lastname@example.org!