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行后面