> For the complete documentation index, see [llms.txt](https://dailyjournal.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dailyjournal.gitbook.io/notes/databases/non-relational-databases/redis/managing-database.md). # 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](https://redis.io/commands/save) 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.