内容简介:上篇文章和小伙伴们一起搭建了 redis 主从复制环境,但是还不完善,本文我想再和小伙伴们聊聊主从复制环境搭建的一些细节。本文是 Redis 系列的第十一篇文章,了解前面的文章有助于更好的理解本文:1.
上篇文章和小伙伴们一起搭建了 redis 主从复制环境,但是还不完善,本文我想再和小伙伴们聊聊主从复制环境搭建的一些细节。
本文是 Redis 系列的第十一篇文章,了解前面的文章有助于更好的理解本文:
4. Redis 字符串 (STRING) 中 BIT 相关命令
5. Redis 列表与集合
8. Redis 快照持久化
10. Redis 主从复制(一)
本文接上文,所用三个 redis 实例和上文一致,这里就不再赘述三个实例搭建方式。
一场接力赛
在上篇文章中,我们搭建的主从复制模式是下面这样的:
实际上,一主二仆的主从复制,我们可以搭建成下面这种结构:
搭建方式很简单,在前文基础上,我们只需要修改 6381 的 master 即可,在 6381 实例上执行如下命令,让 6381 从 6380 实例上复制数据,如下:
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380 OK
此时,我们再看 6379 的 slave ,如下:
127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=1 master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:0
只有一个 slave,就 6380 ,我们再看 6380 的信息,如下:
127.0.0.1:6380> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 slave_repl_offset:70 slave_priority:100 slave_read_only:1 connected_slaves:1 slave0:ip=127.0.0.1,port=6381,state=online,offset=70,lag=0 master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:70 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:70
6380 此时的角色是一个从机,它的主机是 6379,但是 6380 自己也有一个从机,那就是 6381 .此时我们的主从结构如下图:
哨兵模式
结合上篇文章,我们一共介绍了两种主从模式了,但是这两种,不管是哪一种,都会存在这样一个问题,那就是当主机宕机时,就会发生群龙无首的情况,如果在主机宕机时,能够从从机中选出一个来充当主机,那么就不用我们每次去手动重启主机了,这就涉及到一个新的话题,那就是哨兵模式。
所谓的哨兵模式,其实并不复杂,我们还是在我们前面的基础上来搭建哨兵模式。假设现在我的 master 是 6379 ,两个从机分别是 6380 和 6381 ,两个从机都是从 6379 上复制数据。先按照上文的步骤,我们配置好一主二仆,然后在 redis 目录下打开 sentinel.conf 文件,做如下配置:
sentinel monitor mymaster 127.0.0.1 6379 1
其中 mymaster 是给要监控的主机取的名字,随意取,后面是主机地址,最后面的 2 表示有多少个 sentinel 认为主机挂掉了,就进行切换(我这里只有一个,因此设置为1)。好了,配置完成后,输入如下命令启动哨兵:
redis-sentinel sentinel.conf
然后启动我们的一主二仆架构,启动成功后,关闭 master,观察哨兵窗口输出的日志,如下:
小伙伴们可以看到,6379 挂掉之后,redis 内部重新举行了选举,6380 重新上位。此时,如果 6379 重启,也不再是扛把子了,只能屈身做一个 slave 了。
注意问题
由于所有的写操作都是先在 Master 上操作,然后同步更新到 Slave 上,所以从 Master 同步到 Slave 机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave 机器数量的增加也会使这个问题更加严重。因此我们还需要集群来进一步提升 redis 性能,这个问题我们将在后面说到。
OK,redis 主从复制问题我们就介绍这么多,更多资料小伙伴们可以参考官方文档 http://www.redis.net.cn/tutorial/3501.html。小伙伴在看官方文档时,有什么问题欢迎留言讨论。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Dive Into Python 3
Mark Pilgrim / Apress / 2009-11-6 / USD 44.99
Mark Pilgrim's Dive Into Python 3 is a hands-on guide to Python 3 (the latest version of the Python language) and its differences from Python 2. As in the original book, Dive Into Python, each chapter......一起来看看 《Dive Into Python 3》 这本书的介绍吧!