Redis之主从复制

定义：主机数据更新后根据配置策略，自动同步到备的Master/slave机制，Master以写为主，Slave以读为主。

Tip：配从(从库)不配主(主库)

1.从库配置：

　　slave of 主库IP 主库端口

　　每次与master断开连接后，都需要重新连接，除非配置到redis.conf文件中

2.修改配置文件的操作细节：

　　一.修改进程管道文件：pidfile

　　二.修改端口：port

　　三.修改log文件名称

　　四.修改dump.rdb名称

　　五.开启daemonize yes

3.常用3招(三个窗口端口分别为：6379、6380、6381，后面内容均已此三个端口描述）：

　　一. 一主二仆（6379为主，6380、6381为仆） :

　　　　

　　　　 分别启动三个redis配置，在6380、6381上执行：slaveof 主机的IP 主机端口(例：slaveof 127.0.0.7 6379),使用命令 info replication 查看主备详情

　　　　

　　　　笔记：1.从机不能进行写操作（只能读）

　　　　　　　2.主机(6379)存储数据后，从机(6380、6381)执行slaveof命令，会将主机所有数据备份到从机上来

　　　　　　   3.主机宕掉，从机还是slave角色，并不会上位成为master,链接状态变为down

　　　　　　　4.主机从新启动后，还是master角色，从机的连接状态变为up

　　　　　　　5.从机宕了，恢复后不再与之前的主机有关联，角色变为master,想要变为从机，需要再次执行命令slaveof

　　这种一主二仆的模式过于中心化，全部围绕一个主机来做数据备份，下面介绍薪火相传(一个节点接一个节点)的模式

　　二. 薪火相传 :

　　　　　

　　　　　　在6381上执行slaveof 127.0.0.1 6380，我们发现，6380既是6379的从机又是6381的主机

　　　　　　在6379上执行写的命令，在6381上同样能拿到

　　　　　　

　　三. 反客为主 （主机宕掉，从 从机重新选举一个作为新的主机）:

　　　　　

　　　命令：slaveof no one (使当前数据库停止与其他数据库同步，转成主数据库)

　　　 操作步骤：

　　　　　　　1. 将三台redis还原回一主二仆的环境(6379为主机，6380与6381作为6379的从机)

　　　　　　　2. 将6379关掉(模拟线上宕机情况),

　　　　　　　3. 在6380中执行命令slaveof no one

　　　　　　　4. 将6381改成6380的从机

　　　　　　　5. 重新将6379启动

　　    我们发现，6380变成了主机，底下连了一台6381从机，当6379重新连接后，底下没有挂任何从机（区别于一主二仆）

　　　

4.复制原理：

　　 1. Slave连接到Master后发送一个sync命令，Master接到命令启动后台的存盘进程(同时收集所有接收到的修改数据的命令集[主库写操作]），后台进程完成后，Master将传送整个数据文件到slave来完成一次同步

　　 2. 全量复制：第一次slaveof到主库的时候（接收到数据文件后，将其存盘并加载到内存中）

　　 3. 增量复制：除第一次slaveof外，从库以后都是增量存储数据（接收主库传来的修改命令）

5.哨兵模式（类似反客为主的自动版）：

　　举例：生产环境，如果凌晨主机宕了，从机通过投票自动选举新的主机

　　 操作步骤：

　　　　1. 调整环境现在主机是6379，从机为6380与6381

　　　　2. # cd /usr/local/bin (redis的启动目录)

　　　　3. # touch sentinel.conf (配置哨兵监控哪台主机，如果主机挂了，从机如何进行投票选举新的主机，名字绝对不能错)

　　　　4. # vim sentinel.conf，在sentinel.conf加入如下内容： sentinel monitor host6379 127.0.0.1 6380 1

　　             host6379：被监控的主机名称(自己取)

　　　　　　  1代表主机宕掉后，剩余的从机如果谁的票数多余1票，就将作为新的主机

　　　　5. 启动哨兵模式，执行命令：redis-sentinel sentinel.conf，你会看到如下图案：

　　　　　　

　　　　　从图中发现，哨兵开始巡逻6380与6381，只要6379挂掉，那么这两台从机就开始投票，谁票数多谁上位。

　　　　5. 将主机6379 shutdown，我们看到terminal窗口中出现如下信息：

　　　　　　

　　    　　结论：

　　　　　　　　6381变成了新的主机，

　　　　　　　   6380变成了6381的从机

　　　　　　　　重新将关闭后的6379启动，6379变成了6381的slave

6.复制的缺点：

　　由于所有的写操作都在Master上，然后同步到Slave,所以Master同步到Slave上有一定的延迟，当系统繁忙的时候，延迟问题会加重，Slave机器数量的增加也会导致问题更加严重

总结：

　　工作中一般都是哨兵模式