This section contains all you need to know to maintain Redis Enterprise Software (RS) databases.
Your data is critical to your business and securing is one of your top priorities. This section shows how you can secure access to your data and secure your data in transit.
- Replica shards (if database replication is enabled)
- Database shards (if database clustering is enabled)
When you enable Causal Consistency in Active-Active databases, the order of operations on a specific key are maintained across all Active-Active database instances.
When you set a database’s memory limit, you define the maximum size the database can reach in the cluster, across all database replicas and shards, including:
When you delete a database, the database configuration and data are deleted.
The eviction policy defines the methodology that Redis Enterprise Software uses when the database exceeds the memory limit.
When you enable database replication for your database, Redis Enterprise Software replicates your data to a slave node to make sure that your data is highly available. If the slave node fails or if the master node fails and the slave is promoted to master, the remaining master node is a single point of failure.
With Active-Active databases, applications can read and write to the same data set from different geographical locations seamlessly and with latency less than 1 ms, without changing the way the application connects to the database. Active-Active databases also provide disaster recovery and accelerated data read-access for geographically distributed users. If you have data in a single-region Redis Enterprise Software database that you want to migrate to an Active-Active database, you’ll need to create a new Active-Active database and migrate the data into the new database as a Replica Of the existing database.
You can change the configuration of a Redis Enterprise Software (RS) database, for example the number of shards or evicton policy, at any time.