# 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.&#x20;

```
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.&#x20;
* 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 <a href="#managing-keys" id="managing-keys"></a>

* `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.&#x20;

* `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.

