关于 Redis Sentinel
Redis主从复制能够生成一个或多个Redis服务器的副本,但是它不会在主服务器和从Redis服务器之间提供自动故障切换。因此Sentinel为Redis实例提供了一个简单而自动化的高可用性(HA)解决方案,如果当前的主服务器不按预期工作,则可以将从服务器升级为主服务器。假设您已经有一个Redis Replication集群,你将需要配置Sentinel(哨兵),从而完成故障自动切换。更多介绍请参阅官方Redis Sentinel 文档。
Redis源码包中已经包含了一个 sentinel.conf 作为Sentinel的配置文件,配置文件中自带了关于各个配置项的解释。先上架构图:
+———————–+ +——————–+
| Redis Master:6379 | _____ | Redis Svale:6379|
| Sentinel1:26379 | | Sentinel2:26379 |
+———————–+ +——————–+所有Redis节点都应以相同的方式配置和类似的服务器规格,如在故障转移情况下,任何从站都可能会由Sentinel升级为新的Master。
1.开始下面部署前,建议先预读以下文章:
《Linux Centos7 Redis 4.0.1 源码编译安装配置》
《如何在 Centos 7上配置 Redis Replication 主从复制群集》
2.现在开始部署(由于资源有限,暂用2台Server做为测试):
OS:CentOS 7.4
Redis sentinel 4.0.1
Redis Master+Sentinel 10.10.204.64
Redis Slave+Sentinel 10.10.204.65
3.分别修改主从的哨兵配置文件 sentinel.conf (除bind不一样外,其他均相同):
# vim /usr/local/redis/sentinel.conf bind 10.10.204.64 #网卡绑定的IP地址 sentinel monitor mymaster 10.10.204.64 6379 2 #填写Master的IP地址以及端口,这个2代表;当集群中有2个sentinel认为master挂了时,才能真正认为该master已经不可用了 sentinel down-after-milliseconds mymaster 5000 #如果5秒内检测不到mymaster节点存活,则认为主节点故障从而进行转移操作 sentinel failover-timeout mymaster 180000 #故障转移的超时时间(单位毫秒) sentinel parallel-syncs mymaster 1 #设置故障转移后,允许多少从服务器连接主节点发起同步请求 sentinel auth-pass mymaster RenwoleQxl5qpKHrh9khuTW #设置连接密码 protected-mode no #为了redis client能内网连接操作redis-sentinel logfile /usr/local/redis/logs/sentinel.log #添加指定日志文件存储位置
4.分别在主从上创建Redis sentinel系统单元文件:
# vim /usr/lib/systemd/system/redis-sentinel.service [Unit] Description=Redis persistent key-value database After=network.target [Service] User=redis Group=redis ExecStart=/usr/local/bin/redis-sentinel /usr/local/redis/sentinel.conf --daemonize no ExecStop=/usr/local/bin/redis-cli -p 26379 shutdown Restart=always [Install] WantedBy=multi-user.target
5.重载systemctl并启动sentinel(哨兵机制)服务:
# systemctl daemon-reload # systemctl start redis-sentinel.service # systemctl enable redis-sentinel.service
6.将端口加入防火墙(要保证所有Redis实例相互通信):
# firewall-cmd --zone=public --add-port=26379/tcp --permanent # firewall-cmd --reload
7.验证Redis故障切换:
查看Master 10.10.204.64角色,以及slave0的连接状态(正常):
10.10.204.64:6379> info ... # Replication role:master connected_slaves:1 slave0:ip=10.10.204.65,port=6379,state=online,offset=8681829,lag=1 master_replid:0ed3591a6caf4ae4b59d3943dc8d7f4c0440b724 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:8681829 ...查看Slave 10.10.204.65角色,以及master连接状态(正常):
10.10.204.65:6379> info ... # Replication role:slave master_host:10.10.204.64 master_port:6379 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 slave_repl_offset:8692657 ...
8.停止Redis Master服务器并查看sentinel日志记录:
# systemctl stop redis # cat /usr/local/redis/logs/sentinel.log 5403:X 11 Aug 11:05:47.633 * +slave slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379 5403:X 11 Aug 11:05:52.694 # +sdown slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379
9.再查看打印的 Redis Slave sentinel日志记录:
# cat /usr/local/redis/logs/sentinel.log 2873:X 11 Aug 11:05:25.006 * +slave slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379 2873:X 11 Aug 11:05:30.061 # +sdown slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379日志中分别表示,已经将之前 Redis Slave 10.10.204.65 变成了主。
10.现在再模拟下之前的Redis Master 10.10.204.64上线后的状态:
# systemctl start redis # cat /usr/local/redis/logs/sentinel.log 5403:X 11 Aug 11:15:38.743 # -sdown slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379 5403:X 11 Aug 11:15:48.691 * +convert-to-slave slave 10.10.204.64:6379 10.10.204.64 6379 @ mymaster 10.10.204.65 6379日志明确显示 Redis Master 10.10.204.64 被降级为 Redis Slave 10.10.204.65 的从,再不会变成Master,除非Slave出现故障。
扩展阅读:
查看Sentinel状态:
# redis-cli -p 26379 -h 10.10.204.64 -a Qxl5qpKHrh9khuTW 10.10.204.64: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=mymaster,status=ok,address=10.10.204.65:6379,slaves=1,sentinels=2
常用命令:
sentinel master mymaster #查看Master的状态信息
SENTINEL slaves mymaster #查看Salves的信息
SENTINEL sentinels mymaster #查看哨兵的状态
SENTINEL get-master-addr-by-name mymaster #获取当前master的地址
一旦一个Sentinel成功对一个Master进行了failover,它将会把关于Master的最新配置通过广播形式通知其它sentinel,其它的sentinel则更新对应master的配置。
注:如果不能正常故障切换,请检查您的机器之间的端口是否通信,大多数都是因为这个原因导致。
到目前为止Redis Sentinel已经配置完成,而且测试数据看起来一切都很好。
分不同端口对外服务的考虑现在是前端php使用6379,前端tomcat使用6380,所有数据通过端口实现redis内部所有层面的隔离
有必要这么做吗?
个人认为没必要这么做,况且如果redis在不同的服务器上,那么端口都可以使用6379,无需修改任何端口,除非以安全为目的的。
初步分析的结论是,当redis集群(1m2s)分6379和6380两个端口
需要分别为6379和6380进行主从配置
然后需要分别通过sentinel对6379和6380分别监控和自动failover
也就是会出现,对6379的master是redis01,同时6380的master则是redis02
在研究中,当前是对6379端口三台redis做 replication,本以为replication的模式是一个端口用于复制,复制整个redis的所有数据。
是这样的吗?
还是6379的复制,就只复制6379来的k-v,而不是整台redis的所有数据(6379+6380)?
请问,我的Redis架构是1 master 2 slave
3台redis的6379端口用于主从复制
3台redis的6380端口用于供前端phpRedis使用
在这样的情况下,sentinel的sentinel monitor值应该是6379还是6380?
我第一次设置为6380,并在master上停止了6380,结果并没有切换