上篇文章给大家介绍了Redis的主从复制,但是并没有介绍完整,本文继续主从复制的介绍
实现方式也很简单,我们只需要在6381上执行如下命令即可
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
如此6380是一个从机,而6380还有一个slave是6381.至此实现了我们上面的结构图
复制数据没有问题
结合上篇文章我们给大家介绍了两种主从复制的模式,但是我们发现不论是哪种模式,一旦master宕机了,那么整合服务就不可以使用了,此时我们希望系统能在还运行的slave中从新选举新的节点作为mater这样我们就不用重启服务了。能够显著的提高我们系统的稳定性,这里就需要用到我们将要介绍的哨兵模式。
我们还是一主两从,按照上篇文章的结构来实现。
修改和redis.conf同级目录下的sentinel.conf文件
sentinel monitor mymaster 127.0.0.1 6379 1
mymaster 是要监控的主机名 可以随意的取 最后的1 表示的是哨兵进程的个数,我在此处只有1个。
先关闭主从服务,然后开启哨兵模式
src/redis-sentinel sentinel.conf
再分别启动主从服务器
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis6379.conf
[root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6379
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis6380.conf
[root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis6381.conf
[root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6379
查看6379状态
关闭6379等待一会查看哨兵进程界面
当看到如上图的信息后,我们再查看6380的时候,发现该节点已经变成了master了。
再启动6379我们发现该实例依然是slave并不会改变
注意在主从复制中所有的写入操作都是在master实例上进行的,然后再将信息同步到slave上,这就存在一定的信息延迟,在系统非常繁忙的时候延迟会更加的严重,增加slave也会存在这个问题,因此在实际开发中我们需要通过集群(cluster)来进一步提升redis的性能,下篇文章将给大家介绍redis的集群操作。
~本文介绍到此,更多信息欢迎查阅官方文档:http://www.redis.net.cn/tutorial/3501.html