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 indicator (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.
Conflict-Free Replicated Databases (CRDBs) let you create replicated instances of your data between Redis Enterprise Software (RS) clusters. 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 to all of the instances. Steps to Create a CRDB Create a service account - On each participating cluster, create a dedicated user account with the Admin role.
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 - To create databases that are designed to be hosted in distributed locations, see Creating CRDBs.
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. Whether the slave node fails or 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 another 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. You can import data from these locations: HTTP server FTP server SFTP server Amazon S3 Local mount point OpenStack Swift (Object Storage) Warning - Importing data erases all existing content in the database.
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 Other cloud storage options, including Azure Geo-Redundant Storage and Google Cloud Storage, are planned for a future release.
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.