Redis主从复制

概念

主从复制模型中，有多个redis节点。

其中，有且仅有一个为主节点Master。从节点Slave可以有多个。

只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。

特点

  • 主节点Master可读、可写.

  • 从节点Slave只读。（read-only）

因此，主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。

环境准备

主节点 IP 角色
node1 172.16.10.11 Redis Master
node2 172.16.10.12 Redis Slave
node3 172.16.10.13 Redis Slave

安装redis

在所有节点安装

1yum -y install epel-release
2yum -y install redis

修改监听端口，默认监听127.0.0.1，仅本机可以访问

1sed -i '/^bind/s/127.0.0.1/0.0.0.0/' /etc/redis.conf

Master运行redis

1systemctl enable --now redis

Slave节点开启主从复制。

1sed -i '/^# slaveof/a\slaveof 172.16.10.11 6379' /etc/redis.conf

Slave运行redis

1systemctl enable --now redis

查看主从状态

 1redis-cli info replication
 2# Replication
 3role:master
 4connected_slaves:2
 5slave0:ip=172.16.10.12,port=6379,state=online,offset=43,lag=0
 6slave1:ip=172.16.10.13,port=6379,state=online,offset=43,lag=0
 7master_repl_offset:43
 8repl_backlog_active:1
 9repl_backlog_size:1048576
10repl_backlog_first_byte_offset:2
11repl_backlog_histlen:42

可以看到已经是一主两从的模式了

测试

在主节点上，进行读写操作，操作成功

1redis-cli set name jerry
2OK
3
4redis-cli get name
5"jerry"

在从节点上,读操作执行成功，并且成功从master上同步了数据,写操作执行失败。（从节点，只能读，不能写）

1redis-cli get name
2"jerry"
3
4redis-cli set age 30
5(error) READONLY You can't write against a read only slave.

Sentinel哨兵模式

主从模式的缺陷

当主节点宕机了，整个集群就没有可写的节点了。

由于从节点上备份了主节点的所有数据，那在主节点宕机的情况下，Sentinel哨兵的作用能够将从节点变成一个主节点。

哨兵的任务

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

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

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

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

监控（Monitoring）

  • Sentinel可以监控任意多个Master和该Master下的Slaves。（即多个主从模式）

  • 同一个哨兵下的、不同主从模型，彼此之间相互独立。

  • Sentinel会不断检查Master和Slaves是否正常。

自动故障切换（Automatic failover）

在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。

故障切换的过程

（1）投票（半数原则）

当任何一个Sentinel发现被监控的Master下线时，会通知其它的Sentinel开会，投票确定该Master是否下线（半数以上，所以sentinel通常配奇数个）。

（2）选举

当Sentinel确定Master下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。

其它Slaves节点，转为该节点的从节点。

（3）原Master重新上线

当原Master节点重新上线后，自动转为当前Master节点的从节点。

哨兵模式部署

前提：已经存在一个正在运行的主从模式。

另外，配置三个Sentinel实例，监控同一个Master节点。

配置Sentinel

 1sed -i '/^# bind/a\bind 0.0.0.0' /etc/redis-sentinel.conf
 2sed -i '/^sentinel monitor/s/127.0.0.1/172.16.10.11/' /etc/redis-sentinel.conf
 3
 4# 查看配置信息
 5grep -Ev '^$|^#' /etc/redis-sentinel.conf
 6bind 0.0.0.0
 7port 26379
 8dir /tmp
 9sentinel monitor mymaster 172.16.10.11 6379 2
10sentinel down-after-milliseconds mymaster 30000
11sentinel parallel-syncs mymaster 1
12sentinel failover-timeout mymaster 180000
13logfile /var/log/redis/sentinel.log

运行sentinel

1systemctl enable --now redis-sentinel

测试

（1）停止Master节点，查看日志

1systemctl stop redis

（2）再次查看redis情况，Slave1节点成为了新的主节点。

 1redis-cli info replication
 2# Replication
 3role:slave
 4master_host:172.16.10.12
 5master_port:6379
 6master_link_status:up
 7master_last_io_seconds_ago:1
 8master_sync_in_progress:0
 9slave_repl_offset:86815
10slave_priority:100
11slave_read_only:1
12connected_slaves:0
13master_repl_offset:0
14repl_backlog_active:0
15repl_backlog_size:1048576
16repl_backlog_first_byte_offset:0
17repl_backlog_histlen:0

好了，使用sentinel实现了高可用集群，那么master会经常变，需要怎么连接呢？很简单，连接sentinel节点，sentinel记录了master的节点信息。

1redis-cli -p 26379 info sentinel
2# Sentinel
3sentinel_masters:1
4sentinel_tilt:0
5sentinel_running_scripts:0
6sentinel_scripts_queue_length:0
7sentinel_simulate_failure_flags:0
8master0:name=mymaster,status=ok,address=172.16.10.12:6379,slaves=2,sentinels=3

设置密码

redis设置密码，需要修改一下这几个地方（主从节点都需要配置）

1sed -i '/^# requirepass/a\requirepass password' /etc/redis.conf
2sed -i '/^# masterauth/a\masterauth password' /etc/redis.conf
3
4# sentinel也需要配置密码认证
5sed -i '/^sentinel monitor mymaster/a\sentinel auth-pass mymaster password' /etc/redis-sentinel.conf

备注：一定要放在sentinel monitor mymaster 172.16.10.13 6379 2行后面