是什么
主节点的数据同步到从节点上,主节点负责写,从节点负责读。
能干嘛
- 读写分离
- 容灾恢复
怎么玩
1.配从(库)不配主(库)
2.从库配置:slaveof 主库IP 主库端口 (每次与master断开之后,都需要重新连接,除非配置进redis.conf文件)
3.修改配置文件细节操作
- 拷贝多个redis.conf文件
- 开启 daemonize yes
- Pid文件名字 (如 pidfile "/var/run/redis_6380.pid")
- 指定端口 (如 port 6380)
- Log 文件名字 (如 logfile "6380.log")
- Dump.rdb名字 (如 dbfilename "dump6380.rdb")
常用方法
- 一主二仆 (此时并没有将slaveof写进配置文件)
即一个Master两个Slave,现设定6379的为master,6380、6381为slave。
master所写的内容slave都能读取到(包括6380和6381成为slave之前6379所写的内容)
如果slave对master设置的键值进行修改会发生什么?
这说明slave只负责读取。
如果发生一些故障导致master挂了,那slave如何表现呢?是翻身做master还是继续当slave?
很明显,此时角色还是为slave。
如果master又回来了,那slave是继续跟着master干,还是不再听指挥了呢?
在当前配置下,slave还是会继续跟着master。
如果某个slave挂了(这里假设端口为6380的挂了),当这个slave又启动的时候会发生什么?是继续跟着原来的master还是自己当master?
在这种情况下slave会自己成为master。
- 薪火相传
上一个slave可以是下一个slave的master,slave同样可以接收其他slave的连接和同步请求,那么改slave作为链中下一个的master,可以有效减轻master的写压力。
让6379成为master,6380成为6379的slave,6381成为6380的slave(虽然在逻辑上6380既为master又为slave,但在计算机中显示仍为slave)。
- 反客为主
使用slaveof no one命令:使当前库停止与其他库的同步,转成主库。
复制原理
slave启动成功连接到master后会发送一个sync命令,master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步。
全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:master继续将新的所有收集到的修改命令依次传给slave,完成同步。
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行。
复制的缺点
- 复制延时
由于所有的写操作都是先在master上操作,然后同步更新到slave上,所以master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。
哨兵模式(sentinel)
是什么
反客为主的自动版,能够后台监控主机是否出现故障,如果故障了根据投票数自动将从库转换为主库。
使用步骤
- 调整结构,6379带着6380、6381
- 自定义的目录(我的为 /myredis)下新建 sentinel.conf 文件,名字绝不能错
- 配置哨兵,填写内容(sentinel monitor 被监控数据库名字(自己起名字)127.0.0.1 6379 1 【此处的1表示主机挂掉后slave投票看让谁接替成为主机,得票数多少后成为主机】)
- 启动哨兵(redis-sentinel /myredis/sentinel.conf)
让6379挂掉,则会从6380和6381中投票选出新的master。
问题:如果此时6379回来了,那结果又当如何呢?是否会造成双master冲突?