Redis Enterprise Active-Passive Use Cases
Last updated 18, Apr 2024
Question
What use cases are covered by a Redis Enterprise Active-Passive (created using the "Replica Of" feature) deployment?
Answer
Data migration
Using the "Replica Of" feature, it is possible to migrate from a Redis Enterprise database or from Redis OSS Server to a target Redis Enterprise database for a data migration use case.
Data Consolidation
Multiple master databases can be replicated into a single database. This feature can consolidate the data from multiple databases into a single database. Watch out: keys with conflicting names will be overwritten in the target replica database; it is a good practice to have different namespaces for the different databases. As an example, in order to consolidate the data from the hhrr and devs databases, the corresponding keyspaces might be prefixed with hhrr: and devs:.
Scaling down a database
Redis Enterprise allows vertical scaling (or "scaling up") by resharding a database and thus allowing multiple shards to take advantage of multiple resources across one or several Redis Enterprise nodes. Scaling down is not possible in Redis Enterprise, so if the requirement is to reduce the number of shards of a database, a new database shall be created with the desired amount of shards, this new database should then replicate the data of the original database (using the "Replica Of" feature), and then finally the former database will be dismissed later when the migration is complete.
Disaster Recovery
A replica database (initially passive) can be promoted to be a master replica. Client applications should divert the workload to the replica in case the master database is unavailable. Database replicas should be created in a different cluster.
Reads Scalability
Read scalability to one database or multiple database replicas. A Redis Enterprise database can be replicated to one or more database replicas to increase read-only throughput. Replicas can be hosted in the same source database cluster or in different remote clusters.
Active-Passive and Active-Active
Note that in case of connection errors, the replica synchronization may restart from the last position or may be subject to a full resync from the source, causing a large amount of data to be transferred and loaded into the database replica. Refer to the synchronization errors from the documentation pages. Because of such side scenarios, it might be preferable to configure an Active-Active geo-distributed database, which can tolerate network partitioning better than an Active-Passive database. Using Active-Active may be especially convenient for disaster recovery. When the replica is used as a standby database, the sizing model for the Active-Active database may be relaxed if no conflicts are possible (the sizing model for an Active-Active database usually doubles the amount of memory required for the data, while an Active-Active replica only used for disaster recovery may have a more convenient amount of allocated memory). If you resort to Active-Active, verify the modules' capabilities: not all the modules support Active-Active (e.g., RedisGraph).