Gain insights into Redis's capabilities as a database, cache, and message broker. Delve into commands, transactions, and clustering. Explore flexibility, security, and data structure support with Redis.

Redis.tar.gz

Redis is an open-source, in-memory data structure store used as a database, cache, and message broker. Unlike Memcached, it supports multiple data types, giving a lot of flexibility to the user. Redis is easy to configure and provides clustering support to store data in multiple servers.

In this course, you will learn about the various commands that you can use to store different types of data structures in Redis. Some of those commands include utility, insertion, and modification commands.

You will also become familiar with different aspects of Redis, such as transactions, security, partitioning, and clustering. In all, this is your go-to guide to Redis.

Complete Guide to Redis

In the previous lesson, we discussed the concept of replication in Redis. Now it is time to see how replication can be configured in Redis. There are two ways to configure a Redis server as a slave.
1. Provide the `slaveof` property in the `redis.conf` file. This property takes two parameters, i.e., the host and the port of the master. An example of how this can be written in the conf file is shown below.
> `slaveof` 127.0.0.1 6379

When this Redis instance is started, it will automatically connect to the master server.

2. We can use the `REPLICAOF` command to convert a Redis instance into a slave. Here are a few important points about this command:
*  **REPLICAOF hostname port** will make the server a replica of another server listening at the specified hostname and port.
* If a server is already a slave and **REPLICAOF hostname port** is run on this server with different hosts, it will become the slave of a new master. It will delete the data of the old master and replicate the data of the new master.
* **REPLICAOF NO ONE** will convert a slave into a master. If a master is done, then this command can be used to convert its slave to the master. Later when the old master is up, it can be configured to become a slave.

# Read-only replicas
By default, replicas are read-only. However, this behavior can be controlled using the `replica-read-only` property in the redis.conf file. If a replica is not read-only, it will accept write commands, but as soon as it syncs with master, the data written only on the replica will be lost. This raises the question of why we would need to write data to a replica if it is going to be deleted after syncing with the master. There are certain use cases in which this may be required. We may compute some data using the keys that are frequently used. This can be stored on the writable replica. This type of data is called *ephemeral data*.

# Authenticating a replica with the master
In the [Redis Security](https://www.educative.io/courses/complete-guide-to-redis/redis-security), we discussed that we can set a password for the master, and in order for a client to connect to the master, they must know the password. Similarly, a replica(slave) must also be aware of the master password to connect to it. There are two ways through which we can provide the master password to a slave.
1. If the slave is already running, the following command can be used to authorize it with the server.
> config set masterauth *&lt;password&gt;*
2. We can also provide the master password in the redis.conf file of slave using the `masterauth` property, as shown below.
> masterauth *&lt;password&gt;*

# Minimum slaves configuration
We can configure the master to only accept writes if a certain number of slaves are connected to it. This does not ensure that the replica will actually receive all the writes. There are still some chances of data loss, but the chances are reduced.

A slave usually sends a ping to the master every second but it may get delayed. The time  that has passed from when the last ping was sent is called the **lag**, e.g., if a master received a ping 5 seconds ago, the lag is five seconds. We can configure a master to stop accepting writes if there are less than N slaves connected, having a lag less than or equal to M seconds. This is done using the two parameters shown below:

```
min-slaves-to-write <number of replicas>
min-slaves-max-lag <number of seconds>
```

If `min-slaves-to-write` is set to 3 and `min-slaves-max-lag` is set to 10, it means that at least three slaves must have pinged the master within the last ten seconds.

Setting one or the other to 0 disables the feature. By default, min-slaves-to-write is set to 0 (feature disabled) and min-slaves-max-lag is set to 10.


  







Let’s discuss how to configure replication in Redis.

Let's Begin

Redis Commands

Redis Advanced Concepts

Redis Cluster

Appendix

Configuring Replication in Redis