ip分布情况:
sentinel-1/redis 主 | 10.11.11.5 |
sentinel-2/redis 从 | 10.11.11.7 |
sentinel-3/redis 从 | 10.11.11.8 |
haproxy | 10.11.11.10 |
软件版本:
redis-2.8.20-3.el6.art.x86_64.rpm
haproxy-1.5.4-3.el6.x86_64
开始配置:
一 、redis配置
1.1 redis 主配置: /etc/redis.conf,详细参考http://yijiebuyi.com/blog/bc2b3d3e010bf87ba55267f95ab3aa71.html
daemonize yes #Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程 pidfile "/var/run/redis/redis.pid" #当Redis以守护进程方式运行时,Redis默认会把pid写入/var/run/redis.pid文件,可以通过pidfile指定 port 6379 #指定Redis监听端口,默认端口为6379 tcp-backlog 511 # TCP接收队列长度,受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog这两个内核参数的影响 bind 10.11.11.5 #绑定的主机地址 timeout 0 #当 客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能 tcp-keepalive 0 # 如果非零,则设置SO_KEEPALIVE选项来向空闲连接的客户端发送ACK loglevel notice ## debug (大量信息,对开发/测试有用) ## verbose (很多精简的有用信息,但是不像debug等级那么多) ## notice (适量的信息,基本上是你生产环境中需要的) ## warning (只有很重要/严重的信息会记录下来 logfile "/var/log/redis/redis.log" #日志名 databases 16 #设置数据库的数量,可以使用SELECT <dbid>命令在连接上指定数据库id save 900 1 save 300 10 save 60 10000 #指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合save <seconds> <changes> #分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。 stop-writes-on-bgsave-error yes # 默认如果开启RDB快照(至少一条save指令)并且最新的后台保存失败,Redis将会停止接受写操作 # 这将使用户知道数据没有正确的持久化到硬盘,否则可能没人注意到并且造成一些灾难 rdbcompression yes #指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大 rdbchecksum yes dbfilename "dump.rdb" #指定本地数据库文件名,默认值为dump.rdb dir "/var/lib/redis" #指定本地数据库存放目录 slave-serve-stale-data yes# 当从库同主机失去连接或者复制正在进行,从机库有两种运行方式: # # 1) 如果slave-serve-stale-data设置为yes(默认设置),从库会继续相应客户端的请求 # # 2) 如果slave-serve-stale-data是指为no,出去INFO和SLAVOF命令之外的任何请求都会返回一个 # 错误"SYNC with master in progress" slave-read-only yes ##你可以配置salve实例是否接受写操作。可写的slave实例可能对存储临时数据比较有用(因为写入salve ##的数据在同master同步之后将很容易被删除 repl-disable-tcp-nodelay no # 从库会按照一个时间间隔向主库发送PINGs.可以通过repl-ping-slave-period设置这个时间间隔,默认是10秒 slave-priority 100 # slave的优先级是一个整数展示在Redis的Info输出中。如果master不再正常工作了,哨兵将用它来 # 选择一个slave提升=升为master。 # 优先级数字小的salve会优先考虑提升为master,所以例如有三个slave优先级分别为10,100,25, # 哨兵将挑选优先级最小数字为10的slave。 # 0作为一个特殊的优先级,标识这个slave不能作为master,所以一个优先级为0的slave永远不会被 # 哨兵挑选提升为master appendonly no# 默认情况下,redis会在后台异步的把数据库镜像备份到磁盘,但是该备份是非常耗时的,而且备份也不能很频繁,如果发生诸如拉闸限电、拔插头等状况,那么将造成比较大范围的数据丢失。 # 所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。 # 开启append only模式之后,redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中,当redis重新启动时,会从该文件恢复出之前的状态。 # 但是这样会造成appendonly.aof文件过大,所以redis还支持了BGREWRITEAOF指令,对appendonly.aof 进行重新整理。 # 你可以同时开启asynchronous dumps 和 AOF appendfilename "appendonly.aof" # AOF文件名称 (默认: "appendonly.aof") appendfsync everysec # Redis支持三种同步AOF文件的策略: # # no: 不进行同步,系统去操作 . Faster. # always: always表示每次有写操作都进行同步. Slow, Safest. # everysec: 表示对写操作进行累积,每秒同步一次. Compromise. # # 默认是"everysec",按照速度和安全折中这是最好的。 # 如果想让Redis能更高效的运行,你也可以设置为"no",让操作系统决定什么时候去执行 # 或者相反想让数据更安全你也可以设置为"always" # # 如果不确定就用 "everysec". # appendfsync always no-appendfsync-on-rewrite no # AOF策略设置为always或者everysec时,后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作 # 在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复,即使fsync在另外一个线程进行处理 # # 为了减缓这个问题,可以设置下面这个参数no-appendfsync-on-rewrite auto-aof-rewrite-percentage 100 #自动重写AOF文件 auto-aof-rewrite-min-size 64mb lua-time-limit 5000 # Lua 脚本的最大执行时间,毫秒为单位 slowlog-log-slower-than 10000 # Redis慢查询日志可以记录超过指定时间的查询 slowlog-max-len 128 # 这个长度没有限制。只是要主要会消耗内存。你可以通过 SLOWLOG RESET 来回收内存。 hash-max-ziplist-entries 512 hash-max-ziplist-value 64 # 当hash只有少量的entry时,并且最大的entry所占空间没有超过指定的限制时,会用一种节省内存的 # 数据结构来编码。可以通过下面的指令来设定限制 list-max-ziplist-entries 512 list-max-ziplist-value 64 # 与hash似,数据元素较少的list,可以用另一种方式来编码从而节省大量空间。 # 这种特殊的方式只有在符合下面限制时才??以用 set-max-intset-entries 512 # set有一种特殊编码的情况:当set数据全是十进制64位有符号整型数字构成的字符串时。 # 下面这个配置项就是用来设置set使用这种编码来节省内存的最大长度。 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 # 与hash和list相似,有序集合也可以用一种特别的编码方式来节省大量空间。 # 这种编码只适合长度和元素都小于下面限制的有序集合 hll-sparse-max-bytes 3000 # HyperLogLog稀疏结构表示字节的限制。该限制包括 # 16个字节的头。当HyperLogLog使用稀疏结构表示 # 这些限制,它会被转换成密度表示。 # 值大于16000是完全没用的,因为在该点 # 密集的表示是更多的内存效率。 # 建议值是3000左右,以便具有的内存好处, 减少内存的消耗 activerehashing yes # 启用哈希刷新,每100个CPU毫秒会拿出1个毫秒来刷新Redis的主哈希表(顶级键值映射表) hz 10 # 默认情况下,“hz”的被设定为10。提高该值将在Redis空闲时使用更多的CPU时,但同时当有多个key # 同时到期会使Redis的反应更灵敏,以及超时可以更精确地处理 aof-rewrite-incremental-fsync yes # 当一个子进程重写AOF文件时,如果启用下面的选项,则文件每生成32M数据会被同步 unixsocket "/var/run/redis/redis.sock" unixsocketperm 755 maxclients 4064
1.2 redis 从服务器配置
scp 主节点上的/etc/redis.conf配置到从节点的/etc下,然后增加如下配置:
slaveof 10.11.11.5 6379
# 主从复制. 设置该数据库为其他数据库的从数据库. # 设置当本机为slav服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步 # # slaveof <masterip> <masterport>
1.3 启动redis 主从上的服务,查看主从状态
redis-cli -h 10.11.11.5 info Replication,可以看到主从状态,此时redis主从己配置完成
二、redis sentinel配置
sentinel介绍请参考:https://segmentfault.com/a/1190000002680804
安装部署:
编辑sentinel配置文件 ,主要如下
grep -Ev '^#|^$' /etc/sentinel.conf port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 #配置master名、ip、port、需要多少个sentinel才能判断[客观下线](2) sentinel down-after-milliseconds mymaster 30000 #配置sentinel向master发出ping,最大响应时间、超过则认为主观下线 sentinel parallel-syncs mymaster 1 #配置在进行故障转移时,运行多少个slave进行数据备份同步(越少速度越快) sentinel failover-timeout mymaster 180000 #配置当出现failover时下一个sentinel与上一个sentinel对[同一个master监测的时间间
sentinel-1 sentinel-2 sentinel-3节点上的配置文件一样
启动sentinel,sentinel启动后中,sentinel.conf和redis.conf都由sentinel来控制,主从切换时会写入相关配置(redis.conf配置文件从节点会添加slaveof master ip port,主节点去掉slavvof项),启动后,sentinel.conf配置文件变化:
redis-server /etc/sentinel.conf --sentinel >> /var/log/redis/sentinel.log &
可通过/var/log/redis/sentinel.log日志看到一些相关信息
Sentinel服务启动后会打印一些相关日志信息,以下是相关日志特殊字符说明:
+reset-master <instance details> :主服务器已被重置。
+slave <instance details> :一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves <instancedetails> :故障转移状态切换到了reconf-slaves 状态。
+failover-detected <instance details>:另一个 Sentinel 开始了一次故障转移操作,或者一个从服务器转换成了主服务器。
+slave-reconf-sent <instance details>:领头(leader)的 Sentinel 向实例发送了 SLAVEOF 命令,为实例设置新的主服务器。
+slave-reconf-inprog <instancedetails> :实例正在将自己设置为指定主服务器的从服务器,但相应的同步过程仍未完成。
+slave-reconf-done <instance details>:从服务器已经成功完成对新主服务器的同步。
-dup-sentinel <instance details> :对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候,就会出现这种情况。
+sentinel <instance details> :一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sdown <instance details> :给定的实例现在处于主观下线状态。
-sdown <instance details> :给定的实例已经不再处于主观下线状态。
+odown <instance details> :给定的实例现在处于客观下线状态。
-odown <instance details> :给定的实例已经不再处于客观下线状态。
+new-epoch <instance details> :当前的纪元(epoch)已经被更新。
+try-failover <instance details> :一个新的故障迁移操作正在执行中,等待被大多数 Sentinel 选中(waiting to be elected by themajority)。
+elected-leader <instance details> :赢得指定纪元的选举,可以进行故障迁移操作了。
+failover-state-select-slave <instancedetails> :故障转移操作现在处于select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
no-good-slave <instance details> :Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级,又或者直接放弃执行故障转移操作。
selected-slave <instance details> :Sentinel 顺利找到适合进行升级的从服务器。
failover-state-send-slaveof-noone<instance details> :Sentinel 正在将指定的从服务器升级为主服务器,等待升级功能完成。
failover-end-for-timeout <instancedetails> :故障转移因为超时而中止,不过最终所有从服务器都会开始复制新的主服务器(slaves will eventually be configured to replicate with the newmaster anyway)。
failover-end <instance details> :故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
+switch-master <master name><oldip> <oldport> <newip> <newport> :配置变更,主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
+tilt :进入 tilt 模式。
-tilt :退出 tilt 模式。
测试验证
可以对master-slave进行测试,将master关闭,此时slave会自动充当新的new-master;
当old-master恢复后,会充当new-master的slave,即:在这个过程中,sentinel.conf会被改写,改写为当前监控的主机master服务;
如下图测试所示:
Master服务停止:redis-cli -h 10.11.11.5 info Replication 查看10.11.11.7 为master
如图:master己切换到10.11.11.5
三、haproxy 配置,提供负载均衡功能和vip
haproxy 节点:10.11.11.10
vim /etc/haproxy/haproxy.cfg
global daemon group haproxy log /dev/log local0 maxconn 16000 pidfile /var/run/haproxy.pid stats socket /var/lib/haproxy/stats tune.bufsize 32768 user haproxy defaults log global maxconn 8000 mode http option redispatch retries 3 stats enable timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s listen stats *:10000 mode http stats enable stats uri / stats refresh 5s stats show-node stats show-legends stats hide-version listen awredis bind 10.11.11.10:6379 balance leastconn mode tcp option tcp-check #redis 健康检查,确保只有master提供连接 tcp-check connect tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK server redis01 10.11.11.5:6379 check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3 server redis02 10.11.11.7:6379 check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3 server redis03 10.11.11.8:6379 check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3
启动haproxy 服务,可以通过10.11.11.10:10000端口看haproxy的状态
如图:只有master 是up状态