# redis-主从复制和高可用 [TOC] ## 一、 主从复制 ### 1. 主从复制简介 redis的主从复制，使用的是异步复制，主服务器可以有多个从服务器，从服务器也可以再接从服务器。复制功能不会阻塞主服务器，如果在配置文件redis.conf中进行相应的设置，复制功能也不会阻塞从服务器。在从服务器删除旧版本数据集并载入新版本数据集的那段时间内，连接请求会被阻塞。 复制功能可以单纯地用于数据冗余，也可以通过让多个从服务器处理只读命令请求来做到读写分离。 可以通过复制功能来让主服务器免于执行持久化操作：只要关闭主服务器的持久化功能，然后由从服务器去执行持久化操作即可。 ### 2. 主从复制的安全性 当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话要避免主服务器宕机后被自动拉起。 考一下以下会导致主从服务器数据全部丢失的例子： 1. 假设节点A为主服务器，并且关闭了持久化。并且节点B和节点C从节点A复制数据 2. 节点A崩溃，然后由自动拉起服务重启了节点A.由于节点A的持久化被关闭了，所以重启之后没有任何数据 3. 节点B和节点C将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。 无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。 ### 3. 主从复制的原理 1) 图片说明   2) 文件说明 1. 第一步:无论是初次连接还是重新连接，当建立一个从服务器时，从服务器都将向主服务器发送一个SYNC命令。 2. 第二步:接到SYNC命令的主服务器将开始执行BGSAVE创建rdb文件，并在保存操作执行期间，将所有新执行的写入命令都保存到一个缓冲区里面。 3. 第三步:当BGSAVE执行完毕后，主服务器将执行保存操作所得的.rdb文件发送给从服务器，从服务器接收这个.rdb文件，并将文件中的数据载入到内存中。 4. 第四步:之后主服务器会以Redis命令协议的格式，将写命令缓冲区中积累的所有内容都发送给从服务器。 3) 多从和重连 即使有多个从服务器同时向主服务器发送SYNC，主服务器也只需执行一次BGSAVE命令，就可以处理所有这些从服务器的同步请求。 从服务器可以在主从服务器之间的连接断开时进行自动重连，从服务器可以根据主服务器的情况来选择执行完整重同步[2.8以前]还是部分重同步[2.8以后] ### 4. 主从数据一致性保证 ```sh min-slaves-to-write 1 min-slaves-max-lag 2 ``` * 运作原理： 从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。主服务器会记录各个从服务器最后一次向它发送 PING 的时间。 用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。 如果至少有 min-slaves-to-write 个从服务器，并且这些服务器的延迟值都少于 min-slaves-max-lag秒，那么主服务器就会执行客户端请求的写操作。 可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性，但起码丢失数据的窗口会被严格限制在指定的秒数中。 另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件,那么写操作就不会被执行,主服务器会向请求执行写操作的客户端返回一个错误。 ### 5. 主从复制的实现 准备两个或两个以上redis实例 ```sh mkdir /data/redis_m/638{0..2} ``` 1) 配置文件示例 6380 ```sh cat >/data/redis_m/6380/redis.conf <<'EOF' port 6380 daemonize yes pidfile /data/redis_m/6380/redis.pid loglevel notice logfile "/data/redis_m/6380/redis.log" dbfilename dump.rdb dir /data/redis_m/6380 protected-mode no EOF ``` 6381 ```sh cat >/data/redis_m/6381/redis.conf <<'EOF' port 6381 daemonize yes pidfile /data/redis_m/6381/redis.pid loglevel notice logfile "/data/redis_m/6381/redis.log" dbfilename dump.rdb dir /data/redis_m/6381 protected-mode no EOF ``` 6382 ``` cat >/data/redis_m/6382/redis.conf <<'EOF' port 6382 daemonize yes pidfile /data/redis_m/6382/redis.pid loglevel notice logfile "/data/redis_m/6382/redis.log" dbfilename dump.rdb dir /data/redis_m/6382 protected-mode no EOF ``` 2) 启动 ```sh redis-server /data/redis_m/6380/redis.conf redis-server /data/redis_m/6381/redis.conf redis-server /data/redis_m/6382/redis.conf ``` 3) 开启主从 redis主从只需要在从节点设置主库信息即可 6381 ```sh redis-cli -p 6381 SLAVEOF 127.0.0.1 6380 ``` 6382 ```sh redis-cli -p 6382 SLAVEOF 127.0.0.1 6380 ``` 4) 主从状态查询 ```sh 127.0.0.1:6382> info replication ``` ### 6. 手动切换主从 1) 模拟主库故障 ```sh redis-cli -p 6380 shutdown ``` 2) 启用6381为主 ```sh redis-cli -p 6381 info replication slaveof no one ``` 3) 6382连接新主 ```sh redis-cli -p 6382 127.0.0.1:6382> SLAVEOF no one 127.0.0.1:6382> SLAVEOF 127.0.0.1 6381 ``` ## 二、redis高可用[redis-sentinel哨兵] ### 1. redis-sentinel简介 Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。 ### 2. 主要功能 1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。 2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。 ### 3. 实现原理 1. 发现主服务器 Sentinel 通过用户给定的配置文件来发现主服务器,并与主服务器创建连个网络连接,命令连接用于向主服务器发送命令,订阅连接用于订阅指定的频道. 2. 发现从服务 Sentinel 通过向主服务器发送 INFO 命令来自动获得所有从服务器的地址,并与每个被发现的从服务器创建命令连接和订阅连接。 3. 发现其他serntinel Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息[IP、端口号、ID 等]，以此来向其他 Sentinel 宣告自己的存在。并通过订阅连接接收其他 Sentinel 的“HELLO” 信息，以此来发现监视同一个主服务器的其他 Sentinel Sentinel 之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介，所以 Sentinel之间不会创建订阅连接 4. 检测实例状态 Sentinel 使用 PING 命令来检测实例的状态：如果实例在指定的时间内没有返回回复，或者返回错误的回复，那么该实例会被 Sentinel 判断为主观下线。 如果多个sentinel交流后判断这个服务器下线了,这个时候才是真正的下线,也叫客观下线.所以生成环境一般使用的是奇数个sentinel,实例被多数哨兵认为判断才会真的下线 ### 4. 故障转移步骤 * 发现主服务器已经进入客观下线状态。 * 基于Raft leader election协议 ，进行投票选举 如果选举失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试选举。 如果选举成功， 那么执行以下步骤。 * 选出一个从服务器，并将它升级为主服务器。 * 向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。 * 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新。 * 向已下线主服务器的从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器。 * 当所有从服务器都已经开始复制新的主服务器时， leader Sentinel 终止这次故障迁移操作。 ### 5. 高可用哨兵搭建 这里只安装一个哨兵,但实际环境中,一般都会用到3个哨兵共同协作,防止脑裂和单机网络故障导致切换 1) 创建目录 ```sh mkdir /data/redis_m/26380 cd /data/redis_m/26380 ``` 2) 创建配置文件 ```sh cat >>sentinel.conf <<'EOF' port 26380 dir "/data/redis_m/26380" sentinel monitor mymaster 127.0.0.1 6380 1 sentinel down-after-milliseconds mymaster 5000 sentinel config-epoch mymaster 0 EOF ``` 3) 启动哨兵 ```sh redis-sentinel /data/redis_m/26380/sentinel.conf & ``` 4) 故障转移演练 ```sh # 停主库测试： [root@db01 ~]# redis-cli -p 6380 shutdown # 查看新主库信息 [root@db01 ~]# redis-cli -p 6381 info replication # 启动源主库[6380]看状态。 原主库会自动被加入到主从环境做从库 ``` ### 6. 参数解释和常用命令 1)配置文件参数 ``` sh # 指定监控master sentinel monitor mymaster 127.0.0.1 6370 2 {2表示多少个sentinel同意} # 安全信息 sentinel auth-pass mymaster root # 超过多久后认为主机宕机 sentinel down-after-milliseconds mymaster 15000 # 当主从切换多久后认为主从切换失败 sentinel failover-timeout mymaster 900000 # 同时最多2个slave可更新配置 sentinel leader-epoch mymaster 2 # 确认mymater SDOWN时长 sentinel config-epoch mymaster 1 ``` 2)sentinel命令 ```sh PING # 返回 PONG 。 SENTINEL masters # 列出所有被监视的主服务器 SENTINEL slaves <master name> # 列出指定从库 SENTINEL get-master-addr-by-name <master name> # 返回给定名字的主服务器的 IP 地址和端口号。 SENTINEL reset <pattern> # 重置所有名字和给定模式 pattern 相匹配的主服务器。 SENTINEL failover <master name> # 当主服务器失效时，在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移。 ```