Redis主从复制

四、主从复制原理

1.主从复制特点

1.使用异步复制。
2.一个主服务器可以有多个从服务器。
3.从服务器也可以有自己的从服务器。
4.复制功能不会阻塞主服务器。

#详细：
1.Redis 使用异步复制。从 Redis2.8开始，从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。
2.一个主服务器可以有多个从服务器。
3.不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构（级联复制）
4.复制功能不会阻塞主服务器：即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。
5.复制功能也不会阻塞从服务器：只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。
6.在从服务器删除旧版本数据集并载入新版本数据集的那段时间内，连接请求会被阻塞。
7.还可以配置从服务器，让它在与主服务器之间的连接断开时，向客户端发送一个错误。
8.复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说，繁重的SORT命令可以交给附属节点去运行。

2.主从复制原理

1.从服务器开启主从
2.从库向主库发送 SYNC 命令
3.接到 SYNC 命令的主服务器会调用 BGSAVE 命令创建一个 RDB 文件
4.创建RDB文件同时将新写入的数据写入缓冲区
5.主库将RDB文件推送到从库
6.从库清空自己的数据，读取RDB文件
7.主库将缓冲区的数据传到从库执行

3.主从复制机制

1）PSYNC只会将从服务器断线期间缺失的数据发送给从服务器。两个例子的情况是相同的，但SYNC 需要发送包含整个数据库的 RDB 文件，而PSYNC 只需要发送三个命令。

2）如果主从服务器所处的网络环境并不那么好的话（经常断线），那么请尽量使用 Redis 2.8 或以上版本：通过使用 PSYNC 而不是 SYNC 来处理断线重连接，可以避免因为重复创建和传输 RDB文件而浪费大量的网络资源、计算资源和内存资源。

五、配置主从

1.环境准备

角色	主机	端口
主库	172.16.1.51	6379
从库	172.16.1.51	6380
从库	172.16.1.51	6381

2.连接上3台机器

[root@db01 ~]# redis-cli -p 6379
127.0.0.1:6379>

[root@db01 ~]# redis-cli -p 6380
127.0.0.1:6380>

[root@db01 ~]# redis-cli -p 6381
127.0.0.1:6381>

3.查看主从状态

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379

4.配置主从

#配置
127.0.0.1:6380> SLAVEOF 172.16.1.51 6379
OK

#查看主从状态
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:172.16.1.51
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1

#配置文件配置主从
[root@db01 ~]# vim /service/redis/6381/redis.conf 
bind 127.0.0.1 172.16.1.51
port 6381
daemonize yes
pidfile /service/redis/6381/redis_6381.pid
loglevel notice
logfile "/service/redis/6381/redis.log"
slaveof 172.16.1.51 6379

[root@db01 ~]# redis-cli -p 6381 shutdown
[root@db01 ~]# redis-server /service/redis/6381/redis.conf

[root@db01 ~]# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:172.16.1.51
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:43
slave_priority:100
slave_read_only:1

六、主库故障解决

1.模拟主库故障

[root@db01 ~]# redis-cli shutdown

2.找一台从库提升为主库

#主库down机从库仍然是只读
127.0.0.1:6380> set k2 v2
(error) READONLY You can't write against a read only slave.

#停止主从
127.0.0.1:6380> SLAVEOF no one
OK

#查看状态，只要停止主从，就变成主库
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3.将其他redis配置成新的主库的从库

127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6381> SLAVEOF 172.16.1.51 6380
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:172.16.1.51
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:1
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

七、哨兵sentinel介绍

1.什么是哨兵sentinel

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

2.sentinel结构

Sentinel 是一个监视器，它可以根据被监视实例的身份和状态来判断应该执行何种动作。

3.sentinel功能

1.监控（Monitoring）：
Sentinel会不断地检查你的主服务器和从服务器是否运作正常。

2.提醒（Notification）：
当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。

3.自动故障迁移（Automatic failover）：
当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

4.sentinel工作内容

1.sentinel可以通过配置发现主服务
	Sentinel会与被监视的主服务器创建两个网络连接：
	命令连接用于向主服务器发送命令。
	订阅连接用于订阅指定的频道，从而发现监视同一主服务器的其他Sentinel。
2.Sentinel通过向主服务器发送INFO命令来自动获得所有从服务器的地址。
3.发现其他的Sentinel
4.Sentinel之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收HELLO信息的中介，所以Sentinel之间不会创建订阅连接。
5.Sentinel使用PING命令来检测实例的状态：如果实例在指定的时间内没有返回回复，或者返回错误的回复，那么该实例会被 Sentinel 判断为下线。
	Redis的Sentinel中关于下线（down）有两个不同的概念：
	1）主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
	2）客观下线（Objectively Down，简称 ODOWN）指的是多个Sentinel实例在对同一个服务器做出SDOWN判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的服务器下线判断。（一个 Sentinel可以通过向另一个Sentinel发送SENTINEL is-master-down-by-addr命令来询问对方是否认为给定的服务器已下线。）

5.故障转移流程

1.发现主服务器已经进入客观下线状态。
2.基于Raft leader election协议,进行投票选举
3.如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。
4.选出一个从服务器，并将它升级为主服务器。
5.向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
6.通过发布与订阅功能，将更新后的配置传播给所有其他Sentinel，其他Sentinel对它们自己的配置进行更新。
7.向已下线主服务器的从服务器发送SLAVEOF命令，让它们去复制新的主服务器。
8.当所有从服务器都已经开始复制新的主服务器时， leader Sentinel 终止这次故障迁移操作。

#每当一个Redis实例被重新配置（reconfigured）—— 无论是被设置成主服务器、从服务器、又或者被设置成其他主服务器的从服务器 —— Sentinel 都会向被重新配置的实例发送一个CONFIG REWRITE命令，从而确保这些配置会持久化在硬盘里。

6.sentinel选择主库的规则

1.在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的从服务器都会被淘汰。
2.在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的从服务器都会被淘汰。
3.在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有最小运行ID的那个从服务器成为新的主服务器。

7.Sentinel自动故障迁移的一致性特质

1）Sentinel自动故障迁移使用Raft算法来选举领头（leader）Sentinel ，从而确保在一个给定的周期（epoch）里，只有一个领头产生。
2）这表示在同一个周期中， 不会有两个 Sentinel 同时被选中为领头，并且各个 Sentinel 在同一个节点中只会对一个领头进行投票。
3）更高的配置节点总是优于较低的节点，因此每个 Sentinel 都会主动使用更新的节点来代替自己的配置。

#简单来说，我们可以将Sentinel配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他Sentinel。