分别在几台服务器上安装Redis,安装之前请确保Redis安装依赖都已经安装:gcc,make, tcl, jemalloc
安装目录:/usr/local/redis/
cd /usr/local/
wget http://download.redis.io/releases/redis-3.2.6.tar.gz
tar -zxvf redis-3.2.6.tar.gz
mv redis-3.2.6 redis
cd redis
make && make install
新建working directory,把需要用到的文件拷贝过去
cd /home
mkdir redis
mkdir redis/logs
mkdir redis/data
mv /usr/local/bin/redis-* /home/redis/
目前已经将配置好的配置文件拷贝到相应的主机目录上,配置文件有以下:
redis-6379.conf
############ GENERAL ################
daemonize yes
pidfile "./logs/redis-6379.pid"
port 6379
tcp-backlog 511
bind 0.0.0.0
timeout 0
tcp-keepalive 60
loglevel notice
logfile "./logs/redis-6379.log"
databases 16
############ SNAPSHOTTING ################
#save 900 1
#save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump-6379.rdb"
dir "/home/redis/data"
############ REPLICATION ################
masterauth "abcdefg"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
repl-backlog-size 64mb
slave-priority 100
# min-slaves-to-write 3
# min-slaves-max-lag 10
############ SECURITY ################
requirepass "abcdefg"
############ LIMITS ################
# maxclients 10000
maxmemory 4gb
maxmemory-policy noeviction
############ APPEND ONLY MODE ################
appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 80
auto-aof-rewrite-min-size 128mb
aof-load-truncated yes
############ LUA SCRIPTING ################
lua-time-limit 5000
############ REDIS CLUSTER ################
# cluster-enabled yes
# cluster-node-timeout 15000
# cluster-slave-validity-factor 10
# cluster-migration-barrier 1
# cluster-require-full-coverage yes
############ SLOW LOG ################
slowlog-log-slower-than 10000
slowlog-max-len 128
############ LATENCY MONITOR ################
latency-monitor-threshold 0
############ EVENT NOTIFICATION ################
notify-keyspace-events ""
############ ADVANCED CONFIG ################
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 512mb 128mb 120
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
# Generated by CONFIG REWRITE
从节点的配置文件基本一致,只需要在redis配置文件上添加上slaveof MASTER_IP PORT
# 设置当本机为slave服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步
slaveof 127.0.0.1 6379
# 当master服务设置了密码保护时,slave需要设置服务连接master的密码
masterauth abcdefg
通过以下命令分别把Redis实例启动,启动顺序,先启动主节点,然后再启动从节点实例
cd /home/redis/
./redis-server ./redis-6379.conf &
启动完一个redis实例记得先查看一下日志输出,看是否正常启动完成。如果是从节点实例启动会与主节点进行同步数据,同步成功会在日志后面有以下输出:
5190:S 17 Dec 14:42:53.957 * Connecting to MASTER 172.16.0.46:6379
5190:S 17 Dec 14:42:53.957 * MASTER <-> SLAVE sync started
5190:S 17 Dec 14:42:53.958 * Non blocking connect for SYNC fired the event.
5190:S 17 Dec 14:42:53.958 * Master replied to PING, replication can continue...
5190:S 17 Dec 14:42:53.959 * Partial resynchronization not possible (no cached master)
5190:S 17 Dec 14:42:53.989 * Full resync from master: 5e126b4a8e9d7cd9ee7c50ffedeba6a95e1ae523:1
5190:S 17 Dec 14:42:54.060 * MASTER <-> SLAVE sync: receiving 18 bytes from master
5190:S 17 Dec 14:42:54.061 * MASTER <-> SLAVE sync: Flushing old data
5190:S 17 Dec 14:42:54.061 * MASTER <-> SLAVE sync: Loading DB in memory
5190:S 17 Dec 14:42:54.061 * MASTER <-> SLAVE sync: Finished with success
首先分别在多台机器上redis目录中建立sentinel目录
cd /home/redis/
mkdir sentinel
然后分别在机器上建立sentinel.conf文件如下:
port 26371
dir /tmp
logfile "/home/redis/sentinel/sentinel.log"
protected-mode no
sentinel monitor x_master 172.16.6.6 6379 2
sentinel auth-pass x_master abcdefg
sentinel down-after-milliseconds x_master 15000
sentinel failover-timeout x_master 180000
sentinel parallel-syncs x_master 1
同样启动完一个sentinel实例记得先查看一下日志输出,看是否正常启动完成。
日志输出需要注意以下几点:
哨兵会对检测信息进行输出,判断master是否下线,有主观下线和客观下线之分:
1. 主观下线(Subjectively Down,简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
2. 客观下线(Objectively Down,简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的服务器下线判断。
客观下线条件只适用于主服务器:对于任何其他类型的 Redis 实例,Sentinel 在将它们判断为下线前不需要进行协商, 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态,这个Sentinel 就可能会被其他 Sentinel 推选出,并对失效的主服务器执行自动故障迁移操作。
进入到想要查看的主机,通过以下命令指定登录哪个实例端口
cd /home/redis/
./redis-cli –p 6379
> auth abcdefg
> quit # 退出连接
方法一:登录客户端,执行shutdown,生产环境慎用。
> shutdown
方法二:直接kill掉相应的实例进程。
登录客户端后执行:执行monitor,生产环境慎用。
> monitor
登录客户端后执行:执行info
> info
信息如下:
# Server
redis_version:3.2.6 ###redis版本号
redis_git_sha1:00000000 ###git SHA1
redis_git_dirty:0 ###git dirty flag
redis_build_id:78796c63e58b72dc
redis_mode:standalone ###redis运行模式
os:Linux 2.6.32-431.el6.x86_64 x86_64 ###os版本号
arch_bits:64 ###64位架构
multiplexing_api:epoll ###调用epoll算法
gcc_version:4.4.7 ###gcc版本号
process_id:25899 ###服务器进程PID
run_id:eae356ac1098c13b68f2b00fd7e1c9f93b1c6a2c ###Redis的随机标识符(用于sentinel和集群)
tcp_port:6379 ###Redis监听的端口号
uptime_in_seconds:6419 ###Redis运行时长(s为单位)
uptime_in_days:0 ###Redis运行时长(天为单位)
hz:10
lru_clock:10737922 ###以分钟为单位的自增时钟,用于LRU管理
config_file:/etc/redis/redis.conf ###redis配置文件
# Clients
connected_clients:1 ###已连接客户端的数量(不包括通过从属服务器连接的客户端)
client_longest_output_list:0 ###当前连接的客户端中最长的输出列表
client_biggest_input_buf:0 ###当前连接的客户端中最大的输出缓存
blocked_clients:0 ###正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量 需监控
# Memory
used_memory:2281560 ###由 Redis 分配器分配的内存总量,以字节(byte)为单位
used_memory_human:2.18M ###以更友好的格式输出redis占用的内存
used_memory_rss:2699264 ###从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top,ps 等命令的输出一致
used_memory_peak:22141272 ### Redis 的内存消耗峰值(以字节为单位)
used_memory_peak_human:21.12M ###以更友好的格式输出redis峰值内存占用
used_memory_lua:35840 ###LUA引擎所使用的内存大小
mem_fragmentation_ratio:1.18 ###used_memory_rss 和 used_memory 之间的比率
mem_allocator:jemalloc-3.6.0
###在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
# Persistence
loading:0 ###记录服务器是否正在载入持久化文件
rdb_changes_since_last_save:0 ###距离最近一次成功创建持久化文件之后,经过了多少秒
rdb_bgsave_in_progress:0 ###记录了服务器是否正在创建 RDB 文件
rdb_last_save_time:1420023749 ###最近一次成功创建 RDB 文件的 UNIX 时间戳
rdb_last_bgsave_status:ok ###最近一次创建 RDB 文件的结果是成功还是失败
rdb_last_bgsave_time_sec:0 ###最近一次创建 RDB 文件耗费的秒数
rdb_current_bgsave_time_sec:-1 ###如果服务器正在创建 RDB 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:1 ###AOF 是否处于打开状态
aof_rewrite_in_progress:0 ###服务器是否正在创建 AOF 文件
aof_rewrite_scheduled:0 ###RDB 文件创建完毕之后,是否需要执行预约的 AOF 重写操作
aof_last_rewrite_time_sec:-1 ###最近一次创建 AOF 文件耗费的时长
aof_current_rewrite_time_sec:-1 ###如果服务器正在创建 AOF 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_last_bgrewrite_status:ok ###最近一次创建 AOF 文件的结果是成功还是失败
aof_last_write_status:ok
aof_current_size:176265 ###AOF 文件目前的大小
aof_base_size:176265 ###服务器启动时或者 AOF 重写最近一次执行之后,AOF 文件的大小
aof_pending_rewrite:0 ###是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行
aof_buffer_length:0 ###AOF 缓冲区的大小
aof_rewrite_buffer_length:0 ###AOF 重写缓冲区的大小
aof_pending_bio_fsync:0 ###后台 I/O 队列里面,等待执行的 fsync 调用数量
aof_delayed_fsync:0 ###被延迟的 fsync 调用数量
# Stats
total_connections_received:8466 ###服务器已接受的连接请求数量
total_commands_processed:900668 ###服务器已执行的命令数量
instantaneous_ops_per_sec:1 ###服务器每秒钟执行的命令数量
total_net_input_bytes:82724170
total_net_output_bytes:39509080
instantaneous_input_kbps:0.07
instantaneous_output_kbps:0.02
rejected_connections:0 ###因为最大客户端数量限制而被拒绝的连接请求数量
sync_full:2
sync_partial_ok:0
sync_partial_err:0
expired_keys:0 ###因为过期而被自动删除的数据库键数量
evicted_keys:0 ###因为最大内存容量限制而被驱逐(evict)的键数量。
keyspace_hits:0 ###查找数据库键成功的次数。
keyspace_misses:500000 ###查找数据库键失败的次数。
pubsub_channels:0 ###目前被订阅的频道数量
pubsub_patterns:0 ###目前被订阅的模式数量
latest_fork_usec:402 ###最近一次 fork() 操作耗费的毫秒数
# Replication
role:master ###如果当前服务器没有在复制任何其他服务器,那么这个域的值就是 master ;否则的话,这个域的值就是 slave 。注意,在创建复制链的时候,一个从服务器也可能是另一个服务器的主服务器
connected_slaves:2 ###2个slaves
slave0:ip=172.16.6.7,port=6379,state=online,offset=1639,lag=1
slave1:ip=172.16.6.8,port=6379,state=online,offset=1639,lag=0
master_repl_offset:1639
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1638
# CPU
used_cpu_sys:41.87 ###Redis 服务器耗费的系统 CPU
used_cpu_user:17.82 ###Redis 服务器耗费的用户 CPU
used_cpu_sys_children:0.01 ###后台进程耗费的系统 CPU
used_cpu_user_children:0.01 ###后台进程耗费的用户 CPU
# Keyspace
db0:keys=3101,expires=0,avg_ttl=0 ###keyspace 部分记录了数据库相关的统计信息,比如数据库的键数量、数据库已经被删除的过期键数量等。对于每个数据库,这个部分都会添加一行以下格式的信息
登录客户端后执行:执行keys
> keys key # 查看特定的key,支持表达式
> keys * # 查看所有的key
Redis配置信息通过.conf文件进行配置,运行过程中可以通过以下命令进行查看和修改
> config get :获取服务器配置信息
例如:
> config get dir # 获取工作目录
> config get * # 查看所有配置
> config set 配置信息 # 临时设置
> config rewrite 配置信息 # 永久设置,将目前服务器的参数配置写入redis.conf
结果为查询ID、发生时间、运行时长和原命令
> SLOWLOG GET 10
命令为SLAVEOF
SLAVEOF 命令用于在 Redis 运行时动态地修改复制(replication)功能的行为。
通过执行 SLAVEOF host port 命令,可以将当前服务器转变为指定服务器的从属服务器(slave server)。
如果当前服务器已经是某个主服务器(master server)的从属服务器,那么执行 SLAVEOF host port 将使当前服务器停止对旧主服务器的同步,丢弃旧数据集,转而开始对新主服务器进行同步。
另外,对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能,并从从属服务器转变回主服务器,原来同步所得的数据集不会被丢弃。
利用『 SLAVEOF NO ONE 不会丢弃同步所得数据集』这个特性,可以在主服务器失败的时候,将从属服务器用作新的主服务器,从而实现无间断运行。
> SLAVEOF host port
> SLAVEOF NO ONE
Sentinel命令有以下
PING :返回 PONG 。
SENTINEL masters :列出所有被监视的主服务器,以及这些主服务器的当前状态;
SENTINEL slaves :列出给定主服务器的所有从服务器,以及这些从服务器的当前状态;
SENTINEL get-master-addr-by-name :返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个命令返回新的主服务器的 IP 地址和端口号;
SENTINEL reset : 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel ;
SENTINEL failover : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移。(切换需要一定时间,会出现卡顿影响业务,慎用)
> SENTINEL failover name> # 手动切换
Sentinel命令可以查看相关信息:
> sentinel master mymaster //查看master的状态
> sentinel slaves mymaster //查看salves的状态
> sentinel sentinels mymaster //查看哨兵的状态
> sentinel get-master-addr-by-name mymaster //获取当前master的地址
> info sentinel//查看哨兵信息
Redis dbsize命令用来得到所选数据库key数量。
> dbsize
返回连接到Redis服务器的客户端列表。
> client list
关闭指定的客户端连接,生产环境慎用。
> client kill
例如B是A的从节点,同时C也是A的从节点,想要修改C为B的从节点,从而形成链式主从关系,A <- B <- C。在哨兵模式下,如果单纯在C节点下在线之下saveof命令,并不能成功,原因是命令切换后,哨兵管理下已经监管到C了,会对C重新切换回来作为A的从节点。因此需要进行以下操作:
1. 先停掉C节点实例。(并修改C节点的redis配置文件slaveof B.ip B.port)
2. 让哨兵重新刷新监管列表,分别登录几个哨兵客户端执行命令
> redis-cli -p 26371
> SENTINEL RESET *
# SENTINEL RESET mastername