入门demo
复制配置文件
一主二从,6380为主,6381和6382为从。复制三份redis.config:
分别修改配置文件pidfile、port、dbfilename避免冲突(以6380为例,其余两个类似)
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
因为我设置了密码,所以还需要给从机额外配置,不然从机连不上主机
replicaof 127.0.0.1 6380
masterauth 主机密码
启动三个实例
./redis-server ./msdemo/redis6380.conf
./redis-server ./msdemo/redis6381.conf
./redis-server ./msdemo/redis6382.conf
此时虽然启动了三个redis实例,但并不具备主从属性,可以连接redis-cli用info replication查看:
配置主从(配从不配主)
slaveof ip port
在端口6381的实例使用该命令,成功从master变为6380的slave
6382实例同理,可以看到6380已经有两个从机了。
测试:在6380上写入数据,在6381和6382读取数据,可以看到6381和6382能够读取6380写入的数据,说明主从配置生效了
常用主从方案
非专业名词,三种方案名字都是别人乱起的。
一主二从
如上面的demo
注意事项:
- 从机挂掉以后再连上不再是原来的从机了,变为独立的主机
- 从机连上主机后会将主机的数据从头读入
- 主机挂掉以后从机不做任何事情,待主机从新启动后主从关系仍在
薪火相传
此时的结构不再是星状,而是链式的,即一个slave可以是下一个的slave的master,可以减轻master的压力。其余特性和一主二从类似。如A-->B-->C,A是master,B是A的从机,B又是C的master,缺点就是当B挂掉后C不能同步A的数据。
反客为主
用slave no one......命令
当master挂掉以后,其后的slave变为master,其他slave
以上三种都需要手动干预主机的选择,非常的不方便,可以使用哨兵模式去解决。
哨兵模式
反客为主自动版,后台能够监控主机是否故障,如果故障的话可以通过投票方式选出新主机。
配置哨兵
在sentinel.conf里修改
sentinel monitor mymaster 127.0.0.1 6380 1
其中1表示至少1个哨兵同意才进行迁移
因为我从机也配置了密码,所以在哨兵模式核心配置文件中加入密码,主机与从机的密码需保持一致,不然会出现主机无法切换和哨兵检测不到从机的情况。
sentinel auth-pass mymaster ICURX0228xb?
启动哨兵
redis-sentinel msdemo/sentinel.conf
到这基本的配置就完成了,可以简单测试下,将6380主机shutdown,可以从哨兵看到,将6381选为新的主机,并且原主机6380作为其从机(只不过挂掉了)
再看6381,此时role已经变为master,并且从机连接数量为1(6382):
当我们将6380重新上线之后发现已经变为6381的从机了。
复制延迟
由于所有写都在master上,然后同步到slave,所以会有一定延迟,slave越多这个问题越严重
选举策略
优先级 > 偏移量 > runid
主机挂掉以后该选哪个从机为新主机呢?
在redis.conf中有这么一个属性,值越小优先级越高
replica-priority 100 //老版本叫slave-priority
如果优先级一样,则选择偏移量最大的(和主机同步数据最多的)
如果偏移量也一样,则选择runid最小的服务(每个redis启动时都会生成一个40位的随机的runid)
当选出新的master收,sentinel会向原主服务的从机发送【slaveof 新主机】命令。当下线的从机上线后,sentinel会向从机发送【slaveof 新主机】,让其成为新主机的从主机。