image.png
Rdis 的主从复制特点
image.png
1. 配置主从
实现方式同样有两种: 命令方式和配置文件方式
命令方式
只需要在从服务器上执行如下命令即可
slaveof 主服务器的IP 端口号
slaveof
命令是异步的,不阻塞。
并且此时,从服务器现有的数据会先被清空,之后再同步主服务器的数据。
停止一台从服务器的复制操作,在此台服务器上执行如下命令
slaveof no one
配置文件的方式如下
只需要在从服务器上配置即可
修改配置文件
假如主服务器 IP 是: 172.16.153.178
端口是: 6379
# slaveof <masterip> <masterport>
slaveof 172.16.153.178 6379
// 配置此服务器只提供读取操作
slave-read-only yes
之后重启从主机的 Redis 服务
查看主从信息
127.0.0.1:6379> info replication
Sentinel
哨兵模式Redis Sentinel是Redis官方的高可用性解决方案。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:
- 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器。
此种模式下,客户端要访问的 服务 IP 不是主节点,而是 sentiner
服务器的 IP。
架构图
image.png
Redis Sentinel 故障转移
image.png
架构的扩展应用
image.png
1. 配置主从
a. 快速生成主节点的配置文件
编译全新文件 /etc/redis/redis-6380.conf
, 添加如下内容
port 6380
daemonize yes
protected-mode no
pidfile /var/run/redis-6380.pid
logfile /var/log/redis-6380.log
dir /redis/data/
假如是多个主机实现的,就需要更改为
protected-mode yes
,
并且添加 bind 0.0.0.0
b. 快速生成从节点的配置文件
[root@s1 ~]# sed 's/6380/6381/g' /etc/redis/redis-6380.conf > /etc/redis/redis-6381.conf
[root@s1 ~]# sed 's/6380/6382/g' /etc/redis/redis-6380.conf > /etc/redis/redis-6382.conf
查看配置文件内容,检验配置结果
[root@s1 ~]# cat /etc/redis/redis-6381.conf
port 6381
daemonize yes
pidfile /var/run/redis-6381.pid
logfile /var/log/redis-6381.log
dir /redis/data/
[root@s1 ~]# cat /etc/redis/redis-6382.conf
port 6382
daemonize yes
pidfile /var/run/redis-6382.pid
logfile /var/log/redis-6382.log
dir /redis/data/
[root@s1 ~]#
c. 配置主从关系
[root@s1 ~]# echo "slaveof 172.16.153.178 6380" >> /etc/redis/redis-6381.conf
[root@s1 ~]# echo "slaveof 172.16.153.178 6380" >> /etc/redis/redis-6382.conf
[root@s1 ~]#
d. 启动服务,并验证进程
[root@s1 ~]# /usr/local/bin/redis-server /etc/redis/redis-6380.conf
[root@s1 ~]# /usr/local/bin/redis-server /etc/redis/redis-6381.conf
[root@s1 ~]# /usr/local/bin/redis-server /etc/redis/redis-6382.conf
[root@s1 ~]# ps -ef |grep redis
root 4335 1 0 19:30 ? 00:00:03 /usr/local/bin/redis-server *:6380
root 4490 1 0 20:17 ? 00:00:00 /usr/local/bin/redis-server *:6381
root 4495 1 0 20:17 ? 00:00:00 /usr/local/bin/redis-server *:6382
root 4500 3755 0 20:17 pts/0 00:00:00 grep --color=auto redis
[root@s1 ~]#
假如日志中出现如下警告信息
4668:S 17 Feb 20:28:42.107 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
4668:S 17 Feb 20:28:42.107 # Server initialized
4668:S 17 Feb 20:28:42.108 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
4668:S 17 Feb 20:28:42.108 * DB loaded from disk: 0.000 seconds
4668:S 17 Feb 20:28:42.110 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
解决办法
The TCP backlog...
方法1: 临时设置生效:
shell> sysctl -w net.core.somaxconn=1024
方法2: 永久生效:
修改/etc/sysctl.conf文件,增加一行
net.core.somaxconn=1024
然后执行命令
sysctl -p
WARNING overcommit_memory ...
方法1: 临时设置生效:
shell> sysctl -w vm.overcommit_memory=1
方法2: 永久生效:
修改/etc/sysctl.conf文件,增加一行
vm.overcommit_memory=1
然后执行命令
sysctl -p
e. 查看主从复制信息
image.png
2. 配置 sentinel
获取程序
Sentinel 程序可以在编译后的 src 文档中发现, 它是一个命名为 redis-sentinel 的程序。
运行一个 Sentinel 所需的最少配置如下所示:
Redis 源码中包含了一个名为 sentinel.conf
的文件, 这个文件是一个带有详细注释的 Sentinel 配置文件示例。
运行一个 Sentinel 所需的最少配置如下所示:
// 监控一个 Redis 服务器
// 名称为 mymaster ,IP 为 127.0.0.1 端口为 6380
// 最后的 2 是指最少有 2 给 Sentinel 实例同意一台 redis 服务器宕机,才会认为 客观下线。
// sentinel monitor 自定义的主节点名称 主节点的 IP 主节点端口 票数
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 3000
// 180 秒后开始故障自动装换
sentinel failover-timeout mymaster 5000
sentinel parallel-syncs mymaster 1
各个选项的功能如下:
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
parallel-syncs
选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
最终的配置文件
sentinel-27000.cn
daemonize yes
port 27000
dir "/tmp"
logfile "27000.log"
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 5000
sentinel parallel-syncs mymaster 1
哨兵的领导者选举
票数和领导者选举有关系
领导者选举的事件发生,必须满足下面的条件
max(票数, (哨兵的个数 / 2) + 1 )
个哨兵参加选举
才可以选举出领导者,从而完成故障转移。
比如有 5 个哨兵, 配置的票数是 4
max(4, (5 / 2) + 1)
max(4, 3.5)
4 最大
结果就是需要 4 个哨兵参与选举才可以。
a. 获取并修改配置文件
快速创建三个 sentinel 配置文件
进入到 Redis 源码的目录下,执行如下命令
image.png
修改监听端口
image.png
之后在每个 sentinel
配置文件中添加守护进程方式运行,
并修改dir
配置项的目录,
daemonize yes
dir /redis/data/
logfile "sentinel-${port}.log"
最后别忘了修改监控的主服务器的 IP 和端口正确的 6380
最终其中一个的配置文件应该是这样的
image.png
b. 启动服务并验证
启动服务的语法:
shell> redis-sentinel sentinel的配置文件
image.png image.png
可以使用以下命令查看哨兵的信息
[root@s1 ~]# redis-cli -p 27001 info
...略...
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=2,sentinels=3
[root@s1 ~]#
4. 故障演练
停止 Master 节点的服务
[root@s1 ~]# redis-cli -p 6380 shutdown
不断的刷新其中一个 Sentinel 节点的信息,观察最后一行信息的变化
[root@s1 ~]# redis-cli -p 27001 info
...略...
master0:name=mymaster,status=ok,address=127.0.0.1:6382,slaves=2,sentinels=3