centos下sentinel主从监控配置

1,设置密码127.0.0.1:6379> config get requirepass1) "requirepass"2) ""127.0.0.1:6379> config set requirepass joeyonOK127.0.0.1:6379> auth joeyonOK127.0.0.1:6379> config get requirepass1) "requirepass"2) "joeyon"127.0.0.1:6379> 2，查询复制信息127.0.0.1:6379> info replication# Replicationrole:slavemaster_host:192.168.60.237master_port:6379master_link_status:downmaster_last_io_seconds_ago:-1master_sync_in_progress:0slave_repl_offset:1master_link_down_since_seconds:1437034417slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active3，redis启动警告[18767] 15 Jul 15:53:58.022 # Server started, Redis version 2.8.21[18767] 15 Jul 15:53:58.022 # 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.解决：为了调整内存分配策略，需要配置/proc/sys/vm/overcommit_memory0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。2， 表示内核允许分配超过所有物理内存和交换空间总和的内存默认为0，如果内存情况比较紧张的话，设为1：修改方法：echo 1 > /proc/sys/vm/overcommit_memory参考：http://snowolf.iteye.com/blog/16306974，redis启动警告[18767] 15 Jul 15:53:58.022 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.解决透明巨页内存配置centos6以上默认启用透明巨页内存，查看目前状态cat /sys/kernel/mm/transparent_hugepage/enabled[always] madvise never解决办法echo never >/sys/kernel/mm/transparent_hugepage/enabled参数说明never 关闭，不使用透明内存alway 尽量使用透明内存，扫描内存，有512个 4k页面可以整合，就整合成一个2M的页面madvise 避免改变内存占用参考：http://www.wtoutiao.com/a/818253.html5，reids启动警告WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.解决$ /proc/sys/net/core/somaxconnlisten()的默认参数,挂起请求的最大数量.默认是128.对繁忙的服务器,增加该值有助于网络性能.可调整到256.参考：http://waringid.blog.51cto.com/65148/183496/6，[18988] 15 Jul 17:05:24.110 * Increased maximum number of open files to 10032 (it was originally set to 1024).解决ulimit -n 81948，一次自动快照[18767] 15 Jul 16:20:22.916 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:27.928 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:32.941 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:37.953 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:42.965 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:47.978 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:52.990 - 1 clients connected (0 slaves), 773128 bytes in use[18767] 15 Jul 16:20:57.601 * 1 changes in 900 seconds. Saving...[18767] 15 Jul 16:20:57.602 * Background saving started by pid 18819[18819] 15 Jul 16:20:57.604 * DB saved on disk[18819] 15 Jul 16:20:57.604 * RDB: 6 MB of memory used by copy-on-write[18767] 15 Jul 16:20:57.702 * Background saving terminated with success[18767] 15 Jul 16:20:58.003 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18767] 15 Jul 16:20:58.003 - 1 clients connected (0 slaves), 773288 bytes in use[18767] 15 Jul 16:21:03.016 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18767] 15 Jul 16:21:03.016 - 1 clients connected (0 slaves), 773288 bytes in use[18767] 15 Jul 16:21:08.028 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18767] 15 Jul 16:21:08.028 - 1 clients connected (0 slaves), 773272 bytes in use[18767] 15 Jul 16:21:13.040 - DB 0: 1 keys (0 volatile) in 4 slots HT.9，正常关闭日志[18767] 15 Jul 16:24:38.548 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18767] 15 Jul 16:24:38.548 - 0 clients connected (0 slaves), 752392 bytes in use[18767] 15 Jul 16:24:43.560 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18767] 15 Jul 16:24:43.560 - 0 clients connected (0 slaves), 752392 bytes in use[18767] 15 Jul 16:24:48.423 - Accepted 127.0.0.1:37691[18767] 15 Jul 16:24:48.423 # User requested shutdown...[18767] 15 Jul 16:24:48.423 * Saving the final RDB snapshot before exiting.[18767] 15 Jul 16:24:48.425 * DB saved on disk[18767] 15 Jul 16:24:48.425 * Removing the pid file.[18767] 15 Jul 16:24:48.425 # Redis is now ready to exit, bye bye...10，客户端连接日志[18988] 15 Jul 17:10:04.806 - 0 clients connected (0 slaves), 752392 bytes in use[18988] 15 Jul 17:10:05.316 - Accepted 127.0.0.1:37926[18988] 15 Jul 17:10:09.818 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:10:09.818 - 1 clients connected (0 slaves), 773256 bytes in use[18988] 15 Jul 17:10:14.830 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:10:14.830 - 1 clients connected (0 slaves), 773256 bytes in use[18988] 15 Jul 17:10:19.843 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:10:19.843 - 1 clients connected (0 slaves), 773272 bytes in use[18988] 15 Jul 17:10:24.856 - DB 0: 1 keys (0 volatile) in 4 slots HT.11，客户端关闭日志[18988] 15 Jul 17:09:49.768 - 1 clients connected (0 slaves), 773296 bytes in use[18988] 15 Jul 17:09:54.781 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:09:54.781 - 1 clients connected (0 slaves), 773328 bytes in use[18988] 15 Jul 17:09:59.794 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:09:59.794 - 1 clients connected (0 slaves), 773328 bytes in use[18988] 15 Jul 17:10:03.814 - Client closed connection[18988] 15 Jul 17:10:04.805 - DB 0: 1 keys (0 volatile) in 4 slots HT.[18988] 15 Jul 17:10:04.806 - 0 clients connected (0 slaves), 752392 bytes in use[18988] 15 Jul 17:10:05.316 - Accepted 127.0.0.1:3792612，slave第一次启动，全量同步(master打印的日志)[24490] 17 Jul 09:35:12.096 - 1 clients connected (0 slaves), 773408 bytes in use[24490] 17 Jul 09:35:12.384 - Accepted 192.168.60.235:55191[24490] 17 Jul 09:35:12.386 * Slave 192.168.60.235:6379 asks for synchronization[24490] 17 Jul 09:35:12.386 * Full resync requested by slave 192.168.60.235:6379[24490] 17 Jul 09:35:12.386 * Starting BGSAVE for SYNC with target: disk[24490] 17 Jul 09:35:12.387 * Background saving started by pid 24494[24494] 17 Jul 09:35:12.389 * DB saved on disk[24494] 17 Jul 09:35:12.389 * RDB: 6 MB of memory used by copy-on-write[24490] 17 Jul 09:35:12.397 * Background saving terminated with success[24490] 17 Jul 09:35:12.397 * Synchronization with slave 192.168.60.235:6379 succeeded[24490] 17 Jul 09:35:17.108 - DB 0: 1 keys (0 volatile) in 4 slots HT.[24490] 17 Jul 09:35:17.108 - 1 clients connected (1 slaves), 1842912 bytes in use[24490] 17 Jul 09:35:22.122 - DB 0: 1 keys (0 volatile) in 4 slots HT.[24490] 17 Jul 09:35:22.122 - 1 clients connected (1 slaves), 1842912 bytes in use[24490] 17 Jul 09:35:27.133 - DB 0: 1 keys (0 volatile) in 4 slots HT.[24490] 17 Jul 09:35:27.133 - 1 clients connected (1 slaves), 1842912 bytes in use13，从服务器启动日志(同步数据)[27449] 17 Jul 09:34:53.844 # Server started, Redis version 2.8.21[27449] 17 Jul 09:34:53.844 # 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.[27449] 17 Jul 09:34:53.844 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.[27449] 17 Jul 09:34:53.844 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.[27449] 17 Jul 09:34:53.844 * The server is now ready to accept connections on port 6379[27449] 17 Jul 09:34:53.844 * Connecting to MASTER 192.168.60.237:6379[27449] 17 Jul 09:34:53.845 * MASTER <-> SLAVE sync started[27449] 17 Jul 09:34:53.845 * Non blocking connect for SYNC fired the event.[27449] 17 Jul 09:34:53.846 * Master replied to PING, replication can continue...[27449] 17 Jul 09:34:53.846 * Partial resynchronization not possible (no cached master)[27449] 17 Jul 09:34:53.847 * Full resync from master: 48087f3b86f1e710db2df9b5995899573b947597:1[27449] 17 Jul 09:34:53.858 * MASTER <-> SLAVE sync: receiving 35 bytes from master[27449] 17 Jul 09:34:53.858 * MASTER <-> SLAVE sync: Flushing old data[27449] 17 Jul 09:34:53.858 * MASTER <-> SLAVE sync: Loading DB in memory[27449] 17 Jul 09:34:53.858 * MASTER <-> SLAVE sync: Finished with success14，服务端首次启动日志24490] 17 Jul 09:34:11.944 * The server is now ready to accept connections on port 6379[24490] 17 Jul 09:34:11.944 - 0 clients connected (0 slaves), 752256 bytes in use[24490] 17 Jul 09:34:16.957 - 0 clients connected (0 slaves), 752256 bytes in use[24490] 17 Jul 09:34:18.697 - Accepted 127.0.0.1:43884[24490] 17 Jul 09:34:21.970 - 1 clients connected (0 slaves), 773120 bytes in use[24490] 17 Jul 09:34:26.983 - 1 clients connected (0 slaves), 773136 bytes in use[24490] 17 Jul 09:34:31.995 - 1 clients connected (0 slaves), 773136 bytes in use[24490] 17 Jul 09:34:37.008 - DB 0: 1 keys (0 volatile) in 4 slots HT.[24490] 17 Jul 09:34:37.008 - 1 clients connected (0 slaves), 773408 bytes in use15，master新增一个键值对[24490] 17 Jul 10:23:19.113 - 1 clients connected (1 slaves), 1841936 bytes in use[24490] 17 Jul 10:23:24.124 - DB 0: 3 keys (0 volatile) in 4 slots HT.16，master新增一个键值对，客户端日志[27449] 17 Jul 10:27:19.228 - DB 0: 6 keys (0 volatile) in 8 slots HT.[27449] 17 Jul 10:27:19.228 - 2 clients connected (0 slaves), 793576 bytes in use[27449] 17 Jul 10:27:24.237 - DB 0: 6 keys (0 volatile) in 8 slots HT.17，主从正常，开启监控后 从同步的时候ip换成127.0.0.1 然后报错如下。查看redis.conf发现里面的ip也被改了。[27449] 17 Jul 10:51:24.573 * Connecting to MASTER 127.0.0.1:6379[27449] 17 Jul 10:51:24.573 * MASTER <-> SLAVE sync started[27449] 17 Jul 10:51:24.573 - Accepted 127.0.0.1:46050[27449] 17 Jul 10:51:24.573 * Non blocking connect for SYNC fired the event.[27449] 17 Jul 10:51:24.574 * Master replied to PING, replication can continue...[27449] 17 Jul 10:51:29.579 # Unable to AUTH to MASTER: -Reading from master: Connection timed out[27449] 17 Jul 10:51:29.580 - Client closed connection解决办法1，在从上执行127.0.0.1:6379> SLAVEOF 192.168.60.237 6379OK(2.37s)127.0.0.1:6379> 2，修改sentinel中的ip主从同步就是 RDB 文件的上传下载；主机有小部分的数据修改，就把修改记录传播给每个从机。master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从 client到master发送的命令使用相同的协议格式。参考：http://www.cnblogs.com/daoluanxiaozi/p/3724299.html修改后日志[27449] 17 Jul 10:51:54.111 * Connecting to MASTER 127.0.0.1:6379[27449] 17 Jul 10:51:54.111 * MASTER <-> SLAVE sync started[27449] 17 Jul 10:51:54.111 - Accepted 127.0.0.1:46055[27449] 17 Jul 10:51:54.111 * Non blocking connect for SYNC fired the event.[27449] 17 Jul 10:51:54.111 * Master replied to PING, replication can continue...[27449] 17 Jul 10:51:59.116 # Unable to AUTH to MASTER: -Reading from master: Connection timed out[27449] 17 Jul 10:51:59.116 - Client closed connection[27449] 17 Jul 10:52:00.017 * Connecting to MASTER 127.0.0.1:6379[27449] 17 Jul 10:52:00.017 * MASTER <-> SLAVE sync started[27449] 17 Jul 10:52:00.017 - Accepted 127.0.0.1:46056[27449] 17 Jul 10:52:00.017 * Non blocking connect for SYNC fired the event.[27449] 17 Jul 10:52:00.017 * Master replied to PING, replication can continue...[27449] 17 Jul 10:52:05.022 # Unable to AUTH to MASTER: -Reading from master: Connection timed out[27449] 17 Jul 10:52:05.023 * SLAVE OF 192.168.60.237:6379 enabled (user request)[27449] 17 Jul 10:52:05.023 - Client closed connection[27449] 17 Jul 10:52:05.924 * Connecting to MASTER 192.168.60.237:6379[27449] 17 Jul 10:52:05.924 * MASTER <-> SLAVE sync started[27449] 17 Jul 10:52:05.925 * Non blocking connect for SYNC fired the event.[27449] 17 Jul 10:52:05.925 * Master replied to PING, replication can continue...[27449] 17 Jul 10:52:05.926 * Partial resynchronization not possible (no cached master)[27449] 17 Jul 10:52:05.927 * Full resync from master: 48087f3b86f1e710db2df9b5995899573b947597:1[27449] 17 Jul 10:52:05.996 * MASTER <-> SLAVE sync: receiving 81 bytes from master[27449] 17 Jul 10:52:05.997 * MASTER <-> SLAVE sync: Flushing old data[27449] 17 Jul 10:52:05.997 * MASTER <-> SLAVE sync: Loading DB in memory[27449] 17 Jul 10:52:05.997 * MASTER <-> SLAVE sync: Finished with success[27449] 17 Jul 10:52:06.925 - DB 0: 6 keys (0 volatile) in 8 slots HT.[27449] 17 Jul 10:52:06.925 - 4 clients connected (0 slaves), 835696 bytes in use[27449] 17 Jul 10:52:11.932 - DB 0: 6 keys (0 volatile) in 8 slots HT.[27449] 17 Jul 10:52:11.932 - 4 clients connected (0 slaves), 835696 bytes in use[27449] 17 Jul 10:52:16.940 - DB 0: 6 keys (0 volatile) in 8 slots HT.[27449] 17 Jul 10:52:16.940 - 4 clients connected (0 slaves), 835696 bytes in use18，主从正常，开启监控后 从同步的时候ip换成127.0.0.1 ，从上执行SLAVEOF 192.168.60.237 6379报错以及解决办法如下127.0.0.1:6379> SLAVEOF 192.168.60.237 6379(error) NOAUTH Authentication required.127.0.0.1:6379> auth joeyonOK127.0.0.1:6379> SLAVEOF 192.168.60.237 6379OK Already connected to specified master127.0.0.1:6379> 19，通过Sentinel查看slaves信息[root@localhost redis-2.8.21]# ./bin/redis-cli  -p 26379  Sentinel slaves  def_master1)  1) "name"    2) "192.168.60.235:6379"    3) "ip"    4) "192.168.60.235"    5) "port"    6) "6379"    7) "runid"    8) "391ac1a585188201f8bd55ca2b6d83b9d22e8360"    9) "flags"   10) "slave"   11) "pending-commands"   12) "0"   13) "last-ping-sent"   14) "0"   15) "last-ok-ping-reply"   16) "446"   17) "last-ping-reply"   18) "446"   19) "down-after-milliseconds"   20) "30000"   21) "info-refresh"   22) "88"   23) "role-reported"   24) "slave"   25) "role-reported-time"   26) "388407"   27) "master-link-down-time"   28) "303000"   29) "master-link-status"   30) "err"   31) "master-host"   32) "192.168.60.237"   33) "master-port"   34) "6379"   35) "slave-priority"   36) "100"   37) "slave-repl-offset"   38) "71842"[root@localhost redis-2.8.21]# 20，通过sentinel查看集群信息[root@localhost redis-2.8.21]# ./bin/redis-cli  -p 26379 info Sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0master0:name=def_master,status=odown,address=192.168.60.237:6379,slaves=1,sentinels=121，关闭sentinel[root@localhost redis-2.8.21]# ps -ef|grep redis-sentinelroot     24661     1  0 11:04 ?        00:00:00 ./bin/redis-sentinel *:26379root     24676 24521  0 11:10 pts/3    00:00:00 grep --color=auto redis-sentinel[root@localhost redis-2.8.21]# ./bin/redis-cli  -p 26379  shutdown22，停止主 从sentinel打印信息[root@localhost redis-2.8.21]# tail -f log/sentinel.log  |    `-._`-._        _.-'_.-'    |                                    `-._    `-._`-.__.-'_.-'    _.-'                                         `-._    `-.__.-'    _.-'                                                 `-._        _.-'                                                         `-.__.-'                                               [29867] 17 Jul 12:32:20.514 # Sentinel runid is 30c12e21ccbaae88da00dc6e7e6b604aba5d74ff[29867] 17 Jul 12:32:20.514 # +monitor master def_master 192.168.60.237 6379 quorum 1[29867] 17 Jul 12:32:20.516 * +slave slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:32:21.441 * +sentinel sentinel 192.168.60.237:26379 192.168.60.237 26379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:34:04.904 # +sdown master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:04.904 # +odown master def_master 192.168.60.237 6379 #quorum 1/1[29867] 17 Jul 12:34:04.904 # +new-epoch 1[29867] 17 Jul 12:34:04.904 # +try-failover master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:04.948 # +vote-for-leader 30c12e21ccbaae88da00dc6e7e6b604aba5d74ff 1[29867] 17 Jul 12:34:04.951 # 192.168.60.237:26379 voted for 30c12e21ccbaae88da00dc6e7e6b604aba5d74ff 1[29867] 17 Jul 12:34:05.010 # +elected-leader master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.010 # +failover-state-select-slave master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.093 # +selected-slave slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.093 * +failover-state-send-slaveof-noone slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.169 * +failover-state-wait-promotion slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.981 # +promoted-slave slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[29867] 17 Jul 12:34:05.981 # +failover-state-reconf-slaves master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:06.042 # +failover-end master def_master 192.168.60.237 6379[29867] 17 Jul 12:34:06.042 # +switch-master def_master 192.168.60.237 6379 192.168.60.235 6379[29867] 17 Jul 12:34:06.042 * +slave slave 192.168.60.237:6379 192.168.60.237 6379 @ def_master 192.168.60.235 6379[29867] 17 Jul 12:34:11.047 # +sdown slave 192.168.60.237:6379 192.168.60.237 6379 @ def_master 192.168.60.235 637923停止主主sentinel打印信息      `-._    `-.__.-'    _.-'                                                 `-._        _.-'                                                         `-.__.-'                                               [24824] 17 Jul 12:32:03.018 # Sentinel runid is dbd8ca2066096a825254dcb29a8242f982263d68[24824] 17 Jul 12:32:03.018 # +monitor master def_master 192.168.60.237 6379 quorum 1[24824] 17 Jul 12:32:03.019 * +slave slave 192.168.60.235:6379 192.168.60.235 6379 @ def_master 192.168.60.237 6379[24824] 17 Jul 12:32:40.904 * +sentinel sentinel 192.168.60.235:26379 192.168.60.235 26379 @ def_master 192.168.60.237 6379[24824] 17 Jul 12:34:23.276 # +new-epoch 1[24824] 17 Jul 12:34:23.277 # +vote-for-leader 30c12e21ccbaae88da00dc6e7e6b604aba5d74ff 1[24824] 17 Jul 12:34:23.282 # +sdown master def_master 192.168.60.237 6379[24824] 17 Jul 12:34:23.282 # +odown master def_master 192.168.60.237 6379 #quorum 1/1[24824] 17 Jul 12:34:23.282 # Next failover delay: I will not start a failover before Fri Jul 17 13:04:24 2015[24824] 17 Jul 12:34:24.400 # +config-update-from sentinel 192.168.60.235:26379 192.168.60.235 26379 @ def_master 192.168.60.237 6379[24824] 17 Jul 12:34:24.400 # +switch-master def_master 192.168.60.237 6379 192.168.60.235 6379[24824] 17 Jul 12:34:24.400 * +slave slave 192.168.60.237:6379 192.168.60.237 6379 @ def_master 192.168.60.235 6379[24824] 17 Jul 12:34:29.402 # +sdown slave 192.168.60.237:6379 192.168.60.237 6379 @ def_master 192.168.60.235 637924，sentinel机制redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。参考：http://www.cnblogs.com/yjmyzz/p/redis-sentinel-sample.html24，sentinel配置sentinel monitor test1 192.168.7.40 6379 1 #修改IP地址，IP可以是集群中的任意一个IP地址。sentinel down-after-milliseconds test1 5000 #默认1s检测一次，这里配置超时5000毫秒为宕机。sentinel failover-timeout test1 900000sentinel can-failover test1 yessentinel parallel-syncs test1 2  30，repl-disable-tcp-nodelay解释：在slave和master同步后（发送psync/sync），后续的同步是否设置成TCP_NODELAY假如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致假如设置成no，则redis master会立即发送同步数据，没有延迟参考：http://blog.csdn.net/yfkiss/article/details/2147680131，tcp-backlog此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度， 当然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值，默认是511，而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候，可以将这二个参数一起参考设定。32，Replication SYNC strategy: disk or socket一般情况下，一次复制需要将内存的数据写到硬盘中，再将数据从硬盘读进内存，再发送给slave。对于速度比较慢的硬盘，这个操作会给master带来性能上的损失。Redis2.8版本开始，实验性地加上了无硬盘复制的功能。这个功能能将数据从内存中直接发送到slave，而不用经过硬盘的存储。33，min-slaves-to-write <number of slaves>    min-slaves-max-lag <number of seconds>        至少N个slave才允许向master写数据从redis2.8版本开始，master可以被配置为，只有当master当前有至少N个slave连接着的时候才接受写数据的请求。然而，由于redis是异步复制的，所以它并不能保证slave会受到一个写请求，所以总有一个数据丢失的时间窗口存在。这个机制的工作原理如下所示：slave每秒发送ping心跳给master，询问当前复制了多少数据。master会记录下它上次收到某个slave的ping心跳是什么时候。使用者可以配置一个时间，来指定ping心跳的发送不应超过的一个超时时间如果master有至少N个slave，并且ping心跳的超时不超过M秒，那么它就会接收写请求。也许你会认为这情形好似CAP理论中弱化版的C(consistency)，因为写请求并不能保证数据的一致性，但这样做，至少数据丢失被限制在了限定的时间内。即M秒。如果N和M的条件都无法达到，那么master会回复一个错误信息。写请求也不会被处理。有两个配置项用来配置上文中提到的N和M：34，maxmemory <bytes>最大内存策略: 当redis使用的内存达到指定的最大值时，你可以使用如下的5种# 策略来应对这种情况# volatile-lru -> 使用LRU算法依据过期时间来移除key# allkeys-lru -> 使用LRU算法来移除任何key# volatile-random -> 根据过期时间设置随即移除key# allkeys-random -> 随即移除任何一个key# volatile-ttl -> 移除一个最近过期时间的key# noeviction -> 所有key用不过期(即不移除任何key)，对于任何写操作都返回一个错误信息# # 提示: 在以上的所有策略中，当不存在一个key满足以上的淘汰策略时(即无法空出内存时)# 任何写操作都会返回错误信息默认值为:maxmemory-policy volatile-lru警告：如果你的从服务器关联到一个有最大内存限制的redis实例上，# # 主服务器向从服务器输出的缓存属于被该服务器使用的内存的一部分。#因此 网络问题和重新同步引发的复制，不会触发淘汰key的循环，#反过来，从服务器的输出缓存将会被触发淘汰的DEL key，直到数据库清空#简单来说，如果你拥有一个从服务器，我们建议你将这个值#设置为少于系统可用的最大内存，以便系统可以腾出空间来安放#从服务器的输出缓存（但是如果策略是noeviction 那就没这个必要）35， fsync() 调用告诉操作系统立即将数据写入到硬盘中，而不是写入到输出缓冲区# 等待足够的数据再写入。一些操作系统会立即将数据写入到硬盘中，一些其他的#操作系统则只是尽可能快地将数据写入硬盘中 Redis支持三种不同的模式:# no:不进行强制同步，仅仅让操作系统根据自身的决策写入到硬盘中。这种速度更快 # always:在每一次追加写入操作都采用强制同步，特点是慢，安全。# everysec：每间隔一秒钟强制同步数据。折中的方案# 默认采用 "everysec"作为速度和安全性之间的平衡方案# 你将根据自己的需求决定采用更快的方案或者更安全的方案。# 选择no，何时写入数据将由操作系统决定，你可以由此获取最快的速度# 选择always，数据将立即写入到硬盘中，你可以获得更高的数据安全性36，no-appendfsync-on-rewrite no 当AOF的强制写入策略设置为 always 或者 everysec，并且一个后台保存进程#（一个后台保存进程或者 AOF 日志后台重写）会占用硬盘的大量I/O资源，在一些linux# 的配置中redis会因为 fsync() 调用而长期锁定。特别的是在目前我们没法解决这个问题# 即使采用另外的线程来运行强制同步也会锁定住我们的 同步 write(2)调用为了减轻这个问题，下面的选项将会在GBSAVE 或者BGREWRITEAOF运行时# 预防主进程调用fsync()# 这意味着当另一个 子进程在保存的时候，Redis的保存策略将处于"appendfsync none"这样的类似状态# 在实际应用当中，这意味着在最坏的情况下将会失去30秒的日志(使用linux默认的设置)# 如果你采用yes，那么将会存在一个潜在的隐患，不然请设置它为 "no"，这是一个为了稳定的安全性选择参考：http://my.oschina.net/u/568779/blog/30812937，no-appendfsync-on-rewrite 为 yes默认值是 no#yes : 在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。#no : 在日志重写时，命令追加操作照常进行在默认情况下 当aof进行重写的时候，aof的同步信息不是关闭的。在这种情况下 。子进程rewrite在写硬盘 主进程 aof也在写硬盘。在rewrite的过程中 子进程对主进程造成了磁盘阻塞（disk io冲突），导致了报警信息的产生。但是这个参数修改成 yes之后 ，又会有安全上的问题。当rewrite的过程中 要是redis down掉的话 丢失的数据 就不是之前appendfsync 定下的策略。而是整个 rewrite 过程中的所有数据。参考：http://blog.csdn.net/lxpbs8851/article/details/8553271不过这个功能目前处于实验阶段，还未正式发布。http://blog.csdn.net/pi9nc/article/details/17735653http://blog.mkfree.com/posts/5257683d479e1dd72e7c1b4ehttp://segmentfault.com/a/1190000002692598http://segmentfault.com/a/1190000002692598