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成为了主节点，然后另外两个节点称为主节点的从节点。

 

=至此完毕，本文是自己测试学习结果，如果你感觉此文对你有帮助，请帮忙点一下推荐。这将鼓励我继续写下去。