Managing Database

• A Redis instance supports 16 logical databases. These databases are effectively siloed off from one another, and when you run a command in one database it doesn’t affect any of the data stored in other databases in your Redis instance.

• Redis databases are numbered from 0 to 15 and, by default, you connect to database 0 when you connect to your Redis instance. However, you can change the database you’re using with the select command after you connect:

127.0.0.1:6379> select 15

• If you’ve selected a database other than 0, it will be reflected in the redis-cli prompt:

127.0.0.1:6379[15]>

Transfering the data from one database to another

• To swap all the data held in one database with the data held in another, use the swapdb command.

127.0.0.1:6379> swapdb 6 8

• swapdb will swap the data held in database 6 with that in database 8, and any clients connected to either database will be able to see changes immediately.

• swapdb will return OK if the swap is successful.

Keys

Migrate

• If you want to move a key to a different Redis instance, you can run migrate. This command ensures the key exists on the target instance before deleting it from the source instance.

• When you run migrate, the command must include the following elements in this order:

  • The hostname or IP address of the destination database

  • The target database’s port number

  • The name of the key you want to migrate

  • The database number where you want to store the key on the destination instance

  • A timeout, in milliseconds, which defines the maximum amount of idle communication time between the two machines. Note that this isn’t a time limit for the operation, just that the operation should always make some level of progress within the defined length of time

127.0.0.1:6379> migrate 203.0.113.0 6379 key_1 7 8000

Additionally, migrate allows the following options which you can add after the timeout argument:

• COPY: Specifies that the key should not be deleted from the source instance

• REPLACE: Specifies that if the key already exists on the destination, the migrate operation should delete and replace it

• KEYS: Instead of providing a specific key to migrate, you can enter an empty string ("") and then use the syntax from the keys command to migrate any key that matches a pattern.

Commands

• rename will rename the specified key. If it’s successful, it will return OK:

127.0.0.1:6379> rename old_key new_key

• randomkey will return a random key from the currently selected database:

127.0.0.1:6379> randomkey

• type to determine what type of data the given key holds. This command’s output can be either string, list, hash, set, zset, or stream:

127.0.0.1:6379> type key_1

If the specified key doesn’t exist, type will return none instead.

• move to move an individual key to another database in your Redis instance with the. move takes the name of a key and the database where you want to move the key as arguments.

127.0.0.1:6379> move key_1 8

move will return OK if moving the key was successful.

• del is used to delete one or more keys of any data type

127.0.0.1:6379> del key_1 key_2

If this command deletes the key(s) successfully it will return (integer) 1. Otherwise, it will return (integer) 0.

• unlink command performs a similar function as del, with the difference being that del blocks the client as the server reclaims the memory taken up by the key. If the key being deleted is associated with a small object, the amount of time it takes for del to reclaim the memory is very small and the blocking time may not even be noticeable.

  However, it can become inconvenient if, for example, the key you’re deleting is associated with many objects, such as a hash with thousands or millions of fields. Deleting such a key can take a noticeably long time, and you’ll be blocked from performing any other operations until it’s fully removed from the server’s memory. unlink, however, first determines the cost of deallocating the memory taken up by the key. If it’s small then unlink functions the same way as del by the key immediately while also blocking the client. However, if there’s a high cost to deallocate memory for a key, unlink will delete the key asynchronously by creating another thread and incrementally reclaim memory in the background without blocking the client.

127.0.0.1:6379> unlink key_1

Since it runs in the background, it’s generally recommended that you use unlink to remove keys from your server to reduce errors on your clients.

• flushdb to delete all the keys in the selected database,

flushdb

• flushall to delete all the keys in every database on a Redis server (including the currently selected database),

flushall

Both flushdb and flushall accept the async option, which allows you to delete all the keys on a single database or every database in the cluster asynchronously. This allows them to function similarly to the unlink command, and they will create a new thread to incrementally free up memory in the background.

• To create a backup of the currently selected database, you can use the save command:

save

This will export a snapshot of the current dataset as an .rdb file, which is a database dump file that holds the data in an internal, compressed serialization format.

save runs synchronously and will block any other clients connected to the database. Hence, the save command documentation recommends that this command should almost never be run in a production environment.

• bgsave command tells Redis to fork the database: the parent will continue to serve clients while the child process saves the database before exiting:

bgsave

Note that if clients add or modify data while the bgsave operation is occurring, these changes won’t be captured in the snapshot.