11.1.5 其他问题

11.1.5.1 只读性

主从复制架构下，默认Slave是只读的，如果写入则会报错：

127.0.0.1:6379> set foo bar
(error) READONLY You can't write against a read only slave.

注意这个行为是可以修改的，虽然这样的修改没有意义：

127.0.0.1:6379> CONFIG SET slave-read-only no
OK
127.0.0.1:6379> set foo bar
OK

11.1.5.1 事件通知

在sentinel中，如果出现warning以上级别的事件发生， 是可以通过如下配置进行脚本调用的（对于该脚本redis启动用户需要有执行权限）：

比如说，我们希望在发生这些事件的时候进行邮件通知，那么，notify.py就是一个触发邮件调用的东东，传入第一个参数为事件类型，第二个参数为事件信息：

有两个注意事项： 1） 这个时候如果集群发生了切换会产生很多事件，此脚本是在每一个事件发生时调用一次，那么你将短时间收到很多封邮件，加上很多的邮件网关是不允许在一个短时间内发送太多的邮件的，因此这个仅仅是一个示例，并不具备实际上的作用。 2） 一般我们会采用多个sentinel，只需在一个sentinel上配置即可，否则将同一个消息会被多个sentinel多次处理。

附sendmail模块代码：

最佳实践：采用ELK（Elastic+Logstash+Kibana）进行日志收集告警（ElastAlert用起来不错），不启用这个事件通知功能。如果你的环境中没有ELK，或者启动一个Tcp Server进程，notify脚本将事件通过tcp方式吐给这个server，该Server收集一批事件后再做诸如发邮件的处理。

11.1.5.2 虚拟IP切换

在sentinel进行切换时还会自动调用一个脚本（如果设置的话），做一些自动化操作，比如如果我们需要一个虚拟IP永远飘在Master上（这个VIP可不是被应用用来连接redis 的，用过的人都知道连接redis sentinel并不依赖于VIP的），那么可以在sentinel配置文件中配置：

在发生主从切换，Master发生变化时，该脚本会被sentinel进行调用，调用的参数如其配置文件所描述的：

因此，我们可以在failover.sh中进行判断，如果该脚本所运行的主机IP等于新的Master IP，那么将VIP加上，如果不等于，则该机器为Slave，就去掉VIP。通过这种方式进行VIP的切换：

最早这样的用法是一个日本人写的blog，请参见：http://blog.youyo.info/blog/2014/05/24/redis-cluster/

11.1.5.3 持久化动态修改

其实相对于VIP的切换，动态修改持久化则是比较常见的一个需求，一般在一主多从多Sentinel的HA环境中，为了性能常常在Master上关闭持久化，而在Slave上开启持久化，但是如果发生切换就必须有人工干预才能实现这个功能。可以利用client-reconfig-script自动化该进程，无需人工守护，我们就以RDB的动态控制为例： Sentinel配置文件如下：

rdbctl.sh源代码：

原理和VIP切换一节基本一致，不再赘述。

11.1.5.4 Sentinel最大连接数

1. 问题描述

某准生产系统，测试运行一段时间后程序和命令行工具连接sentinel均报错，报错信息为：

此时应用创建redis新连接由于sentinel已经无法响应而无法找到master的IP与端口，因此无法连接redis，并且此时如果发生redis宕机亦无法进行生产切换。

2. 问题初步排查过程

首先，通过netstat对sentinel所监听端口26379进行连接数统计，此时连接则报错。如下图：

通过sentinel服务器端统计发现，redis sentinel 的连接中大部分都是来自于两台非同网段（中间有防火墙）的应用服务器连接（均为Established状态），并且来自其的连接也大约半个小时后稳步增加一次，而同网段的应用服务器连接sentinel的连接数基本保持一致。排除了应用的特殊性（采用的jedis版本和封装的工具类都是一样的）后，初步判断此问题与网络有关，更详细的说是连接数增加与防火墙切断连接后的重连有关。

3. 问题查证过程

此问题分为两个子问题： 1) 防火墙将TCP连接设置为无效时sentinel服务器为何没有断开连接，保持Established状态？ 2) 为何连接数还会不断增加？

对于问题1) ，TCP在三次握手建立连接时OS会启动一个Timer来进行倒计时，经过一个设定的时间（这个时间建立socket的程序可以设置，如果没有设置则采用OS的参数tcp_keepalive_time，这个参数默认为7200s，即2小时）后这个连接还是没有数据传输，它就会以一定间隔（程序可以设定，如果没有设置则采用OS的参数tcp_keepalive_intvl，默认为75s）发出N（程序可以设定，如果没有设置则采用OS的参数tcp_keepalive_probes，默认为9次）次Keep Alive包。TCP连接就是通过上述的过程，在没有流量时是通过发送TCP Keep-Alive数据包，然后对方回应TCP Keep-Alive ACK来确定信道是否还在真实连接。通过查看Sentinel源代码，其默认是不开启Keepalive的（而jedis默认是开启的），并且默认对于不活动的连接也不会主动关闭的（timeout默认为0）。

对于防火墙，通过翻阅防火墙技术资料（详见下列描述，摘自：《Junos Enterprise Switching: A Practical Guide to Junos Switches and Certification》），我司采用的Juniper防火墙对于没有流量的TCP连接默认是30分钟，30分钟内没有流量就会断掉链路，而不会发送TCP Reset，同时在防火墙策略上并没有开长连接，使用的即为此默认设置。

因此在防火墙每半个小时将连接置为无效时，sentinel同时又禁止了Keepalive（因为默认设置Keepalive为0，即disable发送Keepalive包）。应用服务器的jedis虽然开启了keepalive，但是它发送的keepalive包由于防火墙已经将此链路标记为无效，而无法发送到sentinel端，而且jedis由于采用了OS默认参数，因此需要等待tcp_keepalive_time（2小时）后才启动发送Keep Alive包进行探活的，在tcp_keepalive_time+tcp_keepalive_intvl*tcp_keepalive_probes=7895s=131.58分钟后，jedis端才会认定这个连接断掉而清理掉这个连接。简单的说就是jedis会在很长一段时间后才会发keepalive包，并且这个包也是发不到sentinel上的，而sentinel本身也不会发送keepalive包，所以从sentinel这端看连接一直存在，而从jedis那端看7895s之后就会清理一次连接。这也解释了为什么防火墙将TCP连接断开后，sentinel端的连接并没有释放。

对于问题2) ，翻阅jedis源代码，jedis通过连接sentinel并pubsub来监听集群事件，以确定是否发生了切换，并且拿到新的master 地址和端口。如果断开则会5秒后尝试重连（JedisSentinelPool.java）。

4. 问题解决过程

此系统由于访问关系与网段规划间的安全问题，必须跨越防火墙，因此试图从配置角度解决此问题。

首先，联系网络相关同事，进行网络变更，开启从应用服务器到sentinel的链路相对的长连接，即无流量超时而断开的时间设置为8小时。以此手段降低断开频率，以便缓解短时间内不断重试连接造成的sentinel连接增长。

然后，通过阅读redis源代码（net.c），发现，sentinel也采用了redis 所有参数设置（通过config.c的函数void loadServerConfigFromString(char *config)）。因此，通过设置redis 的下列两个参数可以解决这个问题，第一个参数是TCP Keepalive参数，此参数默认为0，也就是不发送keepalive。也就是改变OS默认的tcp_keepalive_time参数（在Unix C的socket编程中TCP_KEEPIDLE参数对应OS 的tcp_keepalive_time参数）。

该参数的官方解释为：

我们设置为tcp-keepalive 60，加快回收连接速度，从网络断开到连接清理时间缩短为60+75*9=12.25分钟。

同时，通过设置maxclients为65536，增大sentinel最大连接数，使得在上述12.25分钟即使有某种异常导致sentinel连接数增加也不至于到达最大限制。此参数的官方解释为：

对于redis 的timeout参数，由于启用这个参数有程序微小开销（会调用redis.c中的int clientsCronHandleTimeout(redisClient *c, mstime_t now_ms)），决定保持默认为0，而通过上述参数使用OS进行连接断开。

5. 问题解决结果

通过开发、网络和数据库团队的协同努力，配置上述参数和修改防火墙策略后，手动增加sentinel进程，超过原默认最大连接数10000后sentinel可以正常访问操作，并且通过tcpdump进行抓包，在指定时间内（1分钟），就有KeepAlive包对每个sentinel TCP连接进行探活，经过观察sentinel连接稳定，再未出现短时间内暴涨的情况。

6. 问题后续

在redis中默认不开启keepalive就是为了尽可能减小网络负载，榨干网络性能，尽可能达到redis的。在后续的程序运行中，如果发现网络是瓶颈时（在相当长的一段时间内不会），可以加大sentinel的keepalive参数，减小keepalive数据包的传输，这个修改是不影响redis对外服务的。

参考文档： http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

附录：如何用TCPDUMP进行keep alive抓包

7. 问题再后续

我们后来在这个应用上发现一旦网络有抖动，sentinel的连接增加就回大幅度增加，后来通过jmap查看sentinelpool的实例竟然多达200多个，也就是说这个就是程序的问题，在sentinelpool上不应该多次实例化，而是采用已有连接进行重连。