We discussed in our previous tutorial, about redis server & its installation. In this tutorial, we will learn to create a redis cluster or rather a master slave setup for redis server. With master slave setup, both the servers will be identical copies of each other & in the event master fails then we can use slave server as master until we have fixed the master server. So let’s start with the process,
(Recommended Read : Installing MEMCACHED in Ubuntu & RHEL/CentOS )
(Also Read : How to install or upgrade PHP version to PHP 7 )
Pre-requisites
We will need to servers with redis installed (check out our redis installation tutorial), one of the server will act as master & other one as slave. For purpose of this tutorial, setup information is as follows,
Master server
IP address – 192.168.1.10 Redis port number – 6379
Slave server
IP address – 192.168.1.11 Redis port number – 6379
We will now start with the configuration on the redis server.
Configuration (MASTER)
We only need to make couple of changes in master redis instance, open the redis instance configuration file i.e. /etc/redis/6379.conf,
$ vi /etc/redis/6379.conf |
Then look for paramter ‘bind’ & change it to,
bind 0.0.0.0 |
Next, search for parameters ‘appendonly’ & ‘appendfilename’ , then change them to,
appendonly yes appendfilename "appendonly.aof" |
These are the only changes required in master server. Save file , then exit & restart the redis instance to implement the changes made,
$ service redis_6379 restart OR systemctl restart redis_6379 |
Configuration (SLAVE)
Now we will make changes to slave configuration file i.e. /etc/redis/6379.conf. To make the changes, open the file with vi editor
$ vi /etc/redis/6379/conf |
As we did for master, search & change the ‘bind’ parameter
bind 0.0.0.0 |
Next search for parameter ‘slaveof’, this parameter is where we mention our master server IP address & redis instance port number,
slaveof 192.168.1.10 6379 |
Save file, then exit & restart the redis service,
$ service redis_6379 restart OR systemctl restart redis_6379 |
Verifying master slave setup
Now that we have made the necessary changes on both, master & slave, servers, we will verify if our setup is working as expected or not. To check if the master slave setup is working, connect to the master redis instance using the following command,
$ redis-cli -h 192.168.1.10 -p 6379 |
& execute the command 'info',
192.168.1.10:6379> info |
In the result, head down to 'Replication' section
# Replication role:master connected_slaves:1 Slave0: ip=192.168.1.11, port=6379, state=online, offset=215, lag=0 master_repl_offset:215 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:214 |
here you can see information about all the slaves connected to the master redis instance. This shows that our master slave replication is working. We can further carry out another test to make sure that data replication among master & slave is working fine by creating a test key-value in master & then it should get replicated to slave.
To create a test key-value, login to redis instance & execute the following command,
192.168.1.48:6379> set test "testing" |
now to check the key on master, run command 'get test'
192.168.1.48:6379> get test "testing" |
Now, login to slave server & check if the key 'test' has been replicated or not,
$ redis-cli -h 192.168.1.152 -p 6379 |
& run 'get test' command,
192.168.1.152:6379> get test "testing" |
This shows that key has been replicated to the slave server as well & our master slave data replication is working fine.
Promoting redis SLAVE as MASTER
In the event master server fails, we can then promote the slave server to act as the backup master server, so that redis server can continue to work while we resolve the issues on the master server. To promote redis slave server as master, connect to slave instance
$ redis-cli -h 192.168.1.152 -p 6379 |
& run the following command,
192.168.1.152:6379> SLAVEOF NO ONE OK |
Our slave server will now act as a master server.
Note:- If we have 2 or more slaves connected to master , then we need to run the command 'SLAVEOF 192.168.1.152 6379' to make them point towards the new master server.
Reconnecting original master server
Once the original master server is up, we will demote the slave server (that was promoted to master) & reconnect it as slave to original master server by executing,
192.168.1.152:6379> SLAVEOF 192.168.1.48 6379 |
Then run the same command on other slave servers as well.
(OPTIONAL) Setting password authentication for the redis instances
In order to set password authentication for a redis instance, open configuration file for the redis instance i.e. '/etc/redis/6379.conf' & uncomment 'requirepass' parameter,
$ vi /etc/redis/6379.conf requirepass redis |
here, 'redis' is the password for the instance. Save file & exit, then restart the service to implement the changes,
$ service redis_6379 restart |
Now login to the instance,
$ redis-cli -h 192.168.1.48 -p 6379 |
We will not be prompted for password, we need to execute command 'AUTH' followed by password,
$ 192.168.1.48:6379> AUTH redis |
Once authenticated, we can use the redis instance as needed. If we try to run any command without authenticating, we will receive an error,
192.168.1.48:6379> info NOAUTH Authentication required. |
Authentication when using master-slave setup
If the master server uses a password for the redis instance, then we need to provide that password while configuring slave server otherwise master slave replication will not work. To do so open the slave instance configuration file,
$ vi /etc/redis/6379.conf |
& uncomment 'masterauth' parameter & add the master instance password,
masterauth redis |
That’s it & our cluster is now secured with a password.
This is also completes our tutorial, do leave your comments/queries in the comment box below.
If you think we have helped you or just want to support us, please consider these :-
Connect to us: Facebook | Twitter | Google Plus
Become a Supporter - Donate us some of you hard earned money: [paypal-donation]
Linux TechLab is thankful for your continued support.
How does this work from the ‘client side’? for example … ownCloud can specify two servers.
Should I only specify one server – and if redis goes down – manually promote slave as master, manually change the redis server address in the owncloud config / reload?
Yes, that’s exactly what needs to be done. But i will check for any other way.
At this step, Reconnecting original master server : – when you bring back the Original Master server, you need to ensure you take a backup of .rdb file from the promoted master and copy it to the reconnected Master. I have noticed that the data changes will be vanished after we bring back the Original Master node meaning data syncs from Master to Slave instead of promoted slave to reconnected Master server.
Thanks for that valuable info.
Could we set the original master to be a slave instance of the temp master and then we will switch their role back?
yes, we can & the process is similar to one mentioned here.
Superb tutorial
With thanks! Valuable information!
why is appendonly a required configuration change?