Redis复制+Sentinel搭建详解

1:实验环境
测试环境两台:
master:172.16.16.34
slave:172.16.16.35
redis版本:redis3.2
要搭建的环境是,redis简单主从复制
2:安装redis
tar xzf redis-3.2.8.tar.gz
cd redis-3.2.8
yum install gcc
make

注意我们使用的是redis3.2.8的版本,这是目前最稳定也是最新的redis版本了。下面我们看一下简单配置

3:配置启动redis
先看一下我主库的配置文件(172.16.16.34)
#bind 127.0.0.1    # 绑定的主机地址
protected-mode no  # 是否开启保护模式,开启该参数后,redis只会本地进行访问
port 6379
timeout 300  # 当客户端闲置多长时间后关闭连接

daemonize yes  # 是否以守护进程的模式运行
pidfile /home/redis/tmp/redis_6379.pid

loglevel notice       # 日志级别,最好是warning
logfile /home/redis/log/redis_6379.log

databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes   # 在出现错误的时候,是否要停止保存
rdbcompression yes   # 使用压缩rdb文件
rdbchecksum yes     # 是否校验rdb文件的名称
dbfilename dump.rdb
dir /home/redis/data     # 数据库目录,数据库的写入会在这个目录

slave-serve-stale-data yes      #主从失去联系以后,继续相应客户端的请求
#slave-read-only yes     # yes开启从库只读
repl-diskless-sync no   # 是否使用socket方式复制数据,采用disk的方式
repl-diskless-sync-delay 5      # diskless复制的延迟时间,默认值是5,可以不设置
repl-disable-tcp-nodelay no    #此设置可减少延迟
slave-priority 100      # 设置优先级,最低的优先级会优先称为主节点

appendonly no   #不使用appendonly来进行持久化操作
#appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no    #
auto-aof-rewrite-percentage 100     #开始重写日志
auto-aof-rewrite-min-size 64mb

lua-time-limit 5000     #最长时间设置,默认为毫秒
slowlog-log-slower-than 10000   #慢查询的时间
slowlog-max-len 128

latency-monitor-threshold 0     #关闭监视器
requirepass maxiangqianredis
然后启动主库的redis:
/home/maxiangqian/redis-3.2.8/src/redis-server /home/redis/redis.conf
这里需要注意的一点就是后面的注释都要去掉,因为redis会继续往后读取,#并不适用除了首行以上。
下面配置从库redis并且启动从库(172.16.16.35):
port 6379
timeout 300 

daemonize yes  
pidfile /home/redis/tmp/redis_6379.pid

loglevel notice      
logfile /home/redis/log/redis_6379.log

databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes  
rdbcompression yes 
rdbchecksum yes    
dbfilename dump.rdb
dir /home/redis/data 

slave-serve-stale-data yes    
#slave-read-only yes     # yes开启从库只读
repl-diskless-sync no  
repl-diskless-sync-delay 5    
repl-disable-tcp-nodelay no  
slave-priority 100     

appendonly no  
#appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no  
auto-aof-rewrite-percentage 100     
auto-aof-rewrite-min-size 64mb

lua-time-limit 5000    
slowlog-log-slower-than 10000  
slowlog-max-len 128

latency-monitor-threshold 0   
requirepass maxiangqianredis
slaveof 172.16.16.34 6379
masterauth maxiangqianredis
启动redis从库
/home/maxiangqian/redis-3.2.8/src/redis-server /home/redis/redis.conf
我们注意就是从库的配置的话比主库是多了最后两行,指定主库,指定主库的认证方式
另外我们也可以在从库加上slave-read-only yes参数来控制从库是否是只能为只读。
然后同样方法启动一个6380的从库
4:查看redis主从同步是否成功
主库执行如下操作
[root@localhost redis]# /home/maxiangqian/redis-3.2.8/src/redis-cli 
127.0.0.1:6379> AUTH maxiangqianredis
OK
127.0.0.1:6379> set name maxiangqian
OK
从库验证是否配置成功:
[root@mxqmongodb2 redis]# /home/maxiangqian/redis-3.2.8/src/redis-cli 
127.0.0.1:6379> get name
127.0.0.1:6379> AUTH maxiangqianredis
OK
127.0.0.1:6379> get name
"maxiangqian"
我们可以看到,slave已经同步了master的数据。简单的主从搭建也就完成了。
5:现在主从配置成功了,但是万一主库down掉,我们是并不能主动进行切换的,所以我们要做高可用方案,我们使用redis官方推荐的Redis-Sentinel,关于这个介绍,可以网上搜下,介绍还是很多的。不过我们还是简单介绍一下Redis-Sentinel吧。
Redis-Sentinel的主要作用:
(1)监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
(2)提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
(3)自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
我们看到了Redis-Sentinel的功能以后就看一下怎么启动Redis-Sentinel,官方给的是有两种启动方式:
edis-sentinel  /path/to/sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
两种启动方式都是可以的。下面看一下我们要怎么去配置这个Redis-Sentinel:
最基本的配置如下:
port  26379
logfile "/home/Sentinel/log/sentinel_263797.log"
daemonize yes
sentinel monitor localhost 172.16.16.34 6379 2
sentinel down-after-milliseconds localhost 60000
sentinel failover-timeout localhost 180000
sentinel parallel-syncs localhost 1
sentinel auth-pass localhost maxiangqianredis
#sentinel notification-script <master-name> <script-path>
最后一行代码主要是用来发生切换之后执行的一个自定义脚本:如发邮件、vip切换等。比较方便我们操作。再看一下Redis-Sentinel的基本操作
PING :返回 PONG 。
SENTINEL masters :列出所有被监视的主服务器,以及这些主服务器的当前状态。
SENTINEL slaves :列出给定主服务器的所有从服务器,以及这些从服务器的当前状态。
SENTINEL get-master-addr-by-name : 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个命令返回新的主服务器的 IP 地址和端口号。
SENTINEL reset : 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel 。
SENTINEL failover : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移 (不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置,其他 Sentinel 会根据这个配置进行相应的更新)。
下面开始配置Redis-Sentinel的监控:
[root@mxqmongodb2 home]# mkdir Sentinel
[root@mxqmongodb2 home]# cd Sentinel/
[root@mxqmongodb2 Sentinel]# mkdir data log tmp
启动:
/home/maxiangqian/redis-3.2.8/src/redis-server /home/Sentinel/sentinel.conf  --sentinel
查看一下啊主库信息:
SENTINEL masters
SENTINEL slaves localhost
可以看到,master信息和两个从库的信息已经打印出来了。已经检测成功了。
同样配置文件在35上在启动一个 sentinel。
 
127.0.0.1:26379> info sentinel 
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=localhost,status=ok,address=172.16.16.34:6379,slaves=2,sentinels=4
 
我们已经看到已经启动了主从以及sentinel HA,下面我们测试一下故障转移
6:测试故障转移
 
127.0.0.1:26379> sentinel failover localhost
OK
下面我们看一下redis强制故障转移以后的信息
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=localhost,status=ok,address=172.16.16.35:6379,slaves=2,sentinels=2
可以看到现在35:6379已经转移称为了主节点。
我们进入我们的sentinel的日志看一下failover的一个过程
29042:X 28 Apr 10:55:14.340 # +try-failover master localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:14.394 # +vote-for-leader 51fc16eb8e0bf950a3f3ada8c1eb9d70145c9ffb 1
29042:X 28 Apr 10:55:14.395 # +elected-leader master localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:14.395 # +failover-state-select-slave master localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:14.457 # +selected-slave slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:14.457 * +failover-state-send-slaveof-noone slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:14.510 * +failover-state-wait-promotion slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:15.436 # +promoted-slave slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:15.436 # +failover-state-reconf-slaves master localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:15.507 * +slave-reconf-sent slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:16.465 * +slave-reconf-inprog slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:16.466 * +slave-reconf-done slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:16.540 # +failover-end master localhost 172.16.16.34 6379
29042:X 28 Apr 10:55:16.540 # +switch-master localhost 172.16.16.34 6379 172.16.16.35 6379
29042:X 28 Apr 10:55:16.541 * +slave slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.35 6379
29042:X 28 Apr 10:55:16.541 * +slave slave 172.16.16.34:6379 172.16.16.34 6379 @ localhost 172.16.16.35 6379
 
过程如下:
(1)尝试DOWN掉主节点redis172.16.16.34 6379
(2)选取一个从节点作为DOWN后的主节点172.16.16.35:6379
(3)重写配置文件
查看配置文件发现,主库重新指定为
slaveof 172.16.16.35 6379
(4)主库DOWN结束,新节点172.16.16.35:6379成为了主节点,然后另外两个节点称为主节点的从节点。

下面关于Redis的文章您也可能喜欢,不妨参考下:

猜你喜欢

转载自www.linuxidc.com/Linux/2017-06/144618.htm