Redis-主从复制

简介

主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
可以做读写分离，容灾恢复等

实例

1主2从

1. 复制2份配置文件redis.conf，并命名为redis6380.conf和redis6381.conf
   
2. 修改配置文件内容

#################redis6379.conf###################
#启用守护进程
daemonize yes
#指定pidfile文件名称
pidfile /var/run/redis6379.pid
#指定端口号
port 6379
#指定日志文件
logfile "redislog6379.log"
#指定dump.rdb文件名称
dbfilename dump6379.rdb
#################redis6380.conf###################
#启用守护进程
daemonize yes
#指定pidfile文件名称
pidfile /var/run/redis6380.pid
#指定端口号
port 6380
#指定日志文件
logfile "redislog6380.log"
#指定dump.rdb文件名称
dbfilename dump6380.rdb
#################redis6381.conf###################
#启用守护进程
daemonize yes
#指定pidfile文件名称
pidfile /var/run/redis6381.pid
#指定端口号
port 6381
#指定日志文件
logfile "redislog6381.log"
#指定dump.rdb文件名称
dbfilename dump6381.rdb

3. 开启3个redis服务
   在redis安装目录下，通过指定配置文件启动redis服务
   
4. 分别进入3个redis客户端，并运行命令info replication查看redis服务的主从复制信息
   默认都为主服务：
   
5. 开启6380和6381为从服务，形成6379为主服务，6380和6381为从服务(1主2从)
   注意：此种在客户端开启的从服务，当从服务关闭并重新开启时，并不会自动恢复为从服务，除非把该种配置写进配置文件
   
6. 检查主从复制
   

链式依赖

以1主2从为例，6379为master，6380和6381为slave，关联关系如下：

当master挂逼时，处于原地待命状态，除非master重新回归，否则两个slave会一直处于无法工作状态。

于是采用另一种模式，链式依赖：

6379为master
6380即为master也为slave
6381为slave

当master挂逼时，处于6380处于无人管束状态，会自动升级成为master：

如何开启？

在三个redis客户端中执行命令：
6379：无需操作，默认为master
6380：SLAVEOF 192.168.0.113 6379
6381：SLAVEOF 192.168.0.113 6380

手动指定master

含义：当master挂逼时，让指定的salve充当master

开启步骤
挂逼前：
6379：
无需操作，默认为master
6380：
SLAVEOF 192.168.0.113 6379
6381：
SLAVEOF 192.168.0.113 6379
挂逼后：
6380：
SLAVEOF no one
6381：
SLAVEOF 192.168.0.113 6380

在这里插入图片描述
master(6379)挂逼前：

master(6379)挂逼后：

当master(6379)回归时，此时6379为单机master，即无slave；6380和6381形成一对新的主从关系

哨兵模式

手动指定master的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

1. 调整主从结构，6379为master，6380/6381为slave
   
2. 在redis的自定义的配置文件目录(/usr/script/redis)下新建sentinel.conf文件
   
3. 配置sentinel.conf，填写内容

#格式：sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
#最后的1的含义：表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
sentinel monitor host6379 192.168.0.113 6379 1

4. 启动哨兵

#在redis安装目录下执行
redis-sentinel /usr/script/redis/sentinel.conf 

5. 主从演示
   略

6. 原有master(6379)挂逼
   可见哨兵在重新进行选举，并选出6381为新master
   

7. 新主从关系继续开工，查看6381的info replication，并检查是否能够正常复制
   

8. 当6379重新复活回归，则6379为新的slave
   

主从复制缺点

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。