Redis 主从配置

就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

主要功能

• 读写分离

• 容灾恢复

配置方法

• 配从(库)不配主(库)

• 从库配置：slaveof 主库IP 主库端口

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

  • Info replication：可以查看Redis主从情况

修改配置文件细节操作

1. 拷贝多个redis.conf文件

2. 开启daemonize yes

3. Pid文件名字

4. 指定端口

5. Log文件名字

6. Dump.rdb名字

配置三台Redis，端口分别为 6379、6380、6381

修改配置

# Redis 6379
cp redis.conf redis6379.conf

daemonize yes
pidfile /var/run/redis6379.pid
port 6379
logfile "6379.log"
dbfilename dump6379.rdb

# Redis 6380
cp redis.conf redis6380.conf

daemonize yes
pidfile /var/run/redis6380.pid
port 6380
logfile "6380.log"
dbfilename dump6380.rdb

# Redis 6381
cp redis.conf redis6381.conf

daemonize yes
pidfile /var/run/redis6381.pid
port 6381
logfile "6381.log"
dbfilename dump6381.rdb

一主二从

主Redis不用改变。

分别使用三个配置文件启动Redis，使用redis客户端连接Redis。

6380、6381执行SLAVEOF 127.0.0.1 6379命令，将自己设置为从数据库，复制6379的数据

使用 Info replication 查看主从情况

注意

1. 从机是复制主机的所有数据

2. 从机Redis只能get，不能set

3. 主Redis宕机后，从Redis不变。

4. 从Redis宕机后，主Redis不变，从Redis变为Master，主从体系断开。

5. 如果主从配置写入配置文件，则重启后继续主从模式，否则需要重新配置

薪火相传

配置文件不变

6380执行SLVAEOF 127.0.0.1 6379命令

6381执行SLVAEOF 127.0.0.1 6380命令

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力

反客为主

主机宕机后，从机将变为主机。

SLAVEOF no one 命令可以使当前数据库停止与其他数据库的同步，转成主数据库。

6381执行SLVAEOF 127.0.0.1 6380命令

复制原理

1. Slave启动成功连接到master后会发送一个sync命令

2. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步（全量复制）

3. 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步

哨兵模式(*)

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

配置方法

1.调整结构，6379带着80、81

2.自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

配置哨兵,填写内容

sentinel monitor 被监控数据库名字(自己起名字)127.0.0.1 6379 1

上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

3.启动哨兵 redis-sentinel /myconf/sentinel.conf

4.如果原master挂了，则后台监视器会自动投票，从从机中选出新的master

5.如果以前的master回来了，则他会自动变成slave，并挂到新的master下面

一组sentinel能同时监控多个Master

复制缺点

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