Considerations for planning Active-Active databases
In Redis Enterprise, Active-Active geo-distribution is based on conflict-free replicated data type (CRDT) technology. Compared to databases without geo-distribution, Active-Active databases have more complex replication and networking, as well as a different data type.
Because of the complexities of Active-Active databases, there are special considerations to keep in mind while planning your Active-Active database.
For Active-Active databases, you need to set up your participating clusters. At least two participating clusters. If your database requires more than ten participating clusters, contact Redis support. You can add or remove participating clusters after database creation.
Changes made from the admin console to an Active-Active database configuration only apply to the cluster you are editing. For global configuration changes across all clusters, use the
crdb-cli command-line utility.
Database memory limits define the maximum size of your database across all database replicas and shards on the cluster. Your memory limit also determines the number of shards.
Besides your dataset, the memory limit must also account for replication, Active-Active metadata, and module overhead. These features can increase your database size, sometimes increasing it by two times or more.
Factors to consider when sizing your database:
- dataset size: you want your limit to be above your dataset size to leave room for overhead.
- database throughput: high throughput needs more shards, leading to a higher memory limit.
- modules: using modules with your database can consume more memory.
- database clustering: enables you to spread your data into shards across multiple nodes (scale out).
- database replication: enabling replication doubles memory consumption
- Active-Active replication: enabling Active-Active replication requires double the memory of regular replication, which can be up to two times (2x) the original data size per instance.
- database replication backlog for synchronization between shards. By default, this is set to 1% of the database size.
- Active-Active replication backlog for synchronization between clusters. By default, this is set to 1% of the database size.
It’s also important to know Active-Active databases have a lower threshold for activating the eviction policy, because it requires propagation to all participating clusters. The eviction policy starts to evict keys when one of the Active-Active instances reaches 80% of its memory limit.
Network requirements for Active-Active databases include:
- A VPN between each network that hosts a cluster with an instance (if your database spans WAN).
- A network connection to several ports on each cluster from all nodes in all participating clusters.
- A network time service running on each node in all clusters.
Networking between the clusters must be configured before creating an Active-Active database. The setup will fail if there is no connectivity between the clusters.
Every node must have access to the REST API ports of every other node as well as other ports for proxies, VPNs, and the admin console. See Network port configurations for more details. These ports should be allowed through firewalls that may be positioned between the clusters.
Network Time Service
Active-Active databases require a time service like NTP or Chrony to make sure the clocks on all cluster nodes are synchronized. This is critical to avoid problems with internal cluster communications that can impact your data integrity.
See Synchronizing cluster node clocks for more information.
Several Redis modules are compatible with Active-Active databases. Find the list of compatible Redis modules.
Active-Active databases have the following limitations:
- An existing database can’t be changed into an Active-Active database. To move data from an existing database to an Active-Active database, you must create a new Active-Active database and migrate the data.
- Discovery service is not supported with Active-Active databases. Active-Active databases require FQDNs or mDNS.
FLUSHcommand is not supported from the CLI. To flush your database, use the API or admin console.
- Cross slot multi commands (such as
MSET) are not supported with Active-Active databases.
- The hashing policy can’t be changed after database creation.