This section contains all you need to know to operate databases hosted on Redis Enterprise Software.
When enabling Causal Consistency in CRDBs, the order of operations on a specific key are maintained across all CRDB instances. For instance, if operations A and B were applied on the same key, and B was performed after the effect of A was observed by the CRDB Instance that initiated B, then all CRDB instances would observe the effect of A before observing the effect of B. This way, any causal relationship between operations on the same key is also observed and maintained by every replica.
For each database, you can enable alerts for database events, such as high memory usage or throughput. You can also enable alerts for the cluster and nodes in the [cluster alerts]](/rs/administering/cluster-operations/settings/alerts/). Configured alerts are shown: As a warning icon (for the database In the log In emails, if you configure email alerts To enable alerts for a database: In configuration for each database, click show adavnced options to see the database alerts and select the alerts that you want to get for the database.
Active-Active replicated databases (also known as CRDBs) give applications write access to replicas of the data set in different geographical locations. The participating clusters that host the instances can be in distributed geographic locations. Every instance of a CRDB can receive write operations, and all operations are synchronized conflict-free to all of the instances. Steps to Create an Active-Active Database Create a service account - On each participating cluster, create a dedicated user account with the Admin role.
Active-Passive replicated databases (also known as Replica Of) give applications read-only access to replicas of the data that are hosted in different geographical locations. The source database can be located in the same cluster, in a different cluster, or in an OSS Redis database. Your applications can connect to the source database to read and write data, or to the source or destination databases to read data. Replica Of can replicate:
You can create Redis databases that are sharded and distributed across a single RS cluster. These databases can use Redis Enterprise features like: Redis on Flash High availability Data persistence Redis modules You can create databases according to the number of shards in your subscription and the memory available on the machine. Note - For databases with Active-Active replication for geo-distributed locations, create an Active-Active database. Creating a New Redis Database To create a new database:
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: Slave shards (if database replication is enabled) Database shards (if database clustering is enabled) If the total size of the database in the cluster reaches the memory limit, the data eviction policy that was defined for the database is applied. The following examples show how different database configurations affect the total database size.
To delete a database in Redis Enterprise Software (RS): Click the relevant database row in the Databases page. The selected database page appears. Select the Configuration tab. Click Delete at the bottom of the page. Confirm the deletion.
Deleting a CRDB is a nearly identical procedure to standard Redis databases in Redis Enterprise Software, but with a critical distinction. Since CRDBs span multiple Participating Clusters, there is more extensive administrative work being done on the clusters on your behalf. When you click the button on the configuration tab to delete a CRDB, this action is an immediate, non-reversible, and has no rollback. The cluster deletes all member databases from all Participating Clusters on your behalf.
The eviction policy designates a data eviction method for Redis Enterprise Software (RS) to use when the database size reaches its limit. You can select any of the following: Policy Description noeviction Returns an error if the memory limit has been reached when trying to insert more data allkeys-lru Evicts the least recently used keys out of all keys allkeys-lfu Evicts the least frequently used keys out of all keys allkeys-random Randomly evicts keys out of all keys volatile-lru Evicts the least recently used keys out of all keys with an “expire” field set volatile-lfu Evicts the least frequently used keys out of all keys with an “expire” field set volatile-random Randomly evicts keys with an “expire” field set volatile-ttl Evicts the shortest time-to-live and least recently used keys out of all keys with an “expire” field set.
You can schedule backups of a specific database to make sure you always have valid backups. You can also export the data from a specific database at any time. You can export a database to these locations: FTP server SFTP server Amazon AWS S3 Local mount point OpenStack Swift (Object Storage) Azure Blob Storage Google Cloud Storage The backup process creates compressed (.gz) RDB files that you can import into a database.
To delete the data in a database without deleting the database configuration, you can flush the data from the database. Warning - The flush command deletes ALL in-memory and persistence data in the database. We recommend that you backup your database before you flush the data. Flushing Data from a Database From the command line, you can flush a database with the redis-cli command or with your favorite Redis client.
When you enable database replication for your database, RS 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. You can configure high availability for slave shards (slave HA) so that the cluster automatically migrates the slave shards to an available node.
You can import export or backup files of a specific database to restore data. You can either import from a single file or from multiple files, such as when you want to import from a backup of a sharded database. Warning - Importing data erases all existing content in the database. Importing data into a database To import data into a database: In databases, click on the database that you want to import data to.
When importing data into a CRDB, there are two options: Perform a flushall to the database, thus deleting all data. Then import the data into the CRDB. Import data but merge it into the existing or add new data from the import file. When using option #2, there are special considerations to be aware of. Unlike a traditional Redis database, CRDBs have a numeric counter data type and thus require special ways to increment.
On the Database > Metrics page you can view detailed real-time graphs of various database metrics, as well as shard-related metrics. Database metrics You can choose which metrics are shown in each of the two detailed graphs at the top of the page, as follows: Below the top two graphs there is a group of smaller graphs that display all available metrics, such as CPU utilization and operations per second.
You can manually export your data from a specific database at any time. You can also schedule backups of your databases to make sure you always have valid backups. The backup process can be scheduled for every 1, 4, 12 or 24 hours from the time that you save the backup configuration. You can schedule backups to these locations: FTP server SFTP server Amazon S3 Local mount point OpenStack Swift (Object Storage) Azure Blob Storage Google Cloud Storage The backup process creates compressed (.
You can change the configuration of a Redis Enterprise Software database at any time. To edit the configuration of a database: Go to Database and select the database that you want to edit. Go to Configuration and click Edit at the bottom of the page. The database settings appear. Change the any of the configurable database settings. Note - For CRDB instances, most database settings only apply to the instance that you are editing.