Redis和Sentinel的安装部署和配置

最新推荐文章于 2024-08-07 02:09:41 发布
最新推荐文章于 2024-08-07 02:09:41 发布
阅读量570 收藏 1
点赞数 1
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/bisal/article/details/113874509
版权

数据库 redis java 分布式 linux

为了提升数据检索的效率，有时候我们会在数据库前加一层缓存，Redis就是常见的一种缓存组件，他的全称是REmote DIctionary Server，是一个由Salvatore Sanfilippo写的key-value存储系统，而且是可以跨平台的非关系型数据库。

Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库，并提供多种语言的API。他的值(value)可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等类型。

在实际场景中，我们不会使用单点的Redis，而是会选择主从模式，但若主节点一旦发生故障不能提供服务，需要人工干预，将从节点晋升为主节点，同时还需要修改客户端配置。

因此，从Redis 2.8开始，提供了Sentinel哨兵模式，Redis Sentinel是Redis的高可用实现方案，他的作用是完成对Redis的故障判断、故障转移、通知客户端。

Sentinel是建立在主从结构之上，会多几个Sentinel节点，他不会存储数据，但是多个Sentinel可达到对Redis故障判断的公平性，还能保证高可用。即使一个Sentinel节点挂了，也能保证Sentinel机制的存在。客户端不会直接从Redis中获取信息，而是从Sentinel获取信息。Sentinel会对所有的master和slave监控。当多个Sentinel发现master挂了，会内部选举出一个Sentinel作为领导。被选举出的Sentinel领导会选出一个slave作为新的master，同时通知slave复制新的master，通知客户端新的master是谁。如果老的master复活了，他会变成一个slave去复制新的master。一套Sentinel可以监控多套master-slave，有效节省资源。每套master-slave会使用一个master-name配置作为标识。

一句话，Sentinel架构解决了Redis主从人工干预的问题。

我们尝试在Linux 7安装Redis 3.0.3，以及Sentinel。

首先，下载redis-3.0.3.tar.gz并解压，生成文件如下，

[bisal@bisal redis-3.0.3]$ tar zxvf redis-3.0.3.tar.gz


[bisal@bisal redis-3.0.3]$ ls -rlht
total 136K
drwxrwxr-x.  5 bisal bisal 4.0K Jul 17  2015 utils
drwxrwxr-x. 10 bisal bisal  167 Jul 17  2015 tests
drwxrwxr-x.  2 bisal bisal 4.0K Jul 17  2015 src
-rw-rw-r--.  1 bisal bisal 7.0K Jul 17  2015 sentinel.conf
-rwxrwxr-x.  1 bisal bisal  281 Jul 17  2015 runtest-sentinel
-rwxrwxr-x.  1 bisal bisal  280 Jul 17  2015 runtest-cluster
-rwxrwxr-x.  1 bisal bisal  271 Jul 17  2015 runtest
-rw-rw-r--.  1 bisal bisal  41K Jul 17  2015 redis.conf
-rw-rw-r--.  1 bisal bisal 5.1K Jul 17  2015 README
-rw-rw-r--.  1 bisal bisal 4.2K Jul 17  2015 MANIFESTO
-rw-rw-r--.  1 bisal bisal  151 Jul 17  2015 Makefile
-rw-rw-r--.  1 bisal bisal   11 Jul 17  2015 INSTALL
drwxrwxr-x.  6 bisal bisal  107 Jul 17  2015 deps
-rw-rw-r--.  1 bisal bisal 1.5K Jul 17  2015 COPYING
-rw-rw-r--.  1 bisal bisal 1.5K Jul 17  2015 CONTRIBUTING
-rw-rw-r--.  1 bisal bisal   53 Jul 17  2015 BUGS
-rw-rw-r--.  1 bisal bisal  28K Jul 17  2015 00-RELEASENOTES

Redis的安装，就是make，会在Redis路径下增加一个src文件夹，包含了相关的执行脚本，

[bisal@bisal redis-3.0.3]$ make 
cd src && make all
make[1]: Entering directory `/opt/software/redis-3.0.3/src'
rm -rf redis-server redis-sentinel redis-cli redis-benchmark redis-check-dump redis-check-aof *.o *.gcda *.gcno *.gcov redis.info lcov-html
(cd ../deps && make distclean)
...
Hint: It's a good idea to run 'make test' ;)


make[1]: Leaving directory `/opt/software/redis-3.0.3/src'

Redis，就，安装完了。

接下来需要的就是利用配置文件执行启动脚本了。为了验证Sentinel的作用，我们搭建一个Redis主从架构，由于机器有限，选择一台机器，利用三个端口，模拟搭建三套Redis，一主两从的配置。

首先，创建三个Redis软件安装的路径，以及三个Redis对应日志的路径，分别使用6379、6380和6381，作为端口，

/opt/app/redis_6379
/opt/app/redis_6380
/opt/app/redis_6381


/opt/applog/redis_6380
/opt/applog/redis_6379
/opt/applog/redis_6381

接下来，改下这三个Redis的配置文件，

/opt/app/redis_6379/redis.conf
/opt/app/redis_6380/redis.conf
/opt/app/redis_6381/redis.conf

调整内容如下，验证的密码是TestRedis，端口、pid文件、log文件、dir，rdb文件都按照实际进行改动，因为要配置主从，还需要配置masterauth指定密码，否则切主从时，会无法连接，

P.S. 三个配置文件使用对应的6379，6380、6381标识，

requirepass "TestRedis"
pidfile "/opt/app/redis_6379/redis_6379.pid"
port 6379
bind 192.168.15.130
tcp-keepalive 60
logfile "/opt/applog/redis_6379/redis_6379.log"
dir "/opt/app/redis_6379"
dbfilename dump_6379.rdb
masterauth "TestRedis"

分别在三个Redis的src下，执行redis-server，参数就是刚才配置的redis.conf，使用&运行在后台，此时Redis就启动了，

 ./redis-server ../redis.conf &

从对应的redis.log，可看到启动信息，

15312:M 02 Feb 14:09:11.656 * Increased maximum number of open files to 4096 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.0.3 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6380
 |    `-._   `._    /     _.-'    |     PID: 15312
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               


15312:M 02 Feb 14:09:11.658 # Server started, Redis version 3.0.3
15312:M 02 Feb 14:09:11.658 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
15312:M 02 Feb 14:09:11.658 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
15312:M 02 Feb 14:09:11.658 * DB loaded from disk: 0.000 seconds
15312:M 02 Feb 14:09:11.658 * The server is now ready to accept connections on port 6379

当前启动的Redis只是单兵作战，开始配置主从。

我们初始设置6379是master，6380和6381是slave，通过redis-cli分别登录两个slave，执行"slaveof 192.168.15.130 6379"，表示这两个是6379的slave，即6379是master，"config rewrite"会将信息回写至配置文件，进行生效，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6380
192.168.15.130:6380> auth "TestRedis"
OK
192.168.15.130:6380> slaveof 192.168.15.130 6379
OK
192.168.15.130:6380> config rewrite
OK

此时登录6379、6380和6381的客户端，可以看下info replication部分，6379的role是master，6380和6381的role是slave，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6379 -a TestRedis info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.15.130,port=6381,state=online,offset=7788,lag=1
master_repl_offset:7931
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:7930
  
[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6380 -a TestRedis info replication
# Replication
role:slave
master_host:192.168.15.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:17605
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
  
[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6381 -a TestRedis info replication
# Replication
role:slave
master_host:192.168.15.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:18463
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

可以尝试插入和检索数据，但是要注意，只可以在主节点进行插入操作，如果插入备节点，会提示错误，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6380 -a TestRedis
192.168.15.130:6380> sadd name bisal
(error) READONLY You can't write against a read only slave.

登录主节点，sadd插入name=bisal，smembers name检索key=name的value，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6379 -a TestRedis
192.168.15.130:6379> sadd name bisal
(integer) 1
192.168.15.130:6379> smembers name
1) "bisal"

我们可以到3个Redis路径下使用od十六进制打开dump_xxxx.rdb文件，看到都存在name、bisal的值，说明主从节点都同步了刚才插入的数据，

[bisal@bisal redis_6380]$ od -A x -t x1c -v dump_6380.rdb 
000000  52  45  44  49  53  30  30  30  36  fe  00  02  04  6e  61  6d
         R   E   D   I   S   0   0   0   6 376  \0 002 004   n   a   m
000010  65  01  05  62  69  73  61  6c  ff  98  c8  57  eb  b8  b8  5b
         e 001 005   b   i   s   a   l 377 230 310   W 353 270 270   [
000020  9b
       233
000021

接下来，Sentinel登场了，首先改下sentinel.conf，我们模拟创建3个Sentinel，端口分别是26379、26380、26381，和Redis的主从不同，这三个Sentinel是相互独立的，没有所谓的master-slave。

在sentinel.conf配置文件中主要改动如下的内容，3个配置文件中"sentinel monitor mymaster 192.168.15.130 6379 2"都是相同的，表示都监控的是6379这个Redis master，mymaster是起的名字，auth-pass要配置刚才Redis的验证密码，否则不会起作用，down-after-milliseconds默认30秒，表示发现主节点无法工作重新选主的间隔时间，为了测试，可以改小点，此处改为5秒，

port 26379
daemonize yes
bind 192.168.15.130
logfile "/opt/applog/redis_6381/sentinel_26381.log"
dir "/opt/app/redis/redis_6381"
sentinel monitor mymaster 192.168.15.130 6379 2
sentinel auth-pass mymaster TestRedis
sentinel down-after-milliseconds mymaster 5000

启动这三个Sentinel，

/redis-sentinel ../sentinel.conf

此时系统中应该存在3个Redis和3个Sentinel，

ps -ef | grep redis
./redis-server 192.168.15.130:6379
./redis-server 192.168.15.130:6380
./redis-server 192.168.15.130:6381
./redis-sentinel 192.168.15.130:26379 [sentinel]
./redis-sentinel 192.168.15.130:26380 [sentinel]
./redis-sentinel 192.168.15.130:26381 [sentinel]

从任何的一个Sentinel登录看他的状态都是相同的，可以看到status状态是ok，说明Sentinel安装正确，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 26379 -a TestRedis info
# Server
redis_version:3.0.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5a9fdf887b7c26a3
redis_mode:sentinel
os:Linux 3.10.0-862.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.5
process_id:13743
run_id:7686d355aa2ca3aedb9bf5d4a8334770a2dcf26b
tcp_port:26379
uptime_in_seconds:1204
uptime_in_days:0
hz:12
lru_clock:2266534
config_file:/opt/oracle/app/redis/redis_6379/sentinel.conf


# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=192.168.15.130:6379,slaves=2,sentinels=3

我们验证下Sentinel所起的作用，即kill了Redis master，看Sentinel能不能帮这套Redis选出新的master。

首先，kill了Redis master进程，

kill -9 6379的redis进程号

可以看到6380的redis.log，试探5秒，Discarding previously cached master state，丢弃原来缓存的master状态信息，MASTER MODE enabled，启动master模式，和6381同步，让其成为slave，

16016:S 09 Feb 22:04:46.574 # Connection with master lost.
16016:S 09 Feb 22:04:46.574 * Caching the disconnected master state.
16016:S 09 Feb 22:04:46.867 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:46.867 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:46.867 # Error condition on socket for SYNC: Connection refused
16016:S 09 Feb 22:04:47.877 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:47.878 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:47.878 # Error condition on socket for SYNC: Connection refused
16016:S 09 Feb 22:04:48.886 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:48.887 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:48.887 # Error condition on socket for SYNC: Connection refused
16016:S 09 Feb 22:04:49.892 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:49.893 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:49.893 # Error condition on socket for SYNC: Connection refused
16016:S 09 Feb 22:04:50.902 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:50.902 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:50.902 # Error condition on socket for SYNC: Connection refused
16016:S 09 Feb 22:04:51.908 * Connecting to MASTER 192.168.15.130:6379
16016:S 09 Feb 22:04:51.908 * MASTER <-> SLAVE sync started
16016:S 09 Feb 22:04:51.908 # Error condition on socket for SYNC: Connection refused
16016:M 09 Feb 22:04:51.940 * Discarding previously cached master state.
16016:M 09 Feb 22:04:51.941 * MASTER MODE enabled (user request)
16016:M 09 Feb 22:04:51.946 # CONFIG REWRITE executed with success.
16016:M 09 Feb 22:04:53.727 * Slave 192.168.15.130:6381 asks for synchronization
16016:M 09 Feb 22:04:53.727 * Full resync requested by slave 192.168.15.130:6381
16016:M 09 Feb 22:04:53.727 * Starting BGSAVE for SYNC with target: disk
16016:M 09 Feb 22:04:53.728 * Background saving started by pid 15376
15376:C 09 Feb 22:04:53.737 * DB saved on disk
15376:C 09 Feb 22:04:53.739 * RDB: 0 MB of memory used by copy-on-write
16016:M 09 Feb 22:04:53.824 * Background saving terminated with success
16016:M 09 Feb 22:04:53.824 * Synchronization with slave 192.168.15.130:6381 succeeded

6381的redis.log，等待5秒，执行了“SLAVE OF 192.168.15.130:6380 enabled”，从作为6379的slave改为6380的slave，

13516:S 09 Feb 22:04:46.575 # Connection with master lost.
13516:S 09 Feb 22:04:46.575 * Caching the disconnected master state.
13516:S 09 Feb 22:04:46.665 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:46.665 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:46.665 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:47.674 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:47.675 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:47.675 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:48.684 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:48.684 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:48.684 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:49.693 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:49.693 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:49.693 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:50.701 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:50.702 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:50.702 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:51.708 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:51.709 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:51.709 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:52.717 * Connecting to MASTER 192.168.15.130:6379
13516:S 09 Feb 22:04:52.717 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:52.717 # Error condition on socket for SYNC: Connection refused
13516:S 09 Feb 22:04:52.866 * Discarding previously cached master state.
13516:S 09 Feb 22:04:52.866 * SLAVE OF 192.168.15.130:6380 enabled (user request)
13516:S 09 Feb 22:04:52.868 # CONFIG REWRITE executed with success.
13516:S 09 Feb 22:04:53.723 * Connecting to MASTER 192.168.15.130:6380
13516:S 09 Feb 22:04:53.724 * MASTER <-> SLAVE sync started
13516:S 09 Feb 22:04:53.724 * Non blocking connect for SYNC fired the event.
13516:S 09 Feb 22:04:53.725 * Master replied to PING, replication can continue...
13516:S 09 Feb 22:04:53.727 * Partial resynchronization not possible (no cached master)
13516:S 09 Feb 22:04:53.729 * Full resync from master: 1c7fdca18b4b509b634f6050219394860858982f:1
13516:S 09 Feb 22:04:53.824 * MASTER <-> SLAVE sync: receiving 18 bytes from master
13516:S 09 Feb 22:04:53.825 * MASTER <-> SLAVE sync: Flushing old data
13516:S 09 Feb 22:04:53.825 * MASTER <-> SLAVE sync: Loading DB in memory
13516:S 09 Feb 22:04:53.825 * MASTER <-> SLAVE sync: Finished with success

再来看下6379的sentinel.log，

发现6379不可用
13743:X 09 Feb 22:04:51.673 # +sdown master mymaster 192.168.15.130 6379
当前配置版本被更新
13743:X 09 Feb 22:04:51.742 # +new-epoch 5
进行投票选举slave服务器
13743:X 09 Feb 22:04:51.746 # +vote-for-leader 3a00a8cb8433aaaf8a59c35a05b3af835827c5f2 5
投票环节有两个sentinel发现master不能用
13743:X 09 Feb 22:04:51.750 # +odown master mymaster 192.168.15.130 6379 #quorum 3/2
13743:X 09 Feb 22:04:51.750 # Next failover delay: I will not start a failover before Tue Feb  9 22:10:52 2021
13743:X 09 Feb 22:04:52.869 # +config-update-from sentinel 192.168.15.130:26380 192.168.15.130 26380 @ mymaster 192.168.15.130 6379
master地址发生改变
13743:X 09 Feb 22:04:52.869 # +switch-master mymaster 192.168.15.130 6379 192.168.15.130 6380
检测slave并添加到slave列表
13743:X 09 Feb 22:04:52.869 * +slave slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6380
13743:X 09 Feb 22:04:52.869 * +slave slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380
13743:X 09 Feb 22:04:57.875 # +sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380

6381的sentinel.log和6379的基本一致，

13514:X 09 Feb 22:04:51.641 # +sdown master mymaster 192.168.15.130 6379
13514:X 09 Feb 22:04:51.744 # +new-epoch 5
13514:X 09 Feb 22:04:51.748 # +vote-for-leader 3a00a8cb8433aaaf8a59c35a05b3af835827c5f2 5
13514:X 09 Feb 22:04:52.802 # +odown master mymaster 192.168.15.130 6379 #quorum 3/2
13514:X 09 Feb 22:04:52.802 # Next failover delay: I will not start a failover before Tue Feb  9 22:10:52 2021
13514:X 09 Feb 22:04:52.864 # +config-update-from sentinel 192.168.15.130:26380 192.168.15.130 26380 @ mymaster 192.168.15.130 6379
13514:X 09 Feb 22:04:52.865 # +switch-master mymaster 192.168.15.130 6379 192.168.15.130 6380
13514:X 09 Feb 22:04:52.865 * +slave slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6380
13514:X 09 Feb 22:04:52.865 * +slave slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380
13514:X 09 Feb 22:04:57.888 # +sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380

6380的sentinel.log会多记录些，但是主流程还是这些，

13809:X 09 Feb 22:04:51.651 # +sdown master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.735 # +odown master mymaster 192.168.15.130 6379 #quorum 2/2
13809:X 09 Feb 22:04:51.735 # +new-epoch 5
13809:X 09 Feb 22:04:51.735 # +try-failover master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.738 # +vote-for-leader 3a00a8cb8433aaaf8a59c35a05b3af835827c5f2 5
13809:X 09 Feb 22:04:51.747 # 192.168.15.130:26379 voted for 3a00a8cb8433aaaf8a59c35a05b3af835827c5f2 5
13809:X 09 Feb 22:04:51.749 # 192.168.15.130:26381 voted for 3a00a8cb8433aaaf8a59c35a05b3af835827c5f2 5
13809:X 09 Feb 22:04:51.791 # +elected-leader master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.791 # +failover-state-select-slave master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.848 # +selected-slave slave 192.168.15.130:6380 192.168.15.130 6380 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.848 * +failover-state-send-slaveof-noone slave 192.168.15.130:6380 192.168.15.130 6380 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:51.940 * +failover-state-wait-promotion slave 192.168.15.130:6380 192.168.15.130 6380 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:52.812 # +promoted-slave slave 192.168.15.130:6380 192.168.15.130 6380 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:52.812 # +failover-state-reconf-slaves master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:52.864 * +slave-reconf-sent slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:53.891 * +slave-reconf-inprog slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:53.891 * +slave-reconf-done slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:53.956 # -odown master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:53.957 # +failover-end master mymaster 192.168.15.130 6379
13809:X 09 Feb 22:04:53.957 # +switch-master mymaster 192.168.15.130 6379 192.168.15.130 6380
13809:X 09 Feb 22:04:53.957 * +slave slave 192.168.15.130:6381 192.168.15.130 6381 @ mymaster 192.168.15.130 6380
13809:X 09 Feb 22:04:53.957 * +slave slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380
13809:X 09 Feb 22:04:59.013 # +sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380

此时，6380成为Redis master，6379和6381是slave，6379还尚未启动。

启动6379的redis进程，我们看到他的redis.log，因为已经超过了检测阈值，6379不再是master，“Connecting to MASTER 192.168.15.130:6380”，连接到了新的master，并进行数据同步，

15665:M 09 Feb 22:09:39.134 # Server started, Redis version 3.0.3
15665:M 09 Feb 22:09:39.135 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
15665:M 09 Feb 22:09:39.136 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
15665:M 09 Feb 22:09:39.136 * DB loaded from disk: 0.000 seconds
15665:M 09 Feb 22:09:39.136 * The server is now ready to accept connections on port 6379
15665:S 09 Feb 22:09:49.209 * SLAVE OF 192.168.15.130:6380 enabled (user request)
15665:S 09 Feb 22:09:49.210 # CONFIG REWRITE executed with success.
15665:S 09 Feb 22:09:49.260 * Connecting to MASTER 192.168.15.130:6380
15665:S 09 Feb 22:09:49.261 * MASTER <-> SLAVE sync started
15665:S 09 Feb 22:09:49.261 * Non blocking connect for SYNC fired the event.
15665:S 09 Feb 22:09:49.262 * Master replied to PING, replication can continue...
15665:S 09 Feb 22:09:49.263 * Partial resynchronization not possible (no cached master)
15665:S 09 Feb 22:09:49.265 * Full resync from master: 1c7fdca18b4b509b634f6050219394860858982f:61491
15665:S 09 Feb 22:09:49.363 * MASTER <-> SLAVE sync: receiving 18 bytes from master
15665:S 09 Feb 22:09:49.363 * MASTER <-> SLAVE sync: Flushing old data
15665:S 09 Feb 22:09:49.363 * MASTER <-> SLAVE sync: Loading DB in memory
15665:S 09 Feb 22:09:49.364 * MASTER <-> SLAVE sync: Finished with success

6380的redis.log，记录了slave同步请求，

16016:M 09 Feb 22:09:49.263 * Slave 192.168.15.130:6379 asks for synchronization
16016:M 09 Feb 22:09:49.263 * Full resync requested by slave 192.168.15.130:6379
16016:M 09 Feb 22:09:49.264 * Starting BGSAVE for SYNC with target: disk
160816:M 09 Feb 22:09:49.264 * Background saving started by pid 15677
15677:C 09 Feb 22:09:49.275 * DB saved on disk
15677:C 09 Feb 22:09:49.276 * RDB: 0 MB of memory used by copy-on-write
16016:M 09 Feb 22:09:49.361 * Background saving terminated with success
16016:M 09 Feb 22:09:49.362 * Synchronization with slave 192.168.15.130:6379 succeeded

6381的redis.log为空，没做任何事情。

3个Sentinel的sentinel.log，看着好像有些怪，

6379的sentinel.log，
13743:X 09 Feb 22:09:39.300 # -sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380


6380的sentinel.log，
13809:X 09 Feb 22:09:39.268 # -sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380
13809:X 09 Feb 22:09:49.208 * +convert-to-slave slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380


6381的sentine.log，
13514:X 09 Feb 22:09:39.269 # -sdown slave 192.168.15.130:6379 192.168.15.130 6379 @ mymaster 192.168.15.130 6380

此时看到6380已经是master，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 26379 -a TestRedis info
# Server
redis_version:3.0.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5a9fdf887b7c26a3
redis_mode:sentinel
os:Linux 3.10.0-862.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.5
process_id:13743
run_id:7686d355aa2ca3aedb9bf5d4a8334770a2dcf26b
tcp_port:26379
uptime_in_seconds:2409
uptime_in_days:0
hz:14
lru_clock:2267739
config_file:/opt/oracle/app/redis/redis_6379/sentinel.conf


# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=192.168.15.130:6380,slaves=2,sentinels=3

6379的role是slave，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6379 -a TestRedis info replication
# Replication
role:slave
master_host:192.168.15.130
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:215403
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

6380的role是master，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6380 -a TestRedis info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.15.130,port=6381,state=online,offset=217562,lag=0
slave1:ip=192.168.15.130,port=6379,state=online,offset=217705,lag=0
master_repl_offset:217705
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:217704

6381的role是slave，

[bisal@bisal src]$ ./redis-cli -h 192.168.15.130 -p 6381 -a TestRedis info replication
# Replication
role:slave
master_host:192.168.15.130
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:219864
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

一起恢复了宁静。

近期更新的文章：

《小白学习MySQL - 闲聊聊》

《“火线”和“零线”》

《通过索引提升SQL性能案例一则》

《如何手动添加jar包到maven本地库？》

《1元股权转让的一点思考》

《如何打造一个经常宕机的业务系统？》

《Linux恢复误删文件的操作》

《Linux的scp指令使用场景》

《Oracle处理IN的几种方式》

《如何搭建一支拖垮公司的技术团队？》

《IP地址解析的规则》

《MySQL的skip-grant-tables》

《国产数据库不平凡的一年》

《Oracle要求顺序的top数据检索问题》

《日常工作中碰到的几个技术问题》

《了解一下sqlhc》

《Oracle的MD5函数介绍》

《Oracle 19c的examples静默安装》

《sqlplus登录缓慢的解决》

《VMWare 11安装RedHat Linux 7过程中碰到的坑》

《COST值相同？是真是假？》

《Oracle 11g的examples静默安装》

《同名的同义词和视图解惑》

《v$和v_$的一些玄机》

文章分类和索引：

《公众号700篇文章分类和索引》

bisal(Chen Liu)
关注
Redis-Sentinel安装
NotAfraid_ZQ的博客
08-26 241
Redis2.X版本是不支持分布式集群的，只能通过第三方的组件进行实现。上一篇文章介绍了twitter的twemproxy，但twemproxy实现的是将value平均分布到各个服务器上，且只能将失败节点移除，这样就保证不了高可用性了。下面介绍下redis的Sentinel，Sentinel也是redis作者开发的，目前已经集成在redis的安装包里，主要目的就是实现redis的高可用性。 ...
Redis 中的 哨兵（Sentinel） 安装和部署 部署Redis数据节点 部署Sentinel节点 配置优化
norang的博客
09-03 1317
这里写目录标题9.2 安装和部署9.2.1 部署拓扑结构9.2.2 部署Redis数据节点1.启动主节点2.启动两个从节点3.确认主从关系9.2.3 部署Sentinel节点1.配置Sentinel节点2.启动Sentinel节点3.确认9.2.4 配置优化1.配置说明和优化2.如何监控多个主节点3.调整配置9.2.5 部署技巧参考目录 9.2 安装和部署          上一节介绍了Redis Sentinel的基
Redis+Sentinel安装与配置
weixin_30532973的博客
02-25 201
在这里我们搭建的是一个1主3从的redis+3个哨兵集群的环境，由于是在一台物理机上，所有我们用端口区分。 物理机IP：192.168.0.12 主节点master端口：6301 从节点slave1端口：6315 从节点slave2端口：6316 从节点slave3端口：6317 哨兵sentinel1端口：26301 哨兵sentinel2端口：26302 哨兵senti...
redis配置sentinel
最新发布
weixin_36867253的博客
08-07 45
Redis Sentinel 配置指南 在现代应用程序中，数据库的高可用性至关重要。Redis Sentinel是Redis提供的一种高可用性解决方案，它可以监控主Redis实例，并在发生故障时进行故障转移。本文将详细介绍如何配置Redis Sentinel，包括步骤流程和具体代码示例。 一、总体流程 在开始之前，让我们先...
redis sentienl 安装
zhaohp的博客
07-11 230
IP 端口 192.168.110.21 主 192.168.110.31 从 #两台服务器都安装redis #下载最新稳定版本：http://redis.io/download [redis@zhaohp ~]$wget http://download.redis.io/releases/redis-2.8.19.tar.gz #安装 [redis@zhaohp ~]$tar -zxvf redis-2.8.19.tar.gz [redis@zhaohp ~]$cd redis-...
Redis哨兵Sentinel配置
RSQ博客
07-06 4809
文章目录1 Sentinel的功能2 配置Redis哨兵模式2.1 基础环境准备2.2 修改配置文件2.3 启动Sentinel3 故障转移测试 1 Sentinel的功能 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过API向管理 员或者其他应用程序发送通知。 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作
Windows环境Redis-Sentinel安装
03-03
Windows环境Redis-Sentinel安装,如需使用，请查看http://blog.csdn.net/u010648555/article/details/79430105 博文的介绍！
spring + redis + sentinel 配置
10-17
在部署环境中，确保所有相关的Redis实例、Sentinel节点以及Spring应用都能正常通信，以实现故障转移和负载均衡。定期检查Sentinel的日志，确保其能正确监控Redis实例并处理任何异常情况。 总结来说，这个配置文件...
Redis主从部署及sentinel配置详细教程
jks212454的博客
06-01 2224
Redis主从部署及sentinel配置详细教程
redis+sentinel+tomcat部署Linux详细步骤（带安装包，自动脚本）.rar
12-27
redis+sentinel+tomcat部署Linux详细步骤，带安装包，自动脚本。redis+sentinel+tomcat部署Linux详细步骤，带安装包，自动脚本。redis+sentinel+tomcat部署Linux详细步骤，带安装包，自动脚本。
docker部署redis-sentinel(一主二从三哨兵)
p393975269的博客
03-02 781
docker部署redis-sentinel(一主二从三哨兵) java代码访问测试故障转移
redis+sentinel的配置
03-20
redis+sentinel的配置
一、redis sentinel安装
feishahui的专栏
01-10 171
非root用户下 redis sentinel 安装 本次部署采用redis sentinel哨兵集群模式在三台服务器上进行部署，部署策略都采用一主一哨兵的方式。所以步骤只以一个服务器的部署为例。切换到非root用户下（此处的用户为test，该用户需具备sudo可执行权限用于redis的安装）做相应的安装配置。,此处略过centos虚拟机安装以及test用户创建过程； 1.1. 在test用户...
Redis-Sentinel配置说明
上帝之手&传奇 - MartinLee
12-30 1316
一、redis.conf 配置项说明如下： 1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程     daemonize no 2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定     pidfile /var/run/redis.pid 3. 指定Redis
安装和部署Reids Sentinel
fyihdg的专栏
02-05 712
先搭好一主两从redis的主从复制 http://blog.csdn.net/fyihdg/article/details/79247469 A主节点6379节点（/usr/local/bin/conf/redis6379.conf）： 修改 requirepass 12345678，注释掉#bind 127.0.0.1，就是注释IP地址，这里面不能绑定IP B从节......
Redis Sentinel--安装配置
架构师的成长之路的博客
04-25 473
转载： https://blog.51cto.com/darrenmemos/2156531 Redis Sentinel概述 我们知道Redis类似MySQL数据库自带主从复制结构，产品环境中，如果一旦master发生crash,我们希望slave可以立即自动提升为主，接替业务提供服务，如何实现这个功能呢？redis sentinel集群可以帮助我们实现这个功能； Redis Sentinel是Redis官方原生高可用解决方案，Redis Sentinel部署架构主要包括两部分：Red..
redis和sentinel 配置详解
xiaoyaGrace的博客
02-18 214
一、redis.conf 配置： 1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程 daemonize no 2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定 pidfile /var/run/redis.pid 3. 指定Redis监听端口，默认端口为...
redis：sentinel的安装与部署
OceanStar的博客
10-07 2441
redis sentinel具有如下几个功能： 监控：sentinel节点会定期检测Redis数据节点、其余sentinel节点是否可达 通知：sentinel节点会将故障转移的结果通知给应用方 主节点故障转移：实现从节点晋升为主节点并维护后继的正确的主从关系 配置提供者：在redis sentinel结构中，客户端在初始化的时候连接的是sentinel节点集合，从中获取主节点信息 redis sentinel包含了若干个sentinel节点，这样做也带来了两个好处： 对于节点的故障判断是由多个sen
redis哨兵机制 - 配置文件sentinel.conf详解
wh柒八九的博客
06-08 2327
Redis的哨兵机制是官方推荐的一种高可用（HA）方案，我们在使用Redis的主从结构时，如果主节点挂掉，这时是不能自动进行主备切换和通知客户端主节点下线的Redis-Sentinel机制主要用三个功能监控：不停监控Redis主从节点是否安装预期运行提醒：如果Redis运行出现问题可以 按照配置文件中的配置项 通知客户端或者集群管理员自动故障转移：当主节点下线之后，哨兵可以从主节点的多个从节点中选出一个为主节点，并更新配置文件和其他从节点的主节点信息。
RedisSentinel高可用架构详解与部署
通过Sentinel的配置和部署，用户可以实现对Redis集群的高可用性保障，即使在主节点故障的情况下，也能快速恢复服务，降低业务中断的风险。这对于依赖Redis存储关键数据的应用来说，是非常重要的。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值